Re: [LLVMdev] New libc++ LLVM Subproject

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Joe Ranieri
On 5/11/10 4:43 PM, Chris Lattner wrote:

> Hi All,
>
> LLVM now includes a C++ standard library, written by Howard Hinnant.  You can read about it here:
> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html
>
> Or get the code here:
> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
>
> If you have questions or comments, please direct them to one of the clang mailing lists.  Thanks!
>
> -Chris

Awesome news! The links to 'Browse SVN' and 'Browse ViewVC' seem to be
pointing to compiler-rt instead of libcxx though...


-- Joe Ranieri
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Howard Hinnant
On May 11, 2010, at 4:46 PM, Joe Ranieri wrote:

> On 5/11/10 4:43 PM, Chris Lattner wrote:
>> Hi All,
>>
>> LLVM now includes a C++ standard library, written by Howard Hinnant.  You can read about it here:
>> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html
>>
>> Or get the code here:
>> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
>>
>> If you have questions or comments, please direct them to one of the clang mailing lists.  Thanks!
>>
>> -Chris
>
> Awesome news! The links to 'Browse SVN' and 'Browse ViewVC' seem to be
> pointing to compiler-rt instead of libcxx though...

Thanks Joe.  Try now.

-Howard


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
dag
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

dag
In reply to this post by Joe Ranieri
On Tuesday 11 May 2010 15:43:21 Chris Lattner wrote:

> Hi All,
>
> LLVM now includes a C++ standard library, written by Howard Hinnant.  You
> can read about it here:
> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html
>
> Or get the code here:
> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
>
> If you have questions or comments, please direct them to one of the clang
> mailing lists.  Thanks!

This looks cool, but I can't help wondering about the motivation.  libstdc++
has a ton of useful functionality (debug mode, profile mode, etc.).  Does
libc++ plan to reproduce that?

What's driving libc++?

                                -Dave

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Howard Hinnant
On May 11, 2010, at 7:26 PM, David Greene wrote:

> On Tuesday 11 May 2010 15:43:21 Chris Lattner wrote:
>> Hi All,
>>
>> LLVM now includes a C++ standard library, written by Howard Hinnant.  You
>> can read about it here:
>> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html
>>
>> Or get the code here:
>> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
>>
>> If you have questions or comments, please direct them to one of the clang
>> mailing lists.  Thanks!
>
> This looks cool, but I can't help wondering about the motivation.  libstdc++
> has a ton of useful functionality (debug mode, profile mode, etc.).  Does
> libc++ plan to reproduce that?

debug mode yes.  It isn't there yet.  And I would like to limit it to being ABI compatible with release mode.  This will entail significant debug functionality curtailment, but also eliminate numerous errors I've seen when debug mode and release mode get accidentally mixed.

> What's driving libc++?

The possibility of being a superior solution.

----------------

// Container overhead example

#include <iostream>
#include <deque>
#include <map>

int main()
{
    typedef std::map<int, int> M;
    typedef std::deque<int> C;
    std::cout << "sizeof map<int, int> = " << sizeof(M)/sizeof(void*) << '\n';
    std::cout << "sizeof deque<int> = " << sizeof(C)/sizeof(void*) << '\n';
}

libc++:

sizeof map<int, int> = 3
sizeof deque<int> = 6

libstdc++:

sizeof map<int, int> = 6
sizeof deque<int> = 10

(smaller is better)

----------------

// Adding a few items to a sorted sequence and resorting
//    (a real world use case)

#include <iostream>
#include <algorithm>
#include <vector>
#include <ctime>

int main()
{
    typedef std::vector<int> V;
    V v;
    const int N = 100000000;
    for (int i = 0; i < N; ++i)
        v.push_back(i);
    for (int i = N; i > 0;)
    {
        i -= N/10;
        int j = v[i];
        v.erase(v.begin() + i);
        v.push_back(j);
    }
    std::random_shuffle(v.begin() + 9 * v.size() / 10, v.end());
    // How long does it take to resort a vector when
    //    only the last 90% is unsorted?
    std::time_t t0 = std::time(0);
    std::sort(v.begin(), v.end());
    std::time_t t1 = std::time(0);
    std::cout << difftime(t1, t0) << " seconds\n";
}

libc++:

5 seconds

libstdc++:

22 seconds

(smaller is better)

----------------

This being said, clang will continue to be std::lib neutral.  If libstdc++ meets your needs better than libc++, then you should use it.  libc++ will have to earn its place.

-Howard


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Andrew Sutton
> What's driving libc++?

The possibility of being a superior solution.

I thought "to support Apple applications" from the previous post was sufficient motivation :) Either way, I'm excited about a new library. Plus, it looks a little easier to read (from the tiny amount of code that I've looked at).
 
libc++:

5 seconds

libstdc++:

22 seconds

(smaller is better)
 
Is this libstdc++ with or without rvalue references?

Andrew Sutton
[hidden email]

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Howard Hinnant
On May 11, 2010, at 8:40 PM, Andrew Sutton wrote:

> > What's driving libc++?
>
> The possibility of being a superior solution.
>
> I thought "to support Apple applications" from the previous post was sufficient motivation :) Either way, I'm excited about a new library. Plus, it looks a little easier to read (from the tiny amount of code that I've looked at).
>  
> libc++:
>
> 5 seconds
>
> libstdc++:
>
> 22 seconds
>
> (smaller is better)
>  
> Is this libstdc++ with or without rvalue references?

This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway).

-Howard


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

David Leimbach
In reply to this post by Andrew Sutton


On Tue, May 11, 2010 at 5:40 PM, Andrew Sutton <[hidden email]> wrote:
> What's driving libc++?

The possibility of being a superior solution.

I thought "to support Apple applications" from the previous post was sufficient motivation :) Either way, I'm excited about a new library. Plus, it looks a little easier to read (from the tiny amount of code that I've looked at).

Just two throw 2 more motivators in...

Sometimes to re-implement after learning from work done before by others is a reason to try it in itself.  Also a lot of LLVM is C++ isn't it?  Wouldn't it be nice if it were 100% self hosting at some point?  (I think so.)

Not having to depend on anyone else to make your stuff work is, well, liberating.

Dave
 
 
libc++:

5 seconds

libstdc++:

22 seconds

(smaller is better)
 
Is this libstdc++ with or without rvalue references?

How about compile times?  Having used Go a bit, I've been quite fond of how short the code, compile, test loop ends up being.

Dave
 

Andrew Sutton
[hidden email]

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Howard Hinnant
On May 11, 2010, at 9:32 PM, David Leimbach wrote:

>  
> libc++:
>
> 5 seconds
>
> libstdc++:
>
> 22 seconds
>
> (smaller is better)
>  
> Is this libstdc++ with or without rvalue references?
>
> How about compile times?  Having used Go a bit, I've been quite fond of how short the code, compile, test loop ends up being.

Tonight compile times look worse.  This isn't completely unexpected as the code size of the libc++ sort is larger than the libstdc++ sort.  Here is a matrix of times.  Each time represents seconds and a median of 3 measurements:

                compile time          run time
              ----------------    ----------------
              libstdc++ libc++    libstdc++ libc++

g++-4.2 -O3      0.62    0.96        23       5
clang++ -O3      0.66    0.80        21       5

Since compile times are usually more important with non-opitimzed builds I computed the same table at -O0:

                compile time          run time
              ----------------    ----------------
              libstdc++ libc++    libstdc++ libc++

g++-4.2 -O0      0.48    .76         186      5
clang++ -O0      0.46    .70         261      5

-Howard


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
dag
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

dag
In reply to this post by Howard Hinnant
On Tuesday 11 May 2010 19:07:50 Howard Hinnant wrote:

> > This looks cool, but I can't help wondering about the motivation.
> > libstdc++ has a ton of useful functionality (debug mode, profile mode,
> > etc.).  Does libc++ plan to reproduce that?
>
> debug mode yes.  It isn't there yet.  And I would like to limit it to being
>  ABI compatible with release mode.  This will entail significant debug
>  functionality curtailment, but also eliminate numerous errors I've seen
>  when debug mode and release mode get accidentally mixed.

Ouch.  I hope libc++ doesn't give up any debug functionality.  It's
indispensable.  I think the ABI compatibility is worth it, but then I've
never run into significant problems where I've been forced to mix
debug and non-debug mode code.

> > What's driving libc++?
>
> The possibility of being a superior solution.

Ok, but could that be done by improving libstdc++?

> ----------------
>
> // Container overhead example

> libc++:
>
> sizeof map<int, int> = 3
> sizeof deque<int> = 6
>
> libstdc++:
>
> sizeof map<int, int> = 6
> sizeof deque<int> = 10
>
> (smaller is better)

Well, that depends, doesn't it?  Why is libstdc++ larger?  Is any
functionality being given up by libc++?  If not, why not improve
libstdc++?

> ----------------
>
> // Adding a few items to a sorted sequence and resorting
> //    (a real world use case)
>
> libc++:
>
> 5 seconds
>
> libstdc++:
>
> 22 seconds
>
> (smaller is better)

Again, what prevents someone from improving libstdc++ here?

Numbers are good, but context and analysis are even better.
 
> ----------------
>
> This being said, clang will continue to be std::lib neutral.  If libstdc++
>  meets your needs better than libc++, then you should use it.  libc++ will
>  have to earn its place.

Of course.  That will require some pretty comprehensive analysis.  Right now
I don't know which meets my needs better because we don't yet have an
explanation of what the trade-offs are.

I understand libc++ is new and you're probably not at that point yet, but
a motivating document would help.  Is there are document somewhere that
explains why the project was started in the first place?

                                      -Dave
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
dag
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

dag
In reply to this post by David Leimbach
On Tuesday 11 May 2010 20:32:58 David Leimbach wrote:

> Just two throw 2 more motivators in...
>
> Sometimes to re-implement after learning from work done before by others is
> a reason to try it in itself.  Also a lot of LLVM is C++ isn't it?

Yes...

>  Wouldn't it be nice if it were 100% self hosting at some point?  (I think
>  so.)

Define self-hosting.  LLVM is already self-hosting in the sense that it
compiles itself.

> Not having to depend on anyone else to make your stuff work is, well,
> liberating.

Yikes!  To me that is the scariest scenario I can imagine.

The best technical interview question I've ever been asked is, "what code
would you never write?"  Standard library functionality is at the top of my
list.  Why would anyone replace rigorously tested code with something
not as widely tested that one has to maintain oneself?

It reminds me of an interview lunch at which the developers constantly
regaled me with tales of their wonderful custom data structures library.
And then I asked about where they spend most of their time debugging.
Guess where?  Suffice to say, I didn't take that job.  :)

Again, I'm not dismissing libc++.  I'm making a general point about
reusing hardened code.  If libc++ is demonstrably better than other
solutions, I'll be the first on board.  But I do wonder why libstdc++ could
not be improved in the same way while retaining is enormous testing base.

And what about libstdc++ doesn't work for Apple applications?

                                           -Dave
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

greened
In reply to this post by dag
On Tuesday 11 May 2010 23:47:03 David Greene wrote:

> Ouch.  I hope libc++ doesn't give up any debug functionality.  It's
> indispensable.  I think the ABI compatibility is worth it, but then I've
 
s/compatibility/incompatibility/

                                      -Dave
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Chris Lattner
In reply to this post by dag
<removing llvm-dev, no need to spam both lists>

On May 11, 2010, at 9:47 PM, David Greene wrote:
>>> What's driving libc++?
>>
>> The possibility of being a superior solution.
>
> Ok, but could that be done by improving libstdc++?

We have no interest in touching libstdc++, both because of its license, but also because a clean rewrite brings a number of advantages.  This is not the first C++ standard library Howard has written, and he is definitely guru-level in his abilities. :)

Also, we don't claim that libc++ is ready for use today (like you said, debug mode is a clear missing feature).  However, libc++ does already provide a number of advantages over libstdc++, and will continue to improve.  If you are more interested in improving libstdc++ than libc++, you are welcome to go do so :)

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Chris Lattner
In reply to this post by dag
On May 11, 2010, at 9:53 PM, David Greene wrote:
> The best technical interview question I've ever been asked is, "what code
> would you never write?"  Standard library functionality is at the top of my
> list.  Why would anyone replace rigorously tested code with something
> not as widely tested that one has to maintain oneself?

Because you think that the end result will be better than what you get if you don't do the work?  By the same argument, why implement a new compiler if you already have one?  The old compiler is well tested and you don't have to maintain it.  Perhaps if you were a library developer instead of a compiler developer you'd understand the opportunity and value. :)

> Again, I'm not dismissing libc++.  I'm making a general point about
> reusing hardened code.  If libc++ is demonstrably better than other
> solutions, I'll be the first on board.  But I do wonder why libstdc++ could
> not be improved in the same way while retaining is enormous testing base.

You obviously took a lot of time to familiarize yourself with the testing framework that libc++ includes?

> And what about libstdc++ doesn't work for Apple applications?

There are many many things about it that are "less than great".  Please familiarize yourself with *either* of the libstdc++ or libc++ implementations before you claim that libstdc++ can't be improved on.

And yes, there is a threshold where starting over is much easier and gives a better result than incrementally improving an existing code base.  One thing that is difficult to achieve with incremental improvement is a replacement of the community built around the codebase.

In any case, questioning motives is not particularly interesting or useful.  If you're not interested in contributing to libc++... then don't!  I'm not particularly interested in discussing why we didn't use libstdc++ any more than the apache libcxx, or many other alternative libraries (most of which are stale/abandoned and have serious technical problems).  Lets discuss the present and future of libc++ instead.

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Jeffrey Yasskin
In reply to this post by Howard Hinnant
On Tue, May 11, 2010 at 7:24 PM, Howard Hinnant <[hidden email]> wrote:

> On May 11, 2010, at 9:32 PM, David Leimbach wrote:
>
>>
>> libc++:
>>
>> 5 seconds
>>
>> libstdc++:
>>
>> 22 seconds
>>
>> (smaller is better)
>>
>> Is this libstdc++ with or without rvalue references?
>>
>> How about compile times?  Having used Go a bit, I've been quite fond of how short the code, compile, test loop ends up being.
>
> Tonight compile times look worse.  This isn't completely unexpected as the code size of the libc++ sort is larger than the libstdc++ sort.


That raises an interesting question. Larger sort code will invalidate
more of the instruction cache, so one may only want to use the
larger-but-faster sort for hot sorts, while colder code should use a
smaller sort even if it's somewhat slower. Do you guys have any ideas
on how to automate that choice?

Jeffrey

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Christopher Jefferson
In reply to this post by Howard Hinnant

On 12 May 2010, at 01:07, Howard Hinnant wrote:

> On May 11, 2010, at 7:26 PM, David Greene wrote:
>
>> On Tuesday 11 May 2010 15:43:21 Chris Lattner wrote:
>>> Hi All,
>>>
>>> LLVM now includes a C++ standard library, written by Howard Hinnant.  You
>>> can read about it here:
>>> http://blog.llvm.org/2010/05/new-libc-c-standard-library.html
>>>
>>> Or get the code here:
>>> svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
>>>
>>> If you have questions or comments, please direct them to one of the clang
>>> mailing lists.  Thanks!
>>
>> This looks cool, but I can't help wondering about the motivation.  libstdc++
>> has a ton of useful functionality (debug mode, profile mode, etc.).  Does
>> libc++ plan to reproduce that?
>
> debug mode yes.  It isn't there yet.  And I would like to limit it to being ABI compatible with release mode.  This will entail significant debug functionality curtailment, but also eliminate numerous errors I've seen when debug mode and release mode get accidentally mixed.

While it would require more work, I believe using 'inline namespaces' would provide the best of both worlds. There can be 2 debugging libraries. One which is ABI-compatable with the standard library while providing as much functionality as possible, and a second which is ABI-incompatable but thanks to being defined in a different namespace and then 'inlined' in std would mangle differently, providing compile-time errors rather than the current run-time errors which often arise from using such a library.

Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Howard Hinnant
In reply to this post by Jeffrey Yasskin
On May 12, 2010, at 1:47 AM, Jeffrey Yasskin wrote:

> On Tue, May 11, 2010 at 7:24 PM, Howard Hinnant <[hidden email]> wrote:
>> On May 11, 2010, at 9:32 PM, David Leimbach wrote:
>>
>>>
>>> libc++:
>>>
>>> 5 seconds
>>>
>>> libstdc++:
>>>
>>> 22 seconds
>>>
>>> (smaller is better)
>>>
>>> Is this libstdc++ with or without rvalue references?
>>>
>>> How about compile times?  Having used Go a bit, I've been quite fond of how short the code, compile, test loop ends up being.
>>
>> Tonight compile times look worse.  This isn't completely unexpected as the code size of the libc++ sort is larger than the libstdc++ sort.
>
>
> That raises an interesting question. Larger sort code will invalidate
> more of the instruction cache, so one may only want to use the
> larger-but-faster sort for hot sorts, while colder code should use a
> smaller sort even if it's somewhat slower. Do you guys have any ideas
> on how to automate that choice?

I haven't a chance to look at this.

-Howard


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
dag
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

dag
In reply to this post by Chris Lattner
My questions aren't intended as an attack on anyone or on libc++.  I think
they are valid questions worth discussing.

On Wednesday 12 May 2010 00:26:38 Chris Lattner wrote:

> On May 11, 2010, at 9:53 PM, David Greene wrote:
> > The best technical interview question I've ever been asked is, "what code
> > would you never write?"  Standard library functionality is at the top of
> > my list.  Why would anyone replace rigorously tested code with something
> > not as widely tested that one has to maintain oneself?
>
> Because you think that the end result will be better than what you get if
>  you don't do the work?  By the same argument, why implement a new compiler
>  if you already have one?  The old compiler is well tested and you don't
>  have to maintain it.  Perhaps if you were a library developer instead of a
>  compiler developer you'd understand the opportunity and value. :)

LLVM has several good reasons to exist: license, the gcc developers'
prior resistance to a plugin architecture, JIT functionality and so on.

I simply don't see or don't understand that libstdc++ has a similar
level of "closedness."

> > Again, I'm not dismissing libc++.  I'm making a general point about
> > reusing hardened code.  If libc++ is demonstrably better than other
> > solutions, I'll be the first on board.  But I do wonder why libstdc++
> > could not be improved in the same way while retaining is enormous testing
> > base.
>
> You obviously took a lot of time to familiarize yourself with the testing
>  framework that libc++ includes?

I'm not sure what you're driving at.  What does libc++'s testing framework
have to do with improving libstdc++?  Can you make the connection for me?

"Testing base" as I meant it doesn't mean testcases.  It means a huge amount
of people running the code in production environments and filing bugs.

My unfamiliarity with libc++'s testing framework isn't relevant as far as I
can see.  Seems like an ad hominem argument to me.

> > And what about libstdc++ doesn't work for Apple applications?
>
> There are many many things about it that are "less than great".  Please
>  familiarize yourself with *either* of the libstdc++ or libc++
>  implementations before you claim that libstdc++ can't be improved on.

Wait.  Isn't the burden on libc++ developers to argue their case?  What about
libstdc++ prevents it from being improved?

> And yes, there is a threshold where starting over is much easier and gives
>  a better result than incrementally improving an existing code base.  One

Yes, that's true.  But I haven't yet been told why libstdc++ is at that point.

>  thing that is difficult to achieve with incremental improvement is a
>  replacement of the community built around the codebase.

Ok, so what about libstdc++'s community needs fixing?  I've found the
libstdc++ developers quite responsive and easy to work with.

> In any case, questioning motives is not particularly interesting or useful.

I think "questioning" is the wrong word.  It is always good to take a step
back and ask whether there is a better, more productive and more
beneficial path.

>   If you're not interested in contributing to libc++... then don't!  I'm
>  not particularly interested in discussing why we didn't use libstdc++ any
>  more than the apache libcxx, or many other alternative libraries (most of
>  which are stale/abandoned and have serious technical problems).  Lets
>  discuss the present and future of libc++ instead.

Here's the sad thing about this.  We have the potential to improve libstdc++,
which is widely used.  Many, many people could benefit.  Maybe libc++ will
get that userbase eventually.  But libstdc++ has that _today_.  Without a
strong motivation for libc++, I can only conclude that improving libstdc++
is a much bigger lever that rewriting something from scratch.

You've hinted at issues with libstdc++.  I would like to understand those.
And it's not reasonable to tell people, "go study the libstdc++ code and
then come back."

The reason there are "stale/abandoned" libraries that "have serious technical
problems" is that NIH is a strong motivator and people didn't want to improve
what is already there.  If improvement isn't possible, fine.  But I need to be
convinced of that.

                                         -Dave
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Daniel Berlin
In reply to this post by Howard Hinnant
>
> This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway).

Errr, that is a pretty old version at this point.
Also this was before significant performance improvements were target
at libstdc++ *and* g++.
It seems a bit strange to compare something from today to something
that is now 3 release versions old.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Christopher Jefferson

On 12 May 2010, at 15:52, Daniel Berlin wrote:

>>
>> This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway).
>
> Errr, that is a pretty old version at this point.
> Also this was before significant performance improvements were target
> at libstdc++ *and* g++.
> It seems a bit strange to compare something from today to something
> that is now 3 release versions old.

I believe this std::sort implementation is better, taking a few good ideas, especially with regards already most-sorted lists. Of course the libc++ could easily be lifted out and dropped into libstdc++ with very minor mangling-related changes without breaking anything.

The container changes are more fundamental, and in particular would (obviously) break the ABI, which libstdc++ has avoided for some time, even when there are known better implementation techniques (issues in std::string, and small object allocation, occur in particular).

Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] New libc++ LLVM Subproject

Anton Korobeynikov
In reply to this post by Daniel Berlin
> Errr, that is a pretty old version at this point.
> Also this was before significant performance improvements were target
> at libstdc++ *and* g++.
Because this is the last version of gcc "oficially" available for
darwin? Noone cares about newer gcc / libstdc++ there.
I consider this pretty strange as well :)

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
12