

GCC 4.9.0 released - arunc
http://gcc.gnu.org/ml/gcc/2014-04/msg00195.html

======
jds375
One particularly impressive improvement: "Memory usage building Firefox with
debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to
350 seconds" \-
[http://gcc.gnu.org/gcc-4.9/changes.html](http://gcc.gnu.org/gcc-4.9/changes.html)

~~~
octoploid
"When LTO is used". For more info about LinkTimeOptimization and Firefox see
the recent blog post from one of its main implementors:
[http://hubicka.blogspot.com/2014/04/linktime-optimization-
in...](http://hubicka.blogspot.com/2014/04/linktime-optimization-in-
gcc-2-firefox.html)

~~~
_pmf_
> Memory usage building Firefox with debug enabled was reduced from 15GB to
> 3.5GB; link time from 1700 seconds to 350 seconds

Why does using LTO reduce link time? It would expect the result to be smaller,
but transient memory usage to be significantly higher.

~~~
joosters
It doesn't reduce link time, the comparison is between LTO link times for old
& new gcc.

------
pdq
This is excellent:

    
    
      GCC 4.9 provides a complete implementation of the Go 1.2.1 release.

~~~
personZ
This is a really interesting aspect. gccgo was intended to be the very high
performance compiler for Go (with the intermediate compilation that could
benefit from the many years of optimization in GCC), versus gc which was
relatively new and unoptimized. It is great to see them catch up.

Though it would be interesting to see hard benchmarks. As is I have found
performance regressions when compiling with prior versions of gccgo, as
compared to gc.

------
mbrubeck
Previous discussion of the GCC 4.9 changelog:
[https://news.ycombinator.com/item?id=7578896](https://news.ycombinator.com/item?id=7578896)

------
Igglyboo
From the changelog

|Memory usage building Firefox with debug enabled was reduced from 15GB to
3.5GB; link time from 1700 seconds to 350 seconds.

That's pretty impressive.

~~~
gtaylor
wow, that is. Any idea if there are any downsides or bugs resulting from this
optimization? Or is this just pure win?

~~~
azakai
It's on LTO (link time optimization), which was previously not much optimized
for compilation speed. Most projects probably don't need LTO so this won't
matter for them, but for projects like Firefox that do, faster LTO compilation
is a great thing.

~~~
riffraff
not being an expert of such things, could you explain to me why do you think
most projects don't need LTO ? (I'm interpreting that as "won't gain much",
rather than "will find optimizations unnecessary")

~~~
azakai
In my experience things like PGO and LTO matter most in very large projects.
Of course it depends on the codebase, but in general that's what I've seen.

In very large projects, fully optimizing all the code is often unneeded, and
bad because fully optimized code is larger (inlining, unrolled loops, etc.).
PGO lets you find what actually needs to be optimized, and you can keep the
rest compact to improve load times. Vice versa, PGO can tell you what code is
run immediately on load so you can order it so that happens faster, etc.

Similarly, LTO is most useful in large projects where it is not obvious to the
compiler how to optimize across compilation unit boundaries - as in a small
enough project, either there are few such boundaries or it is easy to manually
optimize for them.

------
bsdetector
Still no D compiler huh? I've been out of the scene for a while, but I think
they were they promising D support would be included a releases or two after
Go support was added. What happened?

~~~
sp332
It seems to be in active development
[http://gdcproject.org/downloads/](http://gdcproject.org/downloads/) "Merging
GDC into upstream GDB" is on the list of project ideas
[http://wiki.dlang.org/GDC/ProjectIdeas](http://wiki.dlang.org/GDC/ProjectIdeas)

~~~
abique
How is growing D? I played with it 6 years ago, then I totally forgot it.

------
noname123
OT but tangential, what do you guys use to build/make via GCC?

Makefile seems like you have to code every new addition in your build manually
and take care of the dependency tree.

Eclipse CDT seems difficult to set up.

Ant doesn't seem like good C/C++ Make options and require lots of XML and
extra plugins to get it work.

Scons seems like a good option. Haven't tried Maven. What do you guys use to
do C/C++ builds for production or for fun?

~~~
AndrewBissell
CMake is worth a try. Notably, it's the first build system that IntelliJ's new
C/C++ IDE will support once it's released.

Although it's discouraged, CMake does have a way around the "code every new
addition in your build manually" problem:
[http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:au...](http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:aux_source_directory)

~~~
cypher543
I despise CMake's syntax. But it is by far the best build system to use if you
like IDEs and don't want to manage separate project files.

~~~
AndrewBissell
Yeah I remember reading a review of CMake that asked why, with so many good
scripting languages out there these days, they would hand roll their own
subpar implementation. But I mostly think it's a wash between CMake and
vanilla make, with its significant tabs nonsense.

