Better for compiling: AMD or Intel

[mfeller2]

Which would be better for compiling code: something like the AMD A8 with 2 modules / 4 cores, or the i3 with 2 cores, but HT?

I expect only integer matters, so the shared FPU of the AMD modules is a don't care. My understanding is that each Intel core is more efficient, but I am not sure how much the hyperthreading counts in comparing to the extra 2 cores of AMD option.

FYI...this is for a low-end "build" machine, where my main goal is to do lengthy compiles somewhere else and leave my main PC free to do other things.

Thanks!

 

[Elixer]

Just what are you compiling? Are we talking the linux kernel, or something?
For a few more $$$, you can get a real quad core CPU which would be better than anything you listed.

 

[BrightCandle]

All the data I have seen about compiling is Haswell. Most compilation processes aren't all that multithreaded (atlhough that depends on the language) but the extra branch prediction and the increased backend in Haswell makes a big difference in things like Scala and Haswell. Compiling is a lot of integer operations but branch performance matters enormously and in that area Intel totally dominates.

 

[mfeller2]

All the data I have seen about compiling is Haswell. Most compilation processes aren't all that multithreaded (atlhough that depends on the language) but the extra branch prediction and the increased backend in Haswell makes a big difference in things like Scala and Haswell. Compiling is a lot of integer operations but branch performance matters enormously and in that area Intel totally dominates.

...and to answer the earlier question...I am looking at SFF options, where Gigabyte has the A8-5545M vs. i3-3217. If I have an extra box somewhere near my desk for off-loading this compile task, I want it to be a small one.

The compile tasks are a mix of GNU make-based and proprietary tools. For GNU make, my concern on i3 vs A8 is mainly if I use -j4 or -j5 for building.

 

[Nothingness]

You can get some compilation speed with MinGW/GCC here. No A8 but it might help.

BTW AMD FX chips are doing very well at compiling.

 

[Enigmoid]

Intel and Haswell are probably the best.

In terms of brute strength the a8 is weaker than the i3, both is ST and MT.

 

[Hitman928]

Not the exact models you're considering, but this might help.
http://www.phoronix.com/scan.php?page=article&item=amd_kaveri_7850k&num=4

 

[Elixer]

I doubt you can find any, but you never know... a AMD Phenom II 1090 (true hex core) for compiling is awesome.

But yeah, I would also lean toward haswell, unless this is really for a low, low, budget build, but then again, I rather have things compile quicker than wait a long time for them to compile.

 

[ViRGE]

http://www.anandtech.com/bench/CPU/503

Anand's data indicates that a Core i3 should be faster than a dual module AMD CPU, though the difference isn't going to be massive.

 

[Nothingness]

Not the exact models you're considering, but this might help.
http://www.phoronix.com/scan.php?page=article&item=amd_kaveri_7850k&num=4

Interesting, that's another data point that shows FX 8350 better at compiling than Haswell. OTOH the AnandTech results posted by ViRGE shows 4770k leading on Visual Studio.

 

[BrightCandle]

Interesting, that's another data point that shows FX 8350 better at compiling than Haswell. OTOH the AnandTech results posted by ViRGE shows 4770k leading on Visual Studio.

I can't see the 8350 winning any of those compilation benchmarks.
In the Apache compilation its even with a 2500k and 26% slower than the 4770k.
In the Kernel compilation its even with a 3770k and 20% behind the 4770k.

It beats out the i5's and other processors that compete on price but its certainly not beating the top Haswell processor in any of those charts. Good value for money in C++ compilation if you have enough code to use all the cores (many programs don't, the kernel and apache are huge projects).

 

[bononos]

Interesting, that's another data point that shows FX 8350 better at compiling than Haswell. OTOH the AnandTech results posted by ViRGE shows 4770k leading on Visual Studio.

What are you talking about? The lone benchmark which the 8350 was better at was the md5 benchmark. Intel was fastest in both compiling benchmarks. The Haswell i3 was faster than the Kaveri A10-7850.

 

[Fox5]

It depends on the compiler and settings.

Visual Studio is mostly single threaded and favors Intel processors.
Standard GNU make scales better, and based on the limited information available, it seems that dual module AMD does better there.

However, it seems like you'd really want a quad module AMD for compiling, which performs on par with core i7s.

 

[Nothingness]

I can't see the 8350 winning any of those compilation benchmarks.
In the Apache compilation its even with a 2500k and 26% slower than the 4770k.
In the Kernel compilation its even with a 3770k and 20% behind the 4770k.

I somehow thought the first graph was showing MB/s of source compiled. Medication abuse I guess

Anyway this link I previously posted shows the FX leading the pack: http://www.hardware.fr/articles/913-7/cpu-performances-applicatives.html.It's in French, but the graphs are explicit.
And after some digging: http://www.hardware.fr/articles/897-16/cpu-compilation-visual-studio-mingw-gcc.html Haswell back on top (of course the 3930K hexacore is even faster), hyper threading helps.

I nonetheless think FX-8350 is not that bad (certainly less than what I thought).

 

[parvadomus]

All the data I have seen about compiling is Haswell. Most compilation processes aren't all that multithreaded (atlhough that depends on the language) but the extra branch prediction and the increased backend in Haswell makes a big difference in things like Scala and Haswell. Compiling is a lot of integer operations but branch performance matters enormously and in that area Intel totally dominates.

Wrong. Compilation processes are multithreaded if you must compile a lot of files, and the compiler is multithreaded, it has nothing to do with the language. And about compilation itself, I doubt its branch intensive, but im 100% sure the performance depends on ALU/integer power.

 

[parvadomus]

It depends on the compiler and settings.

Visual Studio is mostly single threaded and favors Intel processors.
Standard GNU make scales better, and based on the limited information available, it seems that dual module AMD does better there.

However, it seems like you'd really want a quad module AMD for compiling, which performs on par with core i7s.

Wrong, VS is multithreaded. In my work we compile a 140 proyect solution and every proyect starts at the same time (if they can because of assemblies dependencies). We use i5s 3330 and they are fast, but my 8350 @ home is faster (maybe its just my harddisk :\).

 

[BrightCandle]

Wrong. Compilation processes are multithreaded if you must compile a lot of files, and the compiler is multithreaded, it has nothing to do with the language. And about compilation itself, I doubt its branch intensive, but im 100% sure the performance depends on ALU/integer power.

It really does depend on the language. If you compile a scala project with scalac its single threaded so as the project gets larger it just gets slower. Java uses a few threads but doesn't scale out to 8 or so cores. Certain plugins with Maven can help a little with parallel tests and such but its not a language that deals with parallel compilation in general, anything targeting the JVM struggles to get parallel behaviour. C++ compiles do multithread well because the compiles of individual files can be done separately as the files each declare (via header files) what is available. Then at link time these are actually combined and the availability is checked fully, but while this works for c/c++ it doesn't work for many other languages. Erlang for example is another language I saw almost no multithreading on.

Have you ever written a compiler? Its almost all branches. You lexer takes a character/word and then compares it against a list of possibilities to determine its type, then emits that token and the parser will take the token and compare it against all the possibilities it has and choose based on the type of it what direction to take. Basically every character goes through multiple branches in order to determine what it is so that syntax and language semantics can be checked. I have written quite a few compilers and I its a lot of branch code. Optimisers are especially branch heavy, they go through the abstract syntax tree looking for a match for their optimising pattern, which is a lot of comparisons with a no answer and a few yes ones.

Really good branch prediction and prediction calculation really help compilers along. One of the big things that Haswell beefed up was its branch predictor and its cache, two things we would seriously expect to improve a program with a lot of branches. Yet in most games and calculation heavy apps the benefits from Haswell are disappointingly low, <10% the grand majority of the time even with the additional calculation port. In C++ its +25%. If you profile the gcc compiler you'll see the reason, huge numbers of branch mispredictions from the CPU. That is most what compilers do, choose between all the options to work out which byte to emit.

This is the reason we see a 4 core/8 thread Intel CPU beating convincing a 4 module 8 core AMD chip. The AMD ought to win, its got a lot more Integer performance with those 8 integer ALUs substantially more than the Intel CPU, its just not as good at branch prediction and cache performance and it looses out heavily despite its apparent advantage. Compiling is nasty for CPUs, its one of the worst cases of calculation I know of because in and amoungst all those branches you also have some really complicated algorithms going across large amounts of data in RAM. It really uses a very specific set of resources which right now Intel's design is a lot better, basically twice as good as AMD.

 

[Nothingness]

$ time perf stat gcc -O3 -c nbench1.c

 Performance counter stats for 'gcc -O3 -c nbench1.c':

        490.992042 task-clock (msec)         #    1.000 CPUs utilized          
                22 context-switches          #    0.045 K/sec                  
                13 cpu-migrations            #    0.026 K/sec                  
            13,015 page-faults               #    0.027 M/sec                  
     1,859,386,537 cycles                    #    3.787 GHz                    
   <not supported> stalled-cycles-frontend 
   <not supported> stalled-cycles-backend  
     2,693,776,024 instructions              #    1.45  insns per cycle        
       607,479,121 branches                  # 1237.248 M/sec                  
        18,916,153 branch-misses             #    3.11% of all branches        

       0.490893967 seconds time elapsed

3.11% of mispredicts is rather low.

 

[parvadomus]

It really does depend on the language. If you compile a scala project with scalac its single threaded so as the project gets larger it just gets slower. Java uses a few threads but doesn't scale out to 8 or so cores. Certain plugins with Maven can help a little with parallel tests and such but its not a language that deals with parallel compilation in general, anything targeting the JVM struggles to get parallel behaviour. C++ compiles do multithread well because the compiles of individual files can be done separately as the files each declare (via header files) what is available. Then at link time these are actually combined and the availability is checked fully, but while this works for c/c++ it doesn't work for many other languages. Erlang for example is another language I saw almost no multithreading on.

Have you ever written a compiler? Its almost all branches. You lexer takes a character/word and then compares it against a list of possibilities to determine its type, then emits that token and the parser will take the token and compare it against all the possibilities it has and choose based on the type of it what direction to take. Basically every character goes through multiple branches in order to determine what it is so that syntax and language semantics can be checked. I have written quite a few compilers and I its a lot of branch code. Optimisers are especially branch heavy, they go through the abstract syntax tree looking for a match for their optimising pattern, which is a lot of comparisons with a no answer and a few yes ones.

Really good branch prediction and prediction calculation really help compilers along. One of the big things that Haswell beefed up was its branch predictor and its cache, two things we would seriously expect to improve a program with a lot of branches. Yet in most games and calculation heavy apps the benefits from Haswell are disappointingly low, <10% the grand majority of the time even with the additional calculation port. In C++ its +25%. If you profile the gcc compiler you'll see the reason, huge numbers of branch mispredictions from the CPU. That is most what compilers do, choose between all the options to work out which byte to emit.

This is the reason we see a 4 core/8 thread Intel CPU beating convincing a 4 module 8 core AMD chip. The AMD ought to win, its got a lot more Integer performance with those 8 integer ALUs substantially more than the Intel CPU, its just not as good at branch prediction and cache performance and it looses out heavily despite its apparent advantage. Compiling is nasty for CPUs, its one of the worst cases of calculation I know of because in and amoungst all those branches you also have some really complicated algorithms going across large amounts of data in RAM. It really uses a very specific set of resources which right now Intel's design is a lot better, basically twice as good as AMD.

I know how a compiler works. I have written a few, even the lexer/parser, which I think its a program of its own. The thing is, the branchs in a compiler are not repetitive, they depend on the code being compiled, its not like a video game with infinite loops and things that can be predicted.
The CPU branch predictor has like 50% possibility of hit, no matter how advanced the uarch is. In fact, I think the cache and its latencies are more important than branch prediction for this type of code, thats why a 4c/8t intel matches or beats AMDs 8 integer cores.

 

[Fox5]

Wrong, VS is multithreaded. In my work we compile a 140 proyect solution and every proyect starts at the same time (if they can because of assemblies dependencies). We use i5s 3330 and they are fast, but my 8350 @ home is faster (maybe its just my harddisk :\).

Visual studio is multithreaded at the project level.

GCC and make files will be threaded per file.

 

[tweakboy]

Of course Intel is first choice. Go gang green imo. gl