From: Gustavo S. B. <bar...@gm...> - 2007-07-02 00:17:38
|
Hi guys, these days I was reading GCC's manual and saw that it can compile and operate on more than one file at the same time (-combine) and optimize based on this (-fwhole-program). Until GCC get link-time optimization (LTO) support, this is the only way to optimize within files, but we're unable to use this, because we use autotools and it's stupid way to generate one object (.o) per source (.c)... this is great while developing, reducing compile time, just recompiling the changed sources and then linking it again, but it sucks for the final build. This should shrink final source, produce more optimized code, etc. Another step to improve optimization would be use profile feedback (-fprofile-generate and -fprofile-use) , with -fprofile-arcs, -freorder-functions... AFAIK, autotools doesn't support these things, maybe CMake but I'm not sure, do you know any build infrastructure that supports this? I'd really like to have this setup so we could use GCC better, for systems like Nokia N800 and OpenMoko, this makes a big difference. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Michael J. <e-...@ka...> - 2007-07-03 23:06:38
|
On Sunday, 01 July 2007, at 21:17:30 (-0300), Gustavo Sverzut Barbieri wrote: > Hi guys, these days I was reading GCC's manual and saw that it can > compile and operate on more than one file at the same time (-combine) > and optimize based on this (-fwhole-program). > > Until GCC get link-time optimization (LTO) support, this is the only > way to optimize within files, but we're unable to use this, because we > use autotools and it's stupid way to generate one object (.o) per > source (.c)... this is great while developing, reducing compile time, > just recompiling the changed sources and then linking it again, but it > sucks for the final build. > > This should shrink final source, produce more optimized code, etc. > > Another step to improve optimization would be use profile feedback > (-fprofile-generate and -fprofile-use) , with -fprofile-arcs, > -freorder-functions... > > AFAIK, autotools doesn't support these things, maybe CMake but I'm not > sure, do you know any build infrastructure that supports this? I'd > really like to have this setup so we could use GCC better, for systems > like Nokia N800 and OpenMoko, this makes a big difference. Nothing in the "build infrastructure" is preventing anyone from adding an extra target in the Makefile.am for his own special needs. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Would the congregation please note that the bowl at the back of the church labeled 'For the Sick' is for monetary donations only." -- Churchdown Parish Magazine, Gloucestershire, England |
From: Caio M. <cma...@gm...> - 2007-07-04 13:55:44
|
On 7/3/07, Michael Jennings <e-...@ka...> wrote: > > AFAIK, autotools doesn't support these things, maybe CMake but I'm not > > sure, do you know any build infrastructure that supports this? I'd > > really like to have this setup so we could use GCC better, for systems > > like Nokia N800 and OpenMoko, this makes a big difference. > > Nothing in the "build infrastructure" is preventing anyone from adding > an extra target in the Makefile.am for his own special needs. (Just expanding the idea a little more...) We could add a configure.sh option to enable "final" or "production" build. This would set a var to be used in Makefile.am that could override the default rule for building the library (or executable), something like this: # appending to evas/src/lib/canvas/Makefile.am if FINAL libevas_canvas.la: $(libevas_canvas_la_SOURCES) $(libevas_canvas_la_DEPENDENCIES) # insert gcc special call here, it would be useful to see # the default rule generated by Automake (in the generated # Makefile.in) to see what useful vars are available, # like: libevas_canvas_la_LDFLAGS, etc. endif I'm not sure whether the rule that Automake generates is portable or it generate a different rule for different machines, so we may have to deal with different "final" rules. However, since it's an extra optimization, at first won't be a problem. AFAIK, to use CMake a similar solution would have to be used. The version I looked even had custom rules for dealing with "FINAL" compilation for KDE3-related sources, but simply by creating a new source which #include'd all the others and compiling it. Cheers, Caio Marcelo |
From: Gustavo S. B. <bar...@gm...> - 2007-07-04 16:32:36
|
On 7/4/07, Caio Marcelo <cma...@gm...> wrote: > On 7/3/07, Michael Jennings <e-...@ka...> wrote: > > > AFAIK, autotools doesn't support these things, maybe CMake but I'm not > > > sure, do you know any build infrastructure that supports this? I'd > > > really like to have this setup so we could use GCC better, for systems > > > like Nokia N800 and OpenMoko, this makes a big difference. > > > > Nothing in the "build infrastructure" is preventing anyone from adding > > an extra target in the Makefile.am for his own special needs. > > (Just expanding the idea a little more...) > > We could add a configure.sh option to enable "final" or "production" build. > This would set a var to be used in Makefile.am that could override the default > rule for building the library (or executable), something like this: > > # appending to evas/src/lib/canvas/Makefile.am > > if FINAL > libevas_canvas.la: $(libevas_canvas_la_SOURCES) > $(libevas_canvas_la_DEPENDENCIES) > # insert gcc special call here, it would be useful to see > # the default rule generated by Automake (in the generated > # Makefile.in) to see what useful vars are available, > # like: libevas_canvas_la_LDFLAGS, etc. > endif > > I'm not sure whether the rule that Automake generates is portable or it > generate a different rule for different machines, so we may have to deal > with different "final" rules. However, since it's an extra optimization, > at first won't be a problem. > > AFAIK, to use CMake a similar solution would have to be used. The version I > looked even had custom rules for dealing with "FINAL" compilation for > KDE3-related sources, but simply by creating a new source which #include'd all > the others and compiling it. we cannot use this cat *.c > final.c, and adding an special rule for each lib or binary is not a good option IMHO, we should find out a way to have automake (or cmake, scons, ...) to generate it for us. I'll try to investigate it further. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Carsten H. (T. R. <ra...@ra...> - 2007-07-15 08:27:21
|
On Sun, 1 Jul 2007 21:17:30 -0300 "Gustavo Sverzut Barbieri" <bar...@gm...> babbled: > Hi guys, these days I was reading GCC's manual and saw that it can > compile and operate on more than one file at the same time (-combine) > and optimize based on this (-fwhole-program). > > Until GCC get link-time optimization (LTO) support, this is the only > way to optimize within files, but we're unable to use this, because we > use autotools and it's stupid way to generate one object (.o) per > source (.c)... this is great while developing, reducing compile time, > just recompiling the changed sources and then linking it again, but it > sucks for the final build. > > This should shrink final source, produce more optimized code, etc. > > > Another step to improve optimization would be use profile feedback > (-fprofile-generate and -fprofile-use) , with -fprofile-arcs, > -freorder-functions... > > AFAIK, autotools doesn't support these things, maybe CMake but I'm not > sure, do you know any build infrastructure that supports this? I'd > really like to have this setup so we could use GCC better, for systems > like Nokia N800 and OpenMoko, this makes a big difference. personally i;'d say "wait until autotools supports it". it will help - how much is a question. i don't think it will help a HUGE amount - and the cost of maintaining specialised build targets in Makefile.am's will suck. if you really want to try - write a shells script to just build everything in 1 go as you want :) try it out and see. maybe this is the best way to do this for now - write specialised build.sh's or something to compile using only gcc and very specific option sets. it will probably be less work than trying to maintain it within configure/make/make install autofoo. > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Jabber: bar...@gm... > MSN: bar...@gm... > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: Andre M. <and...@gm...> - 2007-07-15 16:20:25
|
Hi, On 7/15/07, The Rasterman Carsten Haitzler <ra...@ra...> wrote: > On Sun, 1 Jul 2007 21:17:30 -0300 "Gustavo Sverzut Barbieri" > <bar...@gm...> babbled: > > > Hi guys, these days I was reading GCC's manual and saw that it can > > compile and operate on more than one file at the same time (-combine) > > and optimize based on this (-fwhole-program). > > > > Until GCC get link-time optimization (LTO) support, this is the only > > way to optimize within files, but we're unable to use this, because we > > use autotools and it's stupid way to generate one object (.o) per > > source (.c)... this is great while developing, reducing compile time, > > just recompiling the changed sources and then linking it again, but it > > sucks for the final build. kde3 build system supports this with --enable-final option on configure, so you can compile every module with one big source file. You may want to take a look at it > > This should shrink final source, produce more optimized code, etc. > > > > > Another step to improve optimization would be use profile feedback > > (-fprofile-generate and -fprofile-use) , with -fprofile-arcs, > > -freorder-functions... > > > > AFAIK, autotools doesn't support these things, maybe CMake but I'm not > > sure, do you know any build infrastructure that supports this? I'd > > really like to have this setup so we could use GCC better, for systems > > like Nokia N800 and OpenMoko, this makes a big difference. > > personally i;'d say "wait until autotools supports it". it will help - how much > is a question. i don't think it will help a HUGE amount - and the cost of > maintaining specialised build targets in Makefile.am's will suck. if you really > want to try - write a shells script to just build everything in 1 go as you > want :) try it out and see. maybe this is the best way to do this for now - > write specialised build.sh's or something to compile using only gcc and very > specific option sets. it will probably be less work than trying to maintain it > within configure/make/make install autofoo. > > > -- > > Gustavo Sverzut Barbieri > > -------------------------------------- > > Jabber: bar...@gm... > > MSN: bar...@gm... > > ICQ#: 17249123 > > Skype: gsbarbieri > > Mobile: +55 (81) 9927 0010 > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > 裸好多 > Tokyo, Japan (東京 日本) > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Gustavo S. B. <bar...@gm...> - 2007-07-15 16:22:58
|
On 7/15/07, Andre Magalhaes <and...@gm...> wrote: > Hi, > > On 7/15/07, The Rasterman Carsten Haitzler <ra...@ra...> wrote: > > On Sun, 1 Jul 2007 21:17:30 -0300 "Gustavo Sverzut Barbieri" > > <bar...@gm...> babbled: > > > > > Hi guys, these days I was reading GCC's manual and saw that it can > > > compile and operate on more than one file at the same time (-combine) > > > and optimize based on this (-fwhole-program). > > > > > > Until GCC get link-time optimization (LTO) support, this is the only > > > way to optimize within files, but we're unable to use this, because we > > > use autotools and it's stupid way to generate one object (.o) per > > > source (.c)... this is great while developing, reducing compile time, > > > just recompiling the changed sources and then linking it again, but it > > > sucks for the final build. > kde3 build system supports this with --enable-final option on > configure, so you can compile every module with one big source file. > You may want to take a look at it enable final is a hack that cat *.cpp >> one_file.cpp, I don't want that, but this new support from GCC. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |