Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

erlang.org

Post reply on HN
Print view View original

31–40 of 64 posts

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

#31

Post by neurotixz »

felixgallo wrote: post #17
neurotixz wrote: post #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, 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.

I would be extremely surprised that you would need 30 x86 boxes to reach the performance of a P8 box, on any type workload. By my experience with P5-P7 they can be faster for certain workloads then x86, but not that much.

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

#32

Post by rdtsc »

wmf wrote: post #18
rdtsc wrote: 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.

I had no idea. Haven't looked it since many years ago.

Well, heck, that's great then.

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

#34

Post by pavlov »

wmf wrote: post #18
rdtsc wrote: 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.

Wasn't PowerPC always able to switch between little-endian and big-endian at boot? Maybe they migrated that capability to POWER.

(It's been a long time since I last typed "PowerPC", gave me a strange feeling of nostalgia...)

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

#35

Post by apaprocki »

neurotixz wrote: post #31
felixgallo wrote: post #17

Earlier quoted context omitted.

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.

I would be extremely surprised that you would need 30 x86 boxes to reach the performance of a P8 box, on any type workload. By my experience with P5-P7 they can be faster for certain workloads then x86, but not that much.

You can't really compare the different chip revs apples-to-apples. P6 was a completely different chip architecture with much higher clock speeds that IBM abandoned because it didn't perform well. They make a lot of changes in each chip rev.

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

#36

Post by apaprocki »

pavlov wrote: post #34
wmf wrote: post #18

Earlier quoted context omitted.

That's why Power is now little-endian.

Wasn't PowerPC always able to switch between little-endian and big-endian at boot? Maybe they migrated that capability to POWER. (It's been a long time since I last typed "PowerPC", gave me a strange feeling of nostalgia...)

POWER architecture can switch between BE/LE via a special purpose register (SPR). This can even be done to support mixing BE/LE threads on the core. The software complexity of managing that, though, has made them decide to enable the entire OS as BE or LE. One cool thing is that the support will be extended so that the chips can support running either BE or LE guest VMs natively.

edit: Straight from IBM https://www.ibm.com/developerworks/community/blogs/fe313521-...

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

#37

Post by desdiv »

apaprocki wrote: post #19
throwaway_yy2Di wrote: post #5

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.

In case anyone else is confused: DFP = Decimal Floating Point, i.e. native base 10 arithmetics on the FPU.

Googling "DFP instructions" led me to nothing but DoubleClick links.

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

#39

Post by nkurz »

throwaway_yy2Di wrote: post #5

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?

IBM has solid documentation of more of the Power8 details here: http://www.setphaserstostun.org/power8/POWER8_UM_external_22...

Going only by specs, it seems that in many other cases each Power8 core has about 2-4x the resources of a Haswell core:

  64KB vs 32KB L1D
  512KB vs 64KB L2
  8MB vs 2.5MB L3
  16 vs 10(?) outstanding L1 requests
  8 vs 4 instructions issued per cycle
  2 vs 1 stores per cycle (or 4 vs 2 loads if no stores)
  3 vs 4/5 cycle L1 latency for 64-bit data
  5 vs 6/7 cycle L1 latency for vector data
  2048 vs 512 TLB entries (integrated with huge pages)
Specs that aren't higher than Haswell are usually the same --- skimming, I haven't found any that are lower. This makes me think that a 4xSMT or 8xSMT Power8 core will probably be about equivalent to a 2xSMT (hyperthreaded) Haswell core. Dedicated core operation (non-hyperthreaded) will vary more based on workload, but likely be 1x to 2x in favor of Power8. But these are guesses based on written specs -- I'm eager to see more real benchmarks.

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

#40

Post by davidw »

rdtsc wrote: post #16
jedbrown wrote: post #15

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.

A lot of those problems were solved years ago. I remember a big push in the late 90ies, on Debian, to ensure proper endianness, because of the many architectures on which it ran.
Post reply on HN