What's with this flag?
I'm talking with a friend that is showing me screenshots of Chromium being compiled with -j13 showing all cores on his machine at 100% (HTOP). However, I've been using GCC for years, with -j4 now, and I don't remember ever seeing all my cores at 100% during compilation.
Is there some fundamental change between MinGW and GCC here?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Huh. I can't even find -j in gcc or g++'s man page.
Sorry. I didn't make it clear. That's Make option. Not gcc.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Did you compile chromium (with 4 jobs) or other code ?Originally Posted by Mario F.
Seems that it depends upon the number of available jobs at a time, which may not be 'many' when some complicated dependency structure is there.
Maybe Chromium's makefile is generated in such a way that that it is straight forward enough for allowing numerous parallel tasks.
Well, I haven't tried chromium yet, no. But plan to tomorrow. However I'm being guaranteed 100% core usage is a common occurrence on about any build on Linux with that flag. Where's on MinGW I don't remember ever seeing my cores being utilized like that. Ever.
I cannot test this on an actual Linux box because mine is on a VM. But I trust this guy. Besides he shown me screenshots.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I compiled the kernel with j2 recently. (on a dual core.... planning to buy a sixer soon!)
But instead of 100%, the the cpu usage graph was somewhat like a DNA and oscillated between 100% and about 75%
Would upload a screenshot the next time I do so ..
Can it be something to do with -j<max_cpu+1> instead of -j<max_cpu> ?
What you see is what I usually get too. With a lot more time spent under 100% right?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Reason ?
Would try that or j without arguments....next time.
Could say so.. but it seemed pretty symmetric.With a lot more time spent under 100% right?
I can observe that max_cpus +1 will use 100% of all cores on linux, at least when it is actually the compiler that is running.
I'd guess that you could then often have only half the real processors running, since the kernel treats all 12 as real and will assign based on that. It will not assign tasks to just even numbered processors or something.
Seems to me that popular opinion is against enabling hyper-threading on multi-core systems tho.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Then why does Intel waste their time designing 10-core Xeons with hyperthreading (thus 20 logical cores) and why do companies waste thousands of dollars buying them? Hyperthreading requires a more intelligent scheduler but there's nothing wrong with it.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Hmm, I was under the impression Intel had discontinued hyperthreading because of benchmarks that showed "complimentary" processes (doing completely different things) slightly benefited but "competing" processes (doing the same thing) were significantly penalized. I believe this had to do with cache thrashing.
However, I notice after googling that it was not so much discontinued as just "absent" from their first dual cores due to lineage, and that it has been back in place since 2008, so evidently those issues were not serious and I stand corrected!
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Yeah. There's been a lot of misconception and false claims about HT and what it does especially to single-threaded applications -- ST applications that are still at the core of much of what we use today. There's still the false belief circulating that HT can slow down ST applications. And this rumor has been perpetrated especially by the gaming community; where false rumors tend to spread like plague on a drifting ship.
It's just not true. Besides there's been a long road from when HT was introduced in single core CPUs (when there was in fact an overhead for ST applications) and today. Both the technology has been refined, but operating systems everywhere have been taking real advantage of it and coding schedulers so applications make better use of it.
The truth is simply that HT will make my OS and my MT applications faster. I did a recent upgrade to my main system and don't intend to do anything else until late last year. But my next processor will definitely be HT ready.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Let's pretend that your computer is basically doing nothing else but running make. If you have 4 cores and compile with -j4, you're getting 4 jobs. Note that all 4 jobs might not be using their respective cores at once, as one could be waiting for I/O to come back from the disk. That's not counted against your processor usage, so you will get less than 100% usage, despite having one job per core. Does your friend really have 12 cores? If he only has 8, then he's much more likely to have 8 jobs all using the CPU to actually compile, and 5 others waiting for disk I/O or their turn on a core.
6 cores, hyperthread cpu.
This must be something with MinGW.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
AFAIK, hyperthreading doesn't give two full "processors" per core, it just duplicates registers, MMU stuff, etc. It speeds up the time for context switching between threads/processes by having two complete contexts stored on the CPU instead of the others being out in cache/RAM. There is only one actual computing part of the processor (ALU) per core, so he can only crunch data on 6 threads/processes at once. Drop it down to -j6 or -j7 and see if he gets below 100%.
