compile speed
Hi all, I would like to increase compiling speed of my system (AMD64, dual-core, 2GB RAM). I suppose, there are some settings in /etc/apt/apt-build.conf, I can use with gcc or make (such like NICE=something) or let it run more processes at a time. Are there any experiences, somebody made at ? If yes, just let me know. Thanks ! Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compile speed
Am Sonntag, den 15.06.2008, 14:01 +0200 schrieb Hans-J. Ullrich: Hi all, I would like to increase compiling speed of my system (AMD64, dual-core, 2GB RAM). I suppose, there are some settings in /etc/apt/apt-build.conf, I can use with gcc or make (such like NICE=something) or let it run more processes at a time. Well, I guess, you can start your compiler via make -j 2 and/or put something like make_options = -j2 into /etc/apt/apt-build.conf (but I'm not sure about the correct syntax for apt-build.conf). The -j option of the make-command specifies the number of jobs to run simultaneously. You have a dual-core, so I guess -j2 is a good start. Maybe -j3 or even more may give you some more speed, you'll have to try... You could also disable optimization in gcc (the -O switch), which speeds up compiling. But that would result in slower/bigger binaries... so i guess that is not what you want... ;-) HTH, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C.P.U. suggestions.
Chris Wakefield wrote: Greetings all. I'm planning to build my next power machine, this time I may go with a Core Duo, but I looking for some suggestions and CPU stories from Y'all To my dissappointment my 'AMD 64 X2 Dual Core 3800' has been a ho-hum experience; don't know if it's the scheduler with the default debian compile that seems to effect the performance, but it's certainly nothing to write home about. .I actually found my original AMD 64 Processor 3200+ (the one with 1 MiB L2 cache) to be probably the best CPU I ever had and I think just as capable as my X2. So, I'm wondering about the Core Duo family and which is best for the desktop? (I've built about 3 machines for clients with these CPU's and they seem very snappy. I'm even talking about the 1.8 MHz variety). I'm also wondering about alternate CPU's as well and what suggestions anyone has about those as well? Any Suggestions? Thanks, Chris W. Make sure your BIOS is up to date, you need BIOS support to run a dual core CPU on the old AMD boards from around the time of the transition to dual core. Then look for an Opteron 185 on eBay. Almost the fastest non-FX socket 939 X2 CPU. Again, make sure the BIOS support is there. Or, you can buy a new motherboard and go Intel Core 2. They are seriously fast. Mark Allums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compile speed
On Sun, Jun 15, 2008 at 02:01:18PM +0200, Hans-J. Ullrich wrote: I would like to increase compiling speed of my system (AMD64, dual-core, 2GB RAM). I suppose, there are some settings in /etc/apt/apt-build.conf, I can use with gcc or make (such like NICE=something) or let it run more processes at a time. Are there any experiences, somebody made at ? If yes, just let me know. if the makefiles are proper (that is they list all dependancies for each file correctly), then make -j 4 tends to work well for me (that is run 4 things at once, which is 2 per core). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compile speed
Am Sonntag, 15. Juni 2008 schrieb Lennart Sorensen: On Sun, Jun 15, 2008 at 02:01:18PM +0200, Hans-J. Ullrich wrote: I would like to increase compiling speed of my system (AMD64, dual-core, 2GB RAM). I suppose, there are some settings in /etc/apt/apt-build.conf, I can use with gcc or make (such like NICE=something) or let it run more processes at a time. Are there any experiences, somebody made at ? If yes, just let me know. if the makefiles are proper (that is they list all dependancies for each file correctly), then make -j 4 tends to work well for me (that is run 4 things at once, which is 2 per core). -- Len Sorensen Hi Len, yes, that is the point, I wanted to know. I suppose, higher than -j 4 will let the system make too slow. Just another last: Are the entries in /etc/apt/apt-build.conf used by any(!) compiler applications, which are debian based ? I am thinking especially of commands like make-kpkg, ncurses tools like module-assistant and dpkg related things, which are executed during upgrading of packages. Cheers Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compile speed
On Sun, Jun 15, 2008 at 07:19:29PM +0200, Hans-J. Ullrich wrote: yes, that is the point, I wanted to know. I suppose, higher than -j 4 will let the system make too slow. Just another last: Are the entries in /etc/apt/apt-build.conf used by any(!) compiler applications, which are debian based ? I am thinking especially of commands like make-kpkg, ncurses tools like module-assistant and dpkg related things, which are executed during upgrading of packages. The thing is, many Makefiles are NOT proper and will result in broken builds if you try to run them in parallel. So there is no way you can just say 'always do this' because sometimes it doesn't work. I find that 2xCores is a good value, since it tries to make sure each core has something to compile even while doing disk io for another compile task. Any more than that never seems to improve things and just increases the number of context switches that need to be done. Another option is to look at gcc's -pipe option, which makes it use pipes with multiple processes rather than temporary files with each compile step process run in turn. It is completely safe no matter what the Makefile does, but won't likely gain as much, but still better than nothing. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]