3 ms·

Is any thought being put into adding parallelism in the future?

by dmpk2k 2y ago

andsoitis 2y ago
No, but you can do concurrent programming in Pharo: https://books.pharo.org/booklet-ConcurrentProgramming/pdf/ConcurrentProgramming.pdf https://books.pharo.org/booklet-ConcurrentProgramming/pdf/Co...
- ginko 2y ago
  So the entire dev environment and any programs you have running in it only uses a single thread?
  - andsoitis 2y ago
    Pharo uses green threads https://www.pharo.org/features https://www.pharo.org/features https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread
    - packetlost 2y ago
      So does it use symmetric multiprocessing at all?
      - pjmlp 2y ago
        Green threads only mean a M:N mapping to OS threads.
        packetlost 2y ago
        Right, is the N (OS threads) == 1 in this case? It's a specific, technical way of asking if it can run parallel workloads across modern multi-core CPUs.
        rscho 2y ago
        As far as I understand it, no parallelism at all in Pharo itself.
    - ginko 2y ago
      That feels very limiting. It's one thing to have a program run only on one core, but you're supposed to have your entire dev environment, including editor and debugger inside the VM. Won't that end up with the env freezing on compute heavy tasks?
      - pjmlp 2y ago
        The runtime does the mapping, it only means IS threads aren't directly exposed.
      - 0x445442 2y ago
        Yes, you can lock the UI quite easily if you're not careful.
batman-farts 2y ago
https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM is the main thing that comes up when trying to learn about this, and it hasn't been touched in over 10 years. I have also seen people working on spawning child VMs to handle parallelism, though unfortunately I don't have links to those discussions immediately at hand. It seems like perhaps an unnecessarily heavyweight approach, too, not a canonical solution that you would want to use in production. I assume that step 1 towards parallelism, at least on the image side, would be going through the class library and making sure everything is thread-safe. I'd love to know where one would even get started with that effort. The Roar project claims to support Pharo 1.2, which doesn't seem to be very far after they forked from Squeak, but obviously a lot has changed since then. And the challenge is that Pharo is still rapidly developing all the overhauled classes that distinguish it from Smalltalk-80. Meanwhile, if I want to play with parallel image/REPL-based programming, I can go over to Common Lisp and, while lacking an equally coherent GUI, be able to load up bordeaux-threads and off I go.

Is any thought being put into adding parallelism in the future?

by dmpk2k 2y ago

Is any thought being put into adding parallelism in the future?

No, but you can do concurrent programming in Pharo: https://books.pharo.org/booklet-ConcurrentProgramming/pdf/ConcurrentProgramming.pdf https://books.pharo.org/booklet-ConcurrentProgramming/pdf/Co...

ginko 2y ago
So the entire dev environment and any programs you have running in it only uses a single thread?
- andsoitis 2y ago
  Pharo uses green threads https://www.pharo.org/features https://www.pharo.org/features https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread
  - packetlost 2y ago
    So does it use symmetric multiprocessing at all?
    - pjmlp 2y ago
      Green threads only mean a M:N mapping to OS threads.
      - packetlost 2y ago
        Right, is the N (OS threads) == 1 in this case? It's a specific, technical way of asking if it can run parallel workloads across modern multi-core CPUs.
        rscho 2y ago
        As far as I understand it, no parallelism at all in Pharo itself.
  - ginko 2y ago
    That feels very limiting. It's one thing to have a program run only on one core, but you're supposed to have your entire dev environment, including editor and debugger inside the VM. Won't that end up with the env freezing on compute heavy tasks?
    - pjmlp 2y ago
      The runtime does the mapping, it only means IS threads aren't directly exposed.
    - 0x445442 2y ago
      Yes, you can lock the UI quite easily if you're not careful.

batman-farts 2y ago

https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM is the main thing that comes up when trying to learn about this, and it hasn't been touched in over 10 years. I have also seen people working on spawning child VMs to handle parallelism, though unfortunately I don't have links to those discussions immediately at hand. It seems like perhaps an unnecessarily heavyweight approach, too, not a canonical solution that you would want to use in production. I assume that step 1 towards parallelism, at least on the image side, would be going through the class library and making sure everything is thread-safe. I'd love to know where one would even get started with that effort. The Roar project claims to support Pharo 1.2, which doesn't seem to be very far after they forked from Squeak, but obviously a lot has changed since then. And the challenge is that Pharo is still rapidly developing all the overhauled classes that distinguish it from Smalltalk-80. Meanwhile, if I want to play with parallel image/REPL-based programming, I can go over to Common Lisp and, while lacking an equally coherent GUI, be able to load up bordeaux-threads and off I go.