7 ms·

That is untrue. Check http://blogs.azulsystems.com/cliff/ http://blogs.azulsystems.com/cliff/ for really impressive work on jvm that works on 800+ cores ... oh

That is untrue. Check http://blogs.azulsystems.com/cliff/ http://blogs.azulsystems.com/cliff/ for really impressive work on jvm that works on 800+ cores ... oh yes, and you have constant time garbage collection.

glymor 18y ago
Azul's system is proprietary and only runs on special hardware. The openjdk that's in common use has had essentially no work done on green threads. And from your link "we have a lite microkernel style OS; we can easily handle 100K runnable threads" it's not the VM that's handling it.
- framiere 18y ago
  You are correct, I was pointing to cliff click's blog as he his giving back to the community. Look at http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.h... : an implementation of a non blocking hashmap without lock that scales beautifully on a bunch of cores without the need of their hardware (http://sourceforge.net/projects/high-scale-lib http://sourceforge.net/projects/high-scale-lib) As per actor on the JVM open source projects are blooming around such as http://code.google.com/p/actorom/ http://code.google.com/p/actorom/. Alex Miller did a nice review here of the solutions out there: http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-concurrency2.html http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-co...
  - glymor 18y ago
    I remember his hashmap when he published it, state machines are a great way to do concurrency. The Erlang way of handling concurrency is to spawn millions of "processes" (threads) obviously these can't be hardware threads so Erlang is hitting problems OS schedulers would handle (or not be able to handle) in the JVM's case. I would argue that the JVM is eventually going to have to handle the threading itself if it's to support any actor based programming. OS schedulers have other uses they need to be fast for and hardware threads will always have higher overhead. Python's Stackless is perhaps an example of the amount of work it would require.
    - johnm 18y ago
      You might want to take a look at e.g., Scala and how it implements actors on the JVM. It's basically doing a MxN actor to thread-pool scheduling.
      - glymor 18y ago
        The dispacter is probably a bottleneck, looking at the paper http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf I can't really tell how it's implemented. How does the Scala run queue work? eg have a look at the Erlang article I linked to in my first post.
- johnm 18y ago
  You seem to be implying that one needs e.g., "green threads" to support huge numbers of "actors". That implication is false. Also, the only way that Erlang can support running on multiple actual hardware cores is, just as in Java "actor" implementations, to do an MxN mapping of actors to cores. Now, at one end of the spectrum there's the basic rule of thumb for each system to have O(number of cores) hardware threads and map all of the actors down to that, there are good arguments (by people like Paul Tyma) that promote using 10s or even 100s of thousands of hardware threads in Java on real, shipping OSs (late model Linux is his focus). Of course, Erlang as both a language and its VM, are matched to each other and their specific problem domain (lots of little actors focused on coordination rather than computational or data transformation intensive jobs) whereas Java is more general. So, things like the management of multiple run queues in Erlang certainly make sense.
  - glymor 18y ago
    You seem to be trying to make a big distinction between actors and green threads that I don't see. The MxN mapping stuff is a nice start but there a long way from there to the Erlang or Azul VM.
    - johnm 18y ago
      No, you brought that (green threads implication) into the discussion. My whole point is that you're making an implication based on that distinction and that's just not true. Both Erlang and the JVM have to map lots of actors to a number of hardware cores. Lightweight threads of various sorts on top of a smaller number of hardware processes/threads is the same for both. Both Erlang and the JVM use an MxN model. You're last sentence seems to imply that you believe something different. They make some different tradeoffs because of their goals (coordination vs. general purpose) that has some real implication as to solving particular problems more or less easily. I.e., if you're doing coordination dominated systems then Erlang is easy and the underlying performance loss due to other implementation issues is mitigated. On the other hand, if you have lots of data and computation, then Java's solution will blow Erlang away. The real world is about understanding, choosing, and managing the real tradeoffs -- not pushing some theoretical ideal.

glymor 18y ago

Azul's system is proprietary and only runs on special hardware. The openjdk that's in common use has had essentially no work done on green threads. And from your link "we have a lite microkernel style OS; we can easily handle 100K runnable threads" it's not the VM that's handling it.

framiere 18y ago
You are correct, I was pointing to cliff click's blog as he his giving back to the community. Look at http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.h... : an implementation of a non blocking hashmap without lock that scales beautifully on a bunch of cores without the need of their hardware (http://sourceforge.net/projects/high-scale-lib http://sourceforge.net/projects/high-scale-lib) As per actor on the JVM open source projects are blooming around such as http://code.google.com/p/actorom/ http://code.google.com/p/actorom/. Alex Miller did a nice review here of the solutions out there: http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-concurrency2.html http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-co...
- glymor 18y ago
  I remember his hashmap when he published it, state machines are a great way to do concurrency. The Erlang way of handling concurrency is to spawn millions of "processes" (threads) obviously these can't be hardware threads so Erlang is hitting problems OS schedulers would handle (or not be able to handle) in the JVM's case. I would argue that the JVM is eventually going to have to handle the threading itself if it's to support any actor based programming. OS schedulers have other uses they need to be fast for and hardware threads will always have higher overhead. Python's Stackless is perhaps an example of the amount of work it would require.
  - johnm 18y ago
    You might want to take a look at e.g., Scala and how it implements actors on the JVM. It's basically doing a MxN actor to thread-pool scheduling.
    - glymor 18y ago
      The dispacter is probably a bottleneck, looking at the paper http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf I can't really tell how it's implemented. How does the Scala run queue work? eg have a look at the Erlang article I linked to in my first post.
johnm 18y ago
You seem to be implying that one needs e.g., "green threads" to support huge numbers of "actors". That implication is false. Also, the only way that Erlang can support running on multiple actual hardware cores is, just as in Java "actor" implementations, to do an MxN mapping of actors to cores. Now, at one end of the spectrum there's the basic rule of thumb for each system to have O(number of cores) hardware threads and map all of the actors down to that, there are good arguments (by people like Paul Tyma) that promote using 10s or even 100s of thousands of hardware threads in Java on real, shipping OSs (late model Linux is his focus). Of course, Erlang as both a language and its VM, are matched to each other and their specific problem domain (lots of little actors focused on coordination rather than computational or data transformation intensive jobs) whereas Java is more general. So, things like the management of multiple run queues in Erlang certainly make sense.
- glymor 18y ago
  You seem to be trying to make a big distinction between actors and green threads that I don't see. The MxN mapping stuff is a nice start but there a long way from there to the Erlang or Azul VM.
  - johnm 18y ago
    No, you brought that (green threads implication) into the discussion. My whole point is that you're making an implication based on that distinction and that's just not true. Both Erlang and the JVM have to map lots of actors to a number of hardware cores. Lightweight threads of various sorts on top of a smaller number of hardware processes/threads is the same for both. Both Erlang and the JVM use an MxN model. You're last sentence seems to imply that you believe something different. They make some different tradeoffs because of their goals (coordination vs. general purpose) that has some real implication as to solving particular problems more or less easily. I.e., if you're doing coordination dominated systems then Erlang is easy and the underlying performance loss due to other implementation issues is mitigated. On the other hand, if you have lots of data and computation, then Java's solution will blow Erlang away. The real world is about understanding, choosing, and managing the real tradeoffs -- not pushing some theoretical ideal.