gcc – how to use multiple CPU cores for compilation?

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As my program is getting bigger and bigger, the compilation time grows too. Under linux I have "“j switch which causes gcc to use multiple CPU cores, so the compilation is almost number of cores faster. The same switch doesn't work under Windows, still gcc uses only one core. Do you know any recipe how to force gcc to use all available cores?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow--You must do MUCH more sophisticated stuff than I do. Even a full rebuild of a filled Mega64 app takes maybe 30 seconds at most and I don't have the world's fastest PC. A typical app, Mega48/88 sized, isn't even worth timing.

I guess that in general I don't do a lot of rebuilds. I work on a section of coding, and when it is ready to rebuild and test I'm ready for more coffee, a stretch, check email, bathroom, ... I guess I've never thought about it much in this day and age.

Back when I was your age and working on small Burroughs mainframes our project rebuild times were measured in >>hours<<.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok., it takes 15s, but at the same time the other application for PC compiles abort 90s. No problem, but still I use only one core, others are left, and doing nothing. So why not to use them? Under linux –j2 switch shortens compilation time almost twice, -j4 on Intel Quad Core more then 3 times. So why not to use the power?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lessee--if I do 10 compiles a day and save 12 seconds on each, I have 5 hours less compile time by the end of the year.

Yep, you gain all of that time--if you never kick off the build and then flip to check email or freaks or the weather radar or get coffee. I'm not >>that<< involved in the coding continually and in fact find the short pauses reinvigorating, so let's say I'd save 20% of that.

And how long have you spent trying to speed up the process, monitoring/testing/logging the results, etc.?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can’t understand your point of view. If I have multiple cores, why not use them? I think this one reason is enough to justify my question. And, BTW, I didn’t ask if it is reasonable or not, but how to do it. And I’ll really appreciate if you can tell me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you know GCC actually uses only one core?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can check task manager, which clearly shows me that only one core is occupied, so on dual core CPU maximal CPU ocupancy is 50%, on Quad Core 25%. When compiling under linux the same, but with –j2 or –j4 switch CPU occupancy is almost 100%, and what is more important compilation time is reduced approximately by 50% and 70% respectively.
The –j switch has no effect under Windows, either when using MinGW or WinAVR gcc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely this is not something that GCC can control? Sure it can use multi-threading APIs but it's up to your operating system to then share the threads out to the various CPUs. So you may want to send an email off to Seattle and ask Mr. Gates what's going on.

But like Lee says I don't see the point. I used to compile a 57,000 C file project generating 3MB+ of MIPS4000 code that took about half an hour and I would have killed for any mechanism that might have speeded the procedure - but when even a "big" AVR project takes one minute I don't see the issue?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I worked for Racal, building the code for a Xilinx FPGA used in the radio system we were developing took two days!

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson, you didn’t understand me. I don’t blame gcc for that, I only ask if somebody knows how to get the same functionality (-j switch working) under Windows. That’s all. Second thing – AVR project is only one thing, I have another project on PC (MinGW) which compiles much longer. So if somebody will tell me how to speed up compilation in AVR-gcc I’ll be able to speed up compilation of the second application too. I don’t want to argue if 20s savings per compilation is ok or not, it is not my question.
And I make a mistake, the –j option of course works with make not gcc, and causes that make will run a specified number of commands simultaneously.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

under Windows

And that was my point - clearly Linux demonstrates that a "proper" operating system will split the worker threads. If Windows does not do this when -j2/4 are used then it is an issue with Windows, not gcc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't -j an option for make?

Some tips to reduce build times.
1) Use a makefile that only rebuilds parts that has been changed since last build.

2) Design compile units and header fils so that unnessecary cross depencensies are avoided. Particullary don't use a common header file that pulls in everything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson, your statement is very strong, and I’m not so sure that it is not an issue of Windows make version. As I assume –j just makes make to run a couple of commands simultaneously, for example at the same time two or more gcc instances are called so compilation of separate compilation units is parallel. This mechanism is so simple, that I can’t believe that OS is somehow involved.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I can’t believe that OS

In Windows press Ctrl-Shift-Escape. Exactly who do you think is doing the process management here?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
This mechanism is so simple, that I can’t believe that OS is somehow involved.
Try the following:
Start AVR-Studio and let the simulator run. This consumes the whole CPU time of one core. Start another instance of AVR-Studio with a different project and let the simulator run. Both will run on the same core (at least with the version of Windows XP I have).
Looks like Windows prefers to run multiple instances of the same program on the same core (whyever).

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stefan,

I tried that on Vista. Both CPUs were "idling" (yeah!)at about 50%. I ran Studio and started a simulation and that took core 1 to 100%. I then tried to start Studio again and it took AGES with CPU1 showing 100% all the time and CPU2 never peaking above about 90%. When it finally loaded I loaded a project during which I saw CPU2 peak at about 97% but after several minutes it still hasn't fully loaded and the whole PC has basically ground to a halt.

Boy you gotta love M$ software!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Isn't -j an option for make?

Yes it is. And it just might be that GNU Make can do what AVR Studio does not seem to be able to do. Run make with -j4 and see what happens.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok., I’ve checked make –j4 and on process list there was still only one g++ and cc1plus instance. So it means that Windows version of GNU make just ignores this switch.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Windows version

Careful - you mean the Windows version supplied with WinAVR - it's possible that there are other Win32 builds of make available that might work. (though this is Windows so I doubt it)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will download make sources and check what’s going on. BTW, I’ve checked make from MinGW project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, as often, the advide to read the fine manual is applicable. (I get away with my above post without actually checking first because I used the word "might" :wink:.) Here's what it says in one place:

Quote:
`-j [jobs]'
`--jobs[=jobs]'
Specifies the number of jobs (commands) to run simultaneously. [...] Note that this option is ignored on MS-DOS.

I suspect that "MS-DOS" here includes windows.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Johan. I've read the make manual previously but there was no mention about MS-DOS. It's interesting why this option is not supported under MS-DOS/Windows, again it seems to worth to study the make manual.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd imagine it would be down to the way threading works between the two OSes. Windows has its own thread API, while *nix uses (at the very least) a POSIX threading interface. The two aren't compatible and my guess is that the cross-platform libraries can't or don't act as a shim to translate between the two, because of a fundamental difference in how the two work.

Just a guess. However, it is embarassing that my tiny netbook can recompile the whole LUFA codebase (30 odd projects with 80,000 lines of source) in less time than my Windows dual-core Turion 1.9GHz laptop :P.

- Dean :twisted:

P.S: While POSIX may be standardized, the API sucks.

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[Repeating Deans post somewhat]

Quote:

It's interesting why this option is not supported under MS-DOS/Windows

For MS-DOS this is not strange IMO. MS-DOS has no multiprocessing support IIRC. You can spawn/fork a process, but the parent process is blocked until the child returns/ends.

For Windows I suspect that Dean is correct in that the API used is not POSIX-compliant. And please note that I said I suspect that the support for multiprocessing Make is missing in the Windows implementation.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Fri. Nov 20, 2009 - 02:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But make and GCC are single-threaded and therefore do not use multi-threading APIs. GNU make uses pipes and signals, see http://make.paulandlesley.org/jo...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Well, as often, the advide to read the fine manual is applicable. (I get away with my above post without actually checking first because I used the word "might" :wink:.) Here's what it says in one place:
Quote:
`-j [jobs]'
`--jobs[=jobs]'
Specifies the number of jobs (commands) to run simultaneously. [...] Note that this option is ignored on MS-DOS.

I suspect that "MS-DOS" here includes windows.

I wouldn't be so sure that it really does include Windows. Whenever I see MS-DOS mentioned in documentation, I am always suspicious that the documentation might be out of date. Also, there is a pthreads library for Windows that gets used quite often in ports of open source software to Windows. Perhaps some Windows builds of make use it!

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For me, cutting the compilation time from 30 seconds to 15 seconds is
a big deal and does wonders for my productivity. When the compile
time is so long that you task switch to checking mail then it's a lot
harder to stay focused. YMMV.

Saying that a punch card system took 2 days to turn around a
compilation "back in the day" doesn't feel like a productive comment.

TFrancuz, do you know that the Makefile is parallelizable? Make will
only build in parallel if it can find independent files so depending
on how the Make dependency rules are written it may not actually be
able to build anything in parallel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the same makefile under Linux and Windows, soi t is not an issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:
TFrancuz wrote:
This mechanism is so simple, that I can’t believe that OS is somehow involved.
Try the following:
Start AVR-Studio and let the simulator run. This consumes the whole CPU time of one core. Start another instance of AVR-Studio with a different project and let the simulator run. Both will run on the same core (at least with the version of Windows XP I have).
Looks like Windows prefers to run multiple instances of the same program on the same core (whyever).

Since the same code is running in both processes, it makes sense to run both processes in the same core. This saves on switching the code in and out of two different caches. If you wish to change thread affinity for one of the processes, start Windows Task Manager, right click on one of the processes, and select "Thread Affinity".
If you see only one process, it is because you aren't running separate processes. For example, Firefox won't let you start separate copies of Firefox on Windows. It just uses the existing process, and opens another window. Child processes inherit parent processor affinity, and libraries like cygwin may also enfore processor affinity.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any news about the possibility of using the -j4 option in avr-gcc for windows?

Mcguiver -> THE KING! LOL :D