3 ms·

threading doesn't come "for free", in that you need to pay a performance cost in terms of locking in your interpreter and/or a code complexity cost in terms of

by buff-a 15y ago

threading doesn't come "for free", in that you need to pay a performance cost in terms of locking in your interpreter and/or a code complexity cost in terms of access to your shared data structures vs there are out-of-process cacheing technologies (memcached, redis etc) If you subject "out-of-process cacheing technologies" to the same measurements (performance cost, code complexity), as threading solutions, what do you find?

simonw 15y ago
That they're massively easier to work with?
jbert 15y ago
> If you subject "out-of-process cacheing technologies" to the same measurements (performance cost, code complexity), as threading solutions, what do you find? Yes, I think you find that shared state is difficult. So it's the old process (private by default, shared as the exception) versus threads (shared by default) split. imho, "less shared state" == "simpler". And imho, "private by default" == "less shared state". And you have an easier time of it the shared state helps you with concurrent access. This is one benefit of RDBMSs (transactions) and also systems like redis. The fact that your state is external means it is more likely to have been designed to be conncurrency-safe.
- antrix 15y ago
  I don't get this argument. If I replace my memcache logic with an in-memory thread-safe hashmap, it will always be faster. I can't see how it can be slow. As for 'simpler', as long as you aren't actually implementing the thread safe map, it is simpler than using memcache too. So as long as you use well written shared state implementations, (e.g. Java's concurrent collections), shared state isn't as hard as you make it out to be.
  - jbert 15y ago
    > If I replace my memcache logic with an in-memory thread-safe hashmap, it will always be faster. I can't see how it can be slow. Because in a threaded application context, you have to either: - have locking/synchronization on all data structures (performance cost) OR - manage which of your data structures are shared and which are not (complexity cost/race bugs) With external, shared state (RDBMs, memcached, etc) you get fast in-process access to your (private) data structures (no performance cost due to locking) and a (mostly) concurrency-safe, explicit datastore. And as pointed out elsewhere, to scale beyond a single process you need the external state anyway. There are other approaches to this, software transactional memory, functional programming, clojure paradigm etc. But it's a hard problem and it's not clear these are the right solution at scale.
    - buff-a 15y ago
      manage which of your data structures are shared and which are not That is exactly what you are doing when you decide which of your data structures go in memcache and which don't.
      - jbert 15y ago
        > That is exactly what you are doing when you decide which of your data structures go in memcache and which don't. Yes, apart from the fact that the ones you don't think about are private. i.e. processes are "private by default" and threads are "shared by default". Processes give you a safe default, threads give you a dangerous one. This is the main (only) difference between threads and processes - and it is the important one.
        buff-a 15y ago
        So you concede Antrix's point that mutlithreading is not slower? I'd just like to confirm that you are even able to determine when your argument has been refuted, as you seem to think that that the proper response is to just pretend it didn't happen and come up with a new reason instead. That is to say, are you a reason factory supporting of an internally held belief despite evidence to the contrary, or are you a rational sentient who is in a discourse for the purpose of determining a common truth.

by buff-a 15y ago

simonw 15y ago

That they're massively easier to work with?

jbert 15y ago

> If you subject "out-of-process cacheing technologies" to the same measurements (performance cost, code complexity), as threading solutions, what do you find? Yes, I think you find that shared state is difficult. So it's the old process (private by default, shared as the exception) versus threads (shared by default) split. imho, "less shared state" == "simpler". And imho, "private by default" == "less shared state". And you have an easier time of it the shared state helps you with concurrent access. This is one benefit of RDBMSs (transactions) and also systems like redis. The fact that your state is external means it is more likely to have been designed to be conncurrency-safe.

antrix 15y ago
I don't get this argument. If I replace my memcache logic with an in-memory thread-safe hashmap, it will always be faster. I can't see how it can be slow. As for 'simpler', as long as you aren't actually implementing the thread safe map, it is simpler than using memcache too. So as long as you use well written shared state implementations, (e.g. Java's concurrent collections), shared state isn't as hard as you make it out to be.
- jbert 15y ago
  > If I replace my memcache logic with an in-memory thread-safe hashmap, it will always be faster. I can't see how it can be slow. Because in a threaded application context, you have to either: - have locking/synchronization on all data structures (performance cost) OR - manage which of your data structures are shared and which are not (complexity cost/race bugs) With external, shared state (RDBMs, memcached, etc) you get fast in-process access to your (private) data structures (no performance cost due to locking) and a (mostly) concurrency-safe, explicit datastore. And as pointed out elsewhere, to scale beyond a single process you need the external state anyway. There are other approaches to this, software transactional memory, functional programming, clojure paradigm etc. But it's a hard problem and it's not clear these are the right solution at scale.
  - buff-a 15y ago
    manage which of your data structures are shared and which are not That is exactly what you are doing when you decide which of your data structures go in memcache and which don't.
    - jbert 15y ago
      > That is exactly what you are doing when you decide which of your data structures go in memcache and which don't. Yes, apart from the fact that the ones you don't think about are private. i.e. processes are "private by default" and threads are "shared by default". Processes give you a safe default, threads give you a dangerous one. This is the main (only) difference between threads and processes - and it is the important one.
      - buff-a 15y ago
        So you concede Antrix's point that mutlithreading is not slower? I'd just like to confirm that you are even able to determine when your argument has been refuted, as you seem to think that that the proper response is to just pretend it didn't happen and come up with a new reason instead. That is to say, are you a reason factory supporting of an internally held belief despite evidence to the contrary, or are you a rational sentient who is in a discourse for the purpose of determining a common truth.