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

Joe Armstrong: Solving the wrong problem

joearms.github.com

Post reply on HN
Print view View original

111–120 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#111

Post by fulafel »

konstruktor wrote: post #107
fulafel wrote: post #100

Earlier quoted context omitted.

If you want to refute the point you can't arbitrarily restrict the comparison to processors with the same clock rate.

The current Core iX CPUs offer higher clock rates than the Core 2 CPUs from 2008? Using the highest clock available would have skewed the result against Armstrongs argument.

That depends on which CPUs you are looking at, he says "clock rates started sinking" from about 2004. At any rate pinning the clock rate doesn't make any sense in the comparison, even if you think it's for his benefit.

The single thread performance story may be different if you take 2004 era Xeon/Opteron chips and follow the single-thread performance as they go to the 8-12 core chips later on.

Re: Joe Armstrong: Solving the wrong problem

#112

Post by vanderZwan »

smosher wrote: post #85
kkowalczyk wrote: post #25

Earlier quoted context omitted.

Go allows you to share memory between goroutines (i.e. concurrent code). It doesn't force you to do so. In fact, the Go team explicitly tells you not to do that: "do not communicate by sharing memory; instead, share memory by communicating." ( http://blog.golang.org/2010/07/share-memory-by-communicating... ) i.e. they tell you to use the Erlang model. But as everything, there are trade-offs. Even Go team uses shared…

In fact, the Go team explicitly tells you not to do that: "do not communicate by sharing memory; instead, share memory by communicating." Sadly, that doesn't mean what you think it means. It really means: don't organize your IPC around shared state. The juxtaposition in the second half is not directly related to the first half (except poetically), though it does do a good job of completing the their picture of CSP. A…

I guess the Go authors decided that for the sake of performance, you have to risk hurting your foot at least a little bit?

Re: Joe Armstrong: Solving the wrong problem

#113

Post by willvarfar »

seanmcdirmid wrote: post #72
mncolinlee wrote: post #18

I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period. Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without…

Erlang is not designed for parallel programming; it is designed for concurrent programming. These are two very different programming domains with different problems. Every time someone conflates parallelism with concurrency...everyone gets very confused.

Isn't Joe's post specifically about parallelism and how Erlang is designed for it?

Re: Joe Armstrong: Solving the wrong problem

#115

Post by larsberg »

necrodome wrote: post #60
larsberg wrote: post #35

Earlier quoted context omitted.

I completely agree. As someone who works on a parallel functional language, it's very hard to sell a parallel language that isn't as fast as parallel fortran or hand-tuned C code that uses pthreads and the fastest parallel implementation of BLAS and other libraries. The people who really care about performance are using those. The ones who don't are honestly mostly still writing code that has large constant factors o…

Does/can Manticore have a such unique application domain?

We believe so! Our project leader is focused on how we can parallelize general-purpose applications easily. With more and more people writing in static functional languages that have relatively poor parallel scalability without massive program transformations (Haskell, OCaml, F#, etc.), we think there is an opportunity there.

That said, we're at a "go big or go home point." We either need to ramp up from the 1.5 grad students + 2 undergrads / year significantly or wrap things up. Getting to a point where we can be used in general-purpose projects requires a lot of work, none of which results in papers.

If I had to guess, the most probable impact is what you would expect from PL research - integration of lessons learned in other systems down the road:

- CilkPlus has a nice first pass at a work stealing algorithm, but we showed how to do it without static tuning by the programmer with lower overheads, to boot.

- Vectorization to take advantage of wider vector hardware requires transformation of data structures (e.g., array of structs to struct of arrays). We showed how to do that automatically and reason about changes in program performance.

- We have boatloads of papers - at both workshops and conferences - on what has to be done to the compiler and runtime to run efficiently on NUMA multicore systems. Right now, most fp systems do not run into these problems because they cannot scale past their own parallel overheads. Once past that bottleneck, the next one will be memory traffic, at least in our experience.

I don't say any of that to fling mud at other systems; we started our project after them all, at the start of the multicore era (2006), with the goal of investigating these specific issues without carrying along the baggage of a pre-existing sequential implementation.

There's also still a lot more to learn. I personally don't buy that that deterministic and total chaos are the two only points in the design space of program reasoning. There have to be some interesting midpoints (e.g., histories that are linearizable) that are worth investigating.

Re: Joe Armstrong: Solving the wrong problem

#116

Post by peerst »

seanmcdirmid wrote: post #89
unoti wrote: post #86

Earlier quoted context omitted.

Isn't it really fair to say that it's designed for both? The way it uses immutable state and something-similar-to-s-expressions to express data make it very straightforward (or even transparent) to distribute work between multiple processes and separate computers, in addition to how it makes it practical and simple to break work into small chunks that can be interleaved easily within the same thread. It's really desi…

Not at all. Erlang isn't useful for modern parallel computing as we know it, which is usually done as some kind of SIMD program; say MapReduce or GPGPU using something like CUDA. The benefit doesn't just come from operating on data all at once, but these systems (or the programmer) also do a lot of work to optimize the I/O and cache characteristics of the computation. Actor architectures are only useful for task para…

"modern parallel computing" ... well not everything that can run parallel on multi core CPU's can run very well on a GPU.

I'm using Erlang and GPU programming each for its area of expertise. FWIW I even use both together via https://github.com/tonyrog/cl

Erlang is great at asynchronous concurrency which happens to be able to run in parallel well because of how the VM is built.

GPU's solve totally different problems

Re: Joe Armstrong: Solving the wrong problem

#117

Post by InclinedPlane »

lifeisstillgood wrote: post #109
InclinedPlane wrote: post #106

Earlier quoted context omitted.

Yes, precisely. It's like designing a race car, or a fighter jet. Sure, they are amazing things. But are people ever going to commute to work in anything resembling a Bugatti Veyron or an F-22? Of course not. Neither maximum automotive performance nor air combat effectiveness are the sorts of things that are normally necessary to optimize for in daily life. Some time in the far future we're going to have both the too…

Puuuuhhhleeeeaaaseeee can I commute to work in a Bugatti Veyron?? Please please please :-) Edit: sorry unable to resist. However I am on Joe Armstrongs side - I would far rather make a decent living doing fun Erlang work than be in a java shop making the next generation of POS Added to that I think not using Erlang or some STM based concurrency language must be an informed decision - if the CTO of big bank says we ha…

Of course, most people would like to be working on race cars, or spacecraft, or fighter jets, but that just isn't an option for every body. And it's not as though there's no in between. The choice isn't just between some soul sucking blub-job in the enterprise trenches or using Erlang, there are lots of languages, lots of development patterns, lots of products.

Re: Joe Armstrong: Solving the wrong problem

#118

Post by masklinn »

fulafel wrote: post #101
masklinn wrote: post #95

Earlier quoted context omitted.

> Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes Except since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this. > That is, the default concurrency model militated by Go is not shared memory, but that…

> since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this. Channels are pass-by-value. If you pass a struct, it's copied, and both sides can mutate their own copies as much as they want. You can get still bugs if you make channels of pointers (or have pointers in your message str…

> You can get still bugs if you make channels of pointers (or have pointers in your message structs etc).

Confirming that

> the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this.

Re: Joe Armstrong: Solving the wrong problem

#119

Post by seanmcdirmid »

peerst wrote: post #116
seanmcdirmid wrote: post #89

Earlier quoted context omitted.

Not at all. Erlang isn't useful for modern parallel computing as we know it, which is usually done as some kind of SIMD program; say MapReduce or GPGPU using something like CUDA. The benefit doesn't just come from operating on data all at once, but these systems (or the programmer) also do a lot of work to optimize the I/O and cache characteristics of the computation. Actor architectures are only useful for task para…

"modern parallel computing" ... well not everything that can run parallel on multi core CPU's can run very well on a GPU. I'm using Erlang and GPU programming each for its area of expertise. FWIW I even use both together via https://github.com/tonyrog/cl Erlang is great at asynchronous concurrency which happens to be able to run in parallel well because of how the VM is built. GPU's solve totally different problems

Yes, erlang is great for concurrency, GPUs are great for significant scalable parallelism. They both solve different problems, I agree, and that's my point.

Re: Joe Armstrong: Solving the wrong problem

#120

Post by seanmcdirmid »

willvarfar wrote: post #113
seanmcdirmid wrote: post #72

Earlier quoted context omitted.

Erlang is not designed for parallel programming; it is designed for concurrent programming. These are two very different programming domains with different problems. Every time someone conflates parallelism with concurrency...everyone gets very confused.

Isn't Joe's post specifically about parallelism and how Erlang is designed for it?

The post is about concurrency, but the word parallelism is used instead. To be fair, task level parallelism makes concurrent code run faster, but doesn't really scale if done for its own sake.
Post reply on HN