4 ms·

Minor nitpick: (2015) That aside, I wonder how hard proper software development would be for such a machine. It seems like multi-threaded software is something

• rntz 10y ago
  Message-oriented no-shared-state approaches (whether you call it Actors, objects, CSP, session types, or whatever) to concurrency have proved much easier to write correct software in than the traditional threads, locks, and shared memory approach. And it's the message-oriented approach that the article proposes basing the hardware design on.
  • platz 10y ago
    Yes but Erlang provides a run-time that manages the messages between the actors/objects. Where does the run-time exist in such a machine? Would even be possible to have a run-time given the processor units exist at the lowest level?
• masklinn 10y ago
  Assuming process residency/pinning and an erlang-like model it could be pretty easy. Multi-threading I think would be rather bad as you'd have a lot of churn trying to maintain cache coherency, at least at the higher end (hundreds+ cores). At 18 cores it's nothing out of the ordinary, Xeon E5 v4 (broadwell) top out at 22 cores + HT (so 44 threads), and Sun's Ultrasparc T2 topped out at 8C8T (64 concurrent threads). Though you'd probably want to read the old Connection Machine papers too, the CM1 had up to 65kCPU (although individual CM CPUs were much, much simpler than ARM cores).
• cjensen 10y ago
  The notion that multi-threading is hard to get right is a common one, but it does not match my experience. I've been running 100+ threads in C++ routinely for 20 years now. So long as you are sensible (using mutexes for shared data structures, using queues or whatever for inter-thread messaging, using semaphores for inter-thread signaling, etc) it just isn't hard. The only thing that briefly got me in trouble was when I tried my hand at lock-free data structures. Once they are working, they are fine, but it takes a few surprises before you really understand the A-B-A problem.
  • klodolph 10y ago
    Yes, I suppose you can make multi-threading sound easy if you list all of the really easy problems. Mutexes, queues, and semaphores (or condition variables, if you have a modern code base) are all the easiest parts of multithreading. But the "so long as you are sensible" advice is terribly, terribly wrong. You have to rethink how parts of your code are isolated from one another, and you have to avoid entirely new classes of errors—such as deadlocks, which can appear when you combine two well-tested and correct multithreaded components. And the number of threads has nothing to do with it.
    • taeric 10y ago
      This is just as applicable to any of the other tools to master multithreaded programming. Actors, as an example, are great so long as you are sensible and don't push your problems into your protocol too heavily. Unless, of course, you like complicated protocols.
• 7952 10y ago
  It could allow us to represent data on the machine in a way that better matches the shape of the actual problem. So that data can be clustered together physically in two or three dimensions and can be processed locally. The current approach makes all data linear which is not a good fit for some problems.
• ianhowson 10y ago
  It's hard. The author has reinvented the architecture used by Cell (PS3) and Intel IXP. Both of these architectures are dead specifically because they are too damn hard to program for compared with a multicore ARM/x86 chip. GPUs would be the most successful modern implementation of this idea. There are opportunities with FPGAs, but GPU silicon is so far ahead (and still advancing fast) that you're usually better off designing for GPUs. You could also consider Cavium parts (16-64 way ARM chips) which ship today in high-end network hardware. The common lessons across all of these are that: * Memory is slow compared with computation * Put caches everywhere and have the machine decide what to cache * Synchronisation is hard and puts tremendous load on your scarce memory resources * It's much easier to do the same job on different data a million times than to do a million different jobs on the same data. In other words, high throughput is easier to achieve than low latency.
  • matt4077 10y ago
    I'm not sure if those architectures are comparable to the one discussed in the article, except that both are highly parallel. GPUs and Cell are, as you mention, data-parallel. The article talks about a much more "anarchistic" parallelism where thousands of different (in code and data) objects are each doing their thing, sending messages to each other when necessary. I guess that Erlang/Elixir's threads are closest currently, as mentioned in the article.
    • ianhowson 10y ago
      Cell's SPUs and IXP's microengines aren't data-parallel any more than a regular CPU. They're minimal CPUs with local RAM and fast connectivity between each other (usually a FIFO queue). Every single one of the CPUs was independent and happy to run as many branches and/or memory accesses you want without significant performance penalty, unlike modern GPUs. So yeah, you could put different objects on different CPUs if you want. Except that that's not where the bottleneck in either energy or computation is. Remember that that local RAM needs to be powered if it's to retain state (ignoring FeRAM), so CPUs are no longer free; you have to commit objects back to main DRAM before switching off the CPU. And so you've just reinvented caching and might as well just run on a fast few-core CPU anyway.
• gens 10y ago
  note: i didn't go to school for this Communicating sequential processes[0][1] more or less models that. Golang has some history with CSP (they are based on the concept of pipes and CSP was described with pipes before) while haskel/erlang and similar functional languages model the "sequential" part of processing data. [0]https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce... [1]http://usingcsp.com/ http://usingcsp.com/