Additional Evidence That Concurrency Is an Increasing Problem

By Robert Fischer | Published: September 13, 2007

Coding Horror: Choosing Dual or Quad Core

Go. Read. Be Enlightened. Understand why the functional revolution is inevitable.

Related posts:

  1. Accidental Syntax
  2. Functional Language Adoption
  3. Another solution to the Java equals/compareTo Problem (More or Less)
This entry was posted in To Be Categorized and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • Brian

    File this under “no duh!”. If you have an application that only has 2 threads, there’s no advantage to going to 4 cores.

    However, an application that has 4 threads *can* be up to 2x as fast on a quad core as on a dual core- but again, there’s no advantage to going to 8 cores. Or 16.

    What we need is not just applications that have N threads, but that can dynamically scale to have an arbitrary number of threads, anywhere from one to thousands, if not tens of thousands. Anything less than that, and the code will be facing obsolence when the number of cores on a chip (or in a system- I note that multi-socket designs are becoming more common) is greater than the number of threads the program can take advantage of.

    As a side effect, dynamic languages like Ruby and Python are screwed here. If you modify a class, say by adding a new member function, you are changing state (somehow). Unfortunately, it’s not clear *how* you’re changing state, as the state you’re changing is hidden. Which gives rise for a hard to avoid, nigh unto impossible to debug, hidden race conditions.

  • Joe

    “What we need is not just applications that have N threads, but that can dynamically scale to have an arbitrary number of threads”

    Too bad GHC is so incredibly slow, because they certainly seem to have a good start at this. I’m not sure how many threads it can handle well right now, but at least you can take the same code and run it for a single core, or 8 cores and let GHC’s libraries take care of what code should run in what thread and when.

  • http://www.linkedin.com/in/robertfischer Robert Fischer

    JoCaml is a language that has C++-level of performance and dynamic scalability.

  • http://www.linkedin.com/in/robertfischer Robert Fischer

    @Brian

    The bigger deal is how few programs can actually leverage even 3 threads. That’s surprised me: you would think graphically-intensive programs would be in a perfect position to leverage as many CPUs as you could throw at them.

  • Brian

    Chia: I wonder how many of those programs which saw no improvement going between 2 and 4 cores saw any improvement going from 1 to 2? The step from 1(single-threaded) to 2 (multi-threaded) is much bigger than the step from 2 to 4. In many ways going from 1 to 2 cores is a bigger step than going from 2 to 2048 cores- as the step from 1 to 2 introduced whole new categories of problems, while going from 2 to 2048 cores is just the same problems only more so.

    Joe: I’ll pit GHC against Ruby any day of the week. Haskell is definately the place where things are happening right now.

  • Joe

    Jocaml requires you to explicitly deal with concurrency though. GHCs SMP support lets you run your code without any changes in a single thread, or spread across a pool of backend threads. If you did “map foo bar” ordinarily, it would apply foo to each element of bar one at a time. But if you ran it with -N4, it would handle four elements at a time, using all 4 of your CPU cores (obviously assuming you are running -N4 because you have 4 cores).

    Brian: I don’t know what you mean by pitting GHC against ruby. Ruby doesn’t have a compiler to be slow, its just an interpreter. I don’t mean that GHC produces slow binaries, I mean GHC is slow. It takes ages to compile even simple code, making it a serious hinderance to development.

    I think haskell is easily the best language I’ve ever seen, and I would love to use it. But there’s just not a solid implimentation of the language, so I am stuck using ocaml, which only has one implimentation, but its at least a very fully featured, fast implimentation . Not that ocaml (the language) is bad, but haskell is elegant and beautiful, where as ocaml (the language) is simply adequate.

  • Brian

    Joe: Ah. Generally, when someone say “Language X is slow”, I assume they mean “programs written in language X are slow”. That isn’t what you wrote, tho.

    Note that Ruby does have a compilation step- it just happens when you run the program.

  • Categories