Live data from Hacker News

Erlang and IBM Power8 in the cloud: super-high single-system parallelism

erlang.org

11–20 of 64 posts

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#11

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).

thanks for the explanation, had major cognitive dissonance about that post.

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#12
post #11

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).

thanks for the explanation, had major cognitive dissonance about that post.

yeah, sorry, it was just a quick test; I didn't even run any erlang besides building it from scratch, starting it up and seeing that BEAM recognized the right number of schedulers. It would be interesting to run a more comprehensive test suite than a single timing run, for sure.

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#13

How 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?

Based on experience with POWER7, emptying your wallet.

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#14
While 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, 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

#15

How 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 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

#16

How 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…

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

#17

While 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…

the thing you're getting here is primarily throughput on a single image. Even if it's more expensive per-core per-hour, you can't discount that you'd have to work a lot harder to get the equivalent 30-box distributed solution to work properly, and even then it would have certain disadvantages owing to network latency.

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#18
post #16

Earlier 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.

That's why Power is now little-endian.

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#19

How 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?

Worth mentioning that POWER is the only chip I'm aware of that has hardware DFP instructions.

Re: Erlang and IBM Power8 in the cloud: super-high single-system parallelism

#20
post #18
post #16

Earlier 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.

As far as I'm aware, IBM intend on maintaining both big and little endian Linux ports (and toolchains).
Post reply on HN