For those as confused as I was at first, the critical line is "total time". 2.8s for the P8 vs 38.7s for the x86. Otherwise the x86 comes out looking a lot better -- lower 95th percentile, lower max, lower average. (Modulo usual complaints about benchmark porn: single run, lack of standard deviation, unknown configuration differences etc etc).
Erlang and IBM Power8 in the cloud: super-high single-system parallelism
11–20 of 64 posts
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#12For those as confused as I was at first, the critical line is "total time". 2.8s for the P8 vs 38.7s for the x86. Otherwise the x86 comes out looking a lot better -- lower 95th percentile, lower max, lower average. (Modulo usual complaints about benchmark porn: single run, lack of standard deviation, unknown configuration differences etc etc).
thanks for the explanation, had major cognitive dissonance about that post.
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#13How does POWER8 compare to x86, e.g. Haswell? Just skimming some of the architecture details... * 4x hardware threads per core (8-way SMT vs. 2) * 1/4th FP throughput per core (8 SP flops/cycle vs. 32) * 3x bandwidth to RAM (230 GB/s vs. 68) [edit: updated for Haswell-EP] https://en.wikipedia.org/wiki/POWER8#Specifications http://www.redbooks.ibm.com/abstracts/tips1153.html What is it good for?
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#14By my experience with Power7, the price/performance ratio is much lower on Power then Intel systems. Maybe it changed but i'm not holding my breath, even if IBM seems much more aggressive on pricing with P8 then they were with P5-P7. The
Quick calculation, absolutely unscientific:
Seeing that the price is 0.14$/hour for the 6-core xeon and 1.08$/hour on the 176 core P8, it would have to be roughly 8-10x faster to justify the cost difference, not sure it will be the case.
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#15How does POWER8 compare to x86, e.g. Haswell? Just skimming some of the architecture details... * 4x hardware threads per core (8-way SMT vs. 2) * 1/4th FP throughput per core (8 SP flops/cycle vs. 32) * 3x bandwidth to RAM (230 GB/s vs. 68) [edit: updated for Haswell-EP] https://en.wikipedia.org/wiki/POWER8#Specifications http://www.redbooks.ibm.com/abstracts/tips1153.html What is it good for?
Haswell-EP supports 4 DDR4-2133 channels, or 68 GB/s (theoretical). TDP on POWER8 is almost double and it's much more expensive, so we should think about it as having perhaps double the DRAM bandwidth (still excellent).
Note that POWER8 gets this bandwidth through many more channels, which favors the use of many memory streams. This has been the case historically, with POWER favoring data structures that result in many streams, while the same transformation has been catastrophic for memory performance on Blue Gene's PPC, with its limited prefetch engine and small number of outstanding memory requests.
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#16How does POWER8 compare to x86, e.g. Haswell? Just skimming some of the architecture details... * 4x hardware threads per core (8-way SMT vs. 2) * 1/4th FP throughput per core (8 SP flops/cycle vs. 32) * 3x bandwidth to RAM (230 GB/s vs. 68) [edit: updated for Haswell-EP] https://en.wikipedia.org/wiki/POWER8#Specifications http://www.redbooks.ibm.com/abstracts/tips1153.html What is it good for?
> 9x bandwidth to RAM (230 GB/s vs. 25.6) Haswell-EP supports 4 DDR4-2133 channels, or 68 GB/s (theoretical). TDP on POWER8 is almost double and it's much more expensive, so we should think about it as having perhaps double the DRAM bandwidth (still excellent). Note that POWER8 gets this bandwidth through many more channels, which favors the use of many memory streams. This has been the case historically, with POWER…
The problem I see with power is it has a different endiannes and even though compilers know how to handle it, a lot of libraries and code might just assume some specific ordering (little endian) and thus fail un-expectedly on POWER.
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#17While the performance seen here is nice, i'm curious to see the price/performance ratio. Running against a 8-core XEON would not make sense if the closer Intel system price-wise is a quad 12-core xeon... Obviously we are talking cloud here so it might not even apply. By my experience with Power7, the price/performance ratio is much lower on Power then Intel systems. Maybe it changed but i'm not holding my breath, eve…
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#18Earlier quoted context omitted.
> 9x bandwidth to RAM (230 GB/s vs. 25.6) Haswell-EP supports 4 DDR4-2133 channels, or 68 GB/s (theoretical). TDP on POWER8 is almost double and it's much more expensive, so we should think about it as having perhaps double the DRAM bandwidth (still excellent). Note that POWER8 gets this bandwidth through many more channels, which favors the use of many memory streams. This has been the case historically, with POWER…
That is interesting. RAM bandwidth could significantly impact a lot of applications. I guess the only ways it to measure and compare. The problem I see with power is it has a different endiannes and even though compilers know how to handle it, a lot of libraries and code might just assume some specific ordering (little endian) and thus fail un-expectedly on POWER.
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#19How does POWER8 compare to x86, e.g. Haswell? Just skimming some of the architecture details... * 4x hardware threads per core (8-way SMT vs. 2) * 1/4th FP throughput per core (8 SP flops/cycle vs. 32) * 3x bandwidth to RAM (230 GB/s vs. 68) [edit: updated for Haswell-EP] https://en.wikipedia.org/wiki/POWER8#Specifications http://www.redbooks.ibm.com/abstracts/tips1153.html What is it good for?
Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism
#20Earlier quoted context omitted.
That is interesting. RAM bandwidth could significantly impact a lot of applications. I guess the only ways it to measure and compare. The problem I see with power is it has a different endiannes and even though compilers know how to handle it, a lot of libraries and code might just assume some specific ordering (little endian) and thus fail un-expectedly on POWER.
That's why Power is now little-endian.