Live data from Hacker News

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

erlang.org

41–50 of 64 posts

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

#41
post #24

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.

This is interesting and I'd like to hear more opinions on it. My impression is that distributed computing has been eating Power/Sparc/Z processors' lunch for a long time now because software has made up for the deficiencies of coordinating 30 boxes. Do you and do any others believe that we are at an inflection point where the pendulum swings back in the direction of 'high-performance' processors like Power8, or will…

If you have a problem that behaves poorly in the face of the Network Fallacies, then you want to scale vertically.

RDBMSes are a classic example. Some kinds of compute-heavy problems too -- simulations with lots of coupled components, video compression etc.

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

#42

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.

[deleted]

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

#43

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.

Sounds interesting! What's needed from the user in order to use this feature? Will it be possible to use from high level languages like java or do you have to use assembly? Can think of quite a lot of applications that would benefit A LOT from this.

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

#44
post #43

Earlier quoted context omitted.

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

Sounds interesting! What's needed from the user in order to use this feature? Will it be possible to use from high level languages like java or do you have to use assembly? Can think of quite a lot of applications that would benefit A LOT from this.

High level languages like Python, Ruby, and Go could take advantage of this without having to make any code changes, provided that the appropriate libraries are updated to use this new hardware.

Java, however, is a special case. Since Java bytecode does not have a BigDecimal type, there's no way to update the JVM to take advantages of this hardware unfortunately.

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

#45
post #39

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

Your huge page comment also reminded me that Power has 64k page support, rather than the 4k or 2MB that amd64 has, and this is normally the pag size (eg in RHEL) which reduces TLB pressure a lot.

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

#46
post #29

Earlier quoted context omitted.

Power has been little endian for a while. No one bothered to tell the software guys to write a little endian OS and tools for it....

My point is that little-endian Ubuntu is now available.

Yes, and IBM is pushing this (plus the v2 ABI which is a bit more like x86 and simplified in some small ways).

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

#47
post #34
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...)

Most of them, although not the Apple G5s which are BE only.

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

#48

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

Your post should be voted top, it's the most informative. I've spent the whole day scratching my head. The power8 confusion in many ways reminds me of the p4 netburst architecture, not architecturally in any way, but in the sense that "when they are good they are really good". But both by and large are not any great shakes.

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

#49
post #24

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.

This is interesting and I'd like to hear more opinions on it. My impression is that distributed computing has been eating Power/Sparc/Z processors' lunch for a long time now because software has made up for the deficiencies of coordinating 30 boxes. Do you and do any others believe that we are at an inflection point where the pendulum swings back in the direction of 'high-performance' processors like Power8, or will…

The dominant use case for the last decade or so has been web servers hitting caches to do low-CPU low-causality CRUD operations. That looks unlikely to change in the next decade, so keep your Intel stock.

That said, for a lot of interesting use cases, like that king-hell postgres database sitting in the middle of the swarm, or video processing, or streams processing, or indeed any situation in which thousands-to-millions of simultaneous actors need to work on the same shared state, this sort of system starts looking real interesting.

As a thought experiment, think of this system like a GPU, except every single processor is a fully capable 2 GHz i5 running Unix, and instead of having to deal with the CUDA or OpenCL API, you can just write erlang (or haskell; .. or whatever) code and it will run. And instead of having 2-8G of RAM, you have 48G. And instead of having arcane debug tools, you have recon and gdb and ddd.

I don't think there is a pendulum, I think there's a spectrum and has always been one; pragmatism should always rule, and your use case is not my use case. There isn't going to be an objective winner ever, no matter how close Intel may get to covering much of the sweet spot.

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

#50

Earlier quoted context omitted.

> Programmers have also been taught that spawning processes is cheap so idiomatic Erlang code typically have tons of them. The green threads in Haskell are just as cheap, in some cases, cheaper than Erlang's processes. Haskell programmers are similarly encouraged. Concurrency and parallelism are pretty easy in Haskell. http://chimera.labs.oreilly.com/books/1230000000929 http://hackage.haskell.org/package/slave-thread

Yes, indeed. Marlow's book is really good one.

I love my haskell brethren dearly, but haskell isn't organized structurally around an essentially-mandatory fundamentally concurrent, debuggable, quasi-preemptive core like OTP. Not that it won't get there eventually (cf. Cloud Haskell) but it's more than just being able to run concurrent threads. Note: this is not a language flame, just a personal opinion/observation, and I love and welcome correction.
Post reply on HN