Linked by Thom Holwerda on Thu 7th Oct 2010 19:10 UTC, submitted by tyrione
Permalink for comment 444584
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
Linked by Thom Holwerda on 04/14/13 18:22 UTC, submitted by MOS6510
More Features »
Sponsored Links



Member since:
2010-03-08
Every compiler has it's strengths and weaknesses. E.g., compile a very large array of structs. gcc will become a monstrosity, taking enormous amounts of memory, while VC++ effortlessly compiles it in a VM with only 512MB RAM.
It's not exactly clear-cut. But the fact is that gcc until recently didn't have a decent system for plugins to avoid proprietary plugins, and LLVM has forced them to offer such functionality to compete.
Indeed. LLVM is something nice, be it only because it pushes innovation forward in areas which GCC traditionally doesn't explore (internal structure, error messages, plug-ins...).
However, I'm not sure the memory and resource consumption of LLVM is a good argument. Currently, LLVM optimizes code much less than GCC implementations (at least on the tests provided here). Chances are that to optimize code as much as gcc -O3 (or maybe the new -Ofast, not sure what it actually does), LLVM could require much more memory than it currently does.
Edited 2010-10-09 11:17 UTC