Hi All,
LLVM now includes a C++ standard library, written by Howard Hinnant. You can read about it here:
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
Thanks Joe. Try now.
-Howard
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
Hi All,
LLVM now includes a C++ standard library, written by Howard Hinnant. You
can read about it here:
New "libc++" C++ Standard Library - The LLVM Project BlogOr get the code here:
svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxxIf 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.
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
andrew.n.sutton@gmail.com
This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway).
-Howard
What’s driving libc++?
The possibility of being a superior solution.
I thought “to support Apple applications” from the previous post was sufficient motivation
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
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
> 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> = 6libstdc++:
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
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
s/compatibility/incompatibility/
-Dave
<removing llvm-dev, no need to spam both lists>
FYI, there is no reason for this thread to exist on both llvmdev and cfe-dev. Please move it to cfe-dev.
-Chris
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
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
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
Hi Howard
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 5Since 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
it seems odd that the libc++ runtime does not change when compiling at -O0.
Why is that?
Best wishes,
Duncan.
I haven't a chance to look at this.
-Howard
My questions aren't intended as an attack on anyone or on libc++. I think
they are valid questions worth discussing.
> 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