Comments on: The “Many Core” Problem http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/ A blog on .Net and SQL Server Thu, 11 Mar 2010 14:47:30 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Clay Lenhart http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15325 Clay Lenhart Sun, 02 Nov 2008 20:03:56 +0000 http://clay.lenharts.net/blog/?p=43#comment-15325 > In which category does software transactional memory fall? This is a oversight -- thanks for reminding me. For .Net people, you may be interested in the Transaction Memory blog http://blogs.msdn.com/stmteam/default.aspx. > In which category does software transactional memory fall?

This is a oversight — thanks for reminding me.

For .Net people, you may be interested in the Transaction Memory blog http://blogs.msdn.com/stmteam/default.aspx.

]]> By: Clay Lenhart http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15324 Clay Lenhart Sun, 02 Nov 2008 19:59:38 +0000 http://clay.lenharts.net/blog/?p=43#comment-15324 > That Erlang is supposed to be awkward is repeated in many blogs, as if it were an indisputable fact. I've got to admit, you make a fair point here. For what it is worth, my merger explanation is: a) Erlang hasn't taken off yet, so people must have some issue with it. b) "Standard" languages can do most anything concurrency-wise, which means that a restrictive model, like actors/message passing, must be more awkward. Pretty weak. Keep in mind that the point I'm trying to make is we'll get through this crisis. Heck, Erlang may very well be the answer. > That Erlang is supposed to be awkward is repeated in many blogs, as if it were an indisputable fact.

I’ve got to admit, you make a fair point here. For what it is worth, my merger explanation is:
a) Erlang hasn’t taken off yet, so people must have some issue with it.
b) “Standard” languages can do most anything concurrency-wise, which means that a restrictive model, like actors/message passing, must be more awkward.

Pretty weak.

Keep in mind that the point I’m trying to make is we’ll get through this crisis. Heck, Erlang may very well be the answer.

]]> By: Ulf Ochsenfahrt http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15323 Ulf Ochsenfahrt Thu, 30 Oct 2008 09:36:16 +0000 http://clay.lenharts.net/blog/?p=43#comment-15323 In which category does software transactional memory fall? In which category does software transactional memory fall?

]]> By: Kamil Szot http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15322 Kamil Szot Mon, 27 Oct 2008 09:54:41 +0000 http://clay.lenharts.net/blog/?p=43#comment-15322 Most of apps today are multiuser and/or built of multiple software components. You can just run different users, or diffrent software components on different cores and you get the boost but almost never have to bother yourself with multithreading. The only case that remains a problem is when some component of your system responds to slow, then you have try to replace it with some equivalent that uses algorithm that can be distributed. This single tiny bit of system can be written as well in erlang regardles of it's obscurity. There is a chance that you won't even have to write it by yourself because some erlang hackers wrote it already because they needed it before you and published it as open source. Most of apps today are multiuser and/or built of multiple software components.
You can just run different users, or diffrent software components on different cores and you get the boost but almost never have to bother yourself with multithreading. The only case that remains a problem is when some component of your system responds to slow, then you have try to replace it with some equivalent that uses algorithm that can be distributed. This single tiny bit of system can be written as well in erlang regardles of it’s obscurity. There is a chance that you won’t even have to write it by yourself because some erlang hackers wrote it already because they needed it before you and published it as open source.

]]> By: Ulf Wiger http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15321 Ulf Wiger Mon, 27 Oct 2008 09:46:41 +0000 http://clay.lenharts.net/blog/?p=43#comment-15321 That Erlang is supposed to be awkward is repeated in many blogs, as if it were an indisputable fact. Yet the University of Kiel uses Erlang to teach programming to high-school girls, and their final task after a week is programming a distributed chat server. There may, or may not, be an awkward transition depending on what you're used to, but there's plenty of evidence that Erlang itself can give good productiviy, compact code, and excellent life-cycle economy. A very recent study compared implementations of IMAP: http://www.erlang.org/workshop/2008/Sess21.pdf Its conclusion is no surprise to those familiar with Erlang. On several occasions, Erlang teams participating in standardization work have ended up being identified as the de-facto reference implementation, since they are able to implement working feature-complete code much faster than the others. There are other languages that have outstanding qualities, but if you're going to call Erlang awkward and complex, you should be fairly specific about what you're comparing it to - it may carry some weight if coming from a seasoned Haskell programmer, but even then it will depend on the problem domain. That Erlang is supposed to be awkward is repeated in many blogs, as if it were an indisputable fact. Yet the University of Kiel uses Erlang to teach programming to high-school girls, and their final task after a week is programming a distributed chat server. There may, or may not, be an awkward transition depending on what you’re used to, but there’s plenty of evidence that Erlang itself can give good productiviy, compact code, and excellent life-cycle economy.

A very recent study compared implementations of IMAP:
http://www.erlang.org/workshop/2008/Sess21.pdf

Its conclusion is no surprise to those familiar with Erlang. On several occasions, Erlang teams participating in standardization work have ended up being identified as the de-facto reference implementation, since they are able to implement working feature-complete code much faster than the others.

There are other languages that have outstanding qualities, but if you’re going to call Erlang awkward and complex, you should be fairly specific about what you’re comparing it to - it may carry some weight if coming from a seasoned Haskell programmer, but even then it will depend on the problem domain.

]]> By: Clay Lenhart http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15320 Clay Lenhart Sun, 26 Oct 2008 19:34:06 +0000 http://clay.lenharts.net/blog/?p=43#comment-15320 > Erlang got one thing right - the concurrency mechanism You may be interested to know that .Net copied Erlang style concurrency and put it in a library for any .Net language call MPI.Net: http://www.osl.iu.edu/research/mpi.net/ > Erlang got one thing right - the concurrency mechanism

You may be interested to know that .Net copied Erlang style concurrency and put it in a library for any .Net language call MPI.Net: http://www.osl.iu.edu/research/mpi.net/

]]> By: Andras http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15319 Andras Sun, 26 Oct 2008 15:13:36 +0000 http://clay.lenharts.net/blog/?p=43#comment-15319 Erlang got one thing right - the concurrency mechanism (I've written a post on this earlier: http://a-vajda.eu/blog/?p=27) It *IS* a pitty that they chose to make it a functional language (it's *incorrect* to claim that functional languages enable parallelism - why would they still need process constructs like in Erlang and Haskell?!) - same (otherwise powerful and beautifully simple) principles would have worked with traditional languages. Cheers, Andras Erlang got one thing right - the concurrency mechanism (I’ve written a post on this earlier: http://a-vajda.eu/blog/?p=27) It *IS* a pitty that they chose to make it a functional language (it’s *incorrect* to claim that functional languages enable parallelism - why would they still need process constructs like in Erlang and Haskell?!) - same (otherwise powerful and beautifully simple) principles would have worked with traditional languages.
Cheers, Andras

]]> By: henk http://clay.lenharts.net/blog/2008/10/25/the-many-core-problem/comment-page-1/#comment-15318 henk Sun, 26 Oct 2008 14:53:01 +0000 http://clay.lenharts.net/blog/?p=43#comment-15318 I agree there's a problem with the complexity of threading, but it already helps *a lot* if the communication pattern between your objects is well defined instead of chaotic. And guess, we should already be adhering to the well defined communication pattern for regular sequential (OO) programming ;) Next to that, in some cases building multi-threaded software is easier. Firing off some piece of code in a kind of job and then forgetting about it, may be far simpler than executing it inline of your regular sequential code and trying to interweave some other tasks while processing this piece of code. I agree there’s a problem with the complexity of threading, but it already helps *a lot* if the communication pattern between your objects is well defined instead of chaotic.

And guess, we should already be adhering to the well defined communication pattern for regular sequential (OO) programming ;)
Next to that, in some cases building multi-threaded software is easier. Firing off some piece of code in a kind of job and then forgetting about it, may be far simpler than executing it inline of your regular sequential code and trying to interweave some other tasks while processing this piece of code.

]]>