4 ms·

In what situations would you need to do this? I have been using Nim for a long time now and never felt limited by this.

by dom96 12y ago

pcwalton 12y ago
All the time. It's the bread-and-butter of high-performance concurrent programming. - I have a large graph data structure allocated in one thread and I want to transfer it to another thread without copying. - I have a lock-free data structure and I want the benefits of a GC so I don't have to use less efficient hazard pointers [1]. - I have an in-memory database that I want to be able to query efficiently from multiple threads without copying. - I'm doing work stealing on a large, complex data structure and I need to be able to access pieces of that data structure from multiple threads with unpredictable memory access patterns. - I'm using a multicore job queuing system (like most AAA games do nowadays) and almost all game assets can be accessed from any thread. These are just a few. Sure, you can use unsafe manual memory management to work around it, but without RAII and a library designed for manual memory management you suffer a huge penalty in usability—not to mention the safety problems. I can foresee people easily ending up in a situation whereby they can't multithread their applications because they started out using the GC and would have to rewrite all their code to switch from automatic memory management to unsafe manual memory management. Another way to work around the restriction is to copy the data, but that usually ends up making your parallel algorithm slower than sequential unless it has very high arithmetic intensity. (This is based on experience.) [1]: http://en.wikipedia.org/wiki/Hazard_pointer http://en.wikipedia.org/wiki/Hazard_pointer
- moe 12y ago
  All the time. Some people need these kind of optimisations all the time. Most people don't need them even once in their entire life.
  - pcwalton 12y ago
    Every Cocoa app I've written has used "[NSObject performSelectorInBackground:withObject:]", which relies on having a thread-safe GC (atomic reference counting).
    - moe 12y ago
      And just as Cocoa abstracts this away from you any popular Nim frameworks that need such optimisations will also abstract them away from you.
      - pcwalton 12y ago
        I don't see how. The abstraction here is automatic memory management -- i.e. the GC -- and the problem is that the abstraction doesn't work for this popular use case. The language needs to provide a more flexible abstraction: a thread-safe GC. And it's not a question of optimization, it's a question of semantics. Performing an operation in a background thread with a strong mutable reference to an object is a semantic concept. Without a thread-safe GC you simply can't do it.
- ElectronCharge 12y ago
  "- I'm using a multicore job queuing system (like most AAA games do nowadays) and almost all game assets can be accessed from any thread." Almost all AAA games use C++, and live with the 'joys' of manual memory management. Nim provides that as well, from what I've read. I've not yet taken the Nim plunge, but I'm looking forward to it.

In what situations would you need to do this? I have been using Nim for a long time now and never felt limited by this.

by dom96 12y ago

In what situations would you need to do this? I have been using Nim for a long time now and never felt limited by this.

All the time. It's the bread-and-butter of high-performance concurrent programming. - I have a large graph data structure allocated in one thread and I want to transfer it to another thread without copying. - I have a lock-free data structure and I want the benefits of a GC so I don't have to use less efficient hazard pointers [1]. - I have an in-memory database that I want to be able to query efficiently from multiple threads without copying. - I'm doing work stealing on a large, complex data structure and I need to be able to access pieces of that data structure from multiple threads with unpredictable memory access patterns. - I'm using a multicore job queuing system (like most AAA games do nowadays) and almost all game assets can be accessed from any thread. These are just a few. Sure, you can use unsafe manual memory management to work around it, but without RAII and a library designed for manual memory management you suffer a huge penalty in usability—not to mention the safety problems. I can foresee people easily ending up in a situation whereby they can't multithread their applications because they started out using the GC and would have to rewrite all their code to switch from automatic memory management to unsafe manual memory management. Another way to work around the restriction is to copy the data, but that usually ends up making your parallel algorithm slower than sequential unless it has very high arithmetic intensity. (This is based on experience.) [1]: http://en.wikipedia.org/wiki/Hazard_pointer http://en.wikipedia.org/wiki/Hazard_pointer

moe 12y ago
All the time. Some people need these kind of optimisations all the time. Most people don't need them even once in their entire life.
- pcwalton 12y ago
  Every Cocoa app I've written has used "[NSObject performSelectorInBackground:withObject:]", which relies on having a thread-safe GC (atomic reference counting).
  - moe 12y ago
    And just as Cocoa abstracts this away from you any popular Nim frameworks that need such optimisations will also abstract them away from you.
    - pcwalton 12y ago
      I don't see how. The abstraction here is automatic memory management -- i.e. the GC -- and the problem is that the abstraction doesn't work for this popular use case. The language needs to provide a more flexible abstraction: a thread-safe GC. And it's not a question of optimization, it's a question of semantics. Performing an operation in a background thread with a strong mutable reference to an object is a semantic concept. Without a thread-safe GC you simply can't do it.
ElectronCharge 12y ago
"- I'm using a multicore job queuing system (like most AAA games do nowadays) and almost all game assets can be accessed from any thread." Almost all AAA games use C++, and live with the 'joys' of manual memory management. Nim provides that as well, from what I've read. I've not yet taken the Nim plunge, but I'm looking forward to it.