4 ms·

I'm not saying i can't tell you, i'm saying i don't have the patience. I could throw the book at you and the library besides, but you showed quite clearly that

I'm not saying i can't tell you, i'm saying i don't have the patience. I could throw the book at you and the library besides, but you showed quite clearly that you lack the experience to know which problems multi-threading solves. This means that both of our time is better used if you went and got the experience. I don't want you to shut up, i want you to go and learn something. On the other hand, yes, i am an asshole. That's why i'll suggest you try and build a minecraft clone with a multi-process/single-thread solution PS: > Conversely, there's also a huge gain in architectural simplicity which I hope you are aware of. Though you have neither acknowledged nor disproven that yet I absolutely said so. I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers.

nailer 13y ago
By no means would I try and build a high bandwidth graphics pipeline that runs between processes. That's a very specific problem requiring a very specific solution. However it wouldn't be correct to abandon multiple process single thread for the (much more common, particularly on HN) situation of a web app that's running on a server with multiple logical cores in non-evented programming language. > I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers. When? Please quote.
- Mithaldu 13y ago
  > it wouldn't be correct to abandon multiple process single thread I never said that should be done and in fact mentioned that as a solution/problem pair, see the bit about webservers in the PS of my previous comment. :) (A web app is just a specialized webserver.) > When? Please quote. I did so in a much more concise form here: > different use profiles that make certain multi-processing paradigms better suited than others
  - nailer 13y ago
    I guess the issue is the full version of the quote: "If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion" That was the first time you've proposed the topic! I didn't imagine it because you hadn't actually brought up the subject. I asked you specifically what you needed. And already you've told me not to speak to you about it. How about: "well in games which need single copies of large in-memory assets a multi-process setup wouldn't work due to copy latency"? Seriously. You're not very good at discussing things with people. Perhaps you were a Perl person - who, in general, doesn't create high performance games - avoiding Python for typical Perl task because of lack of multiprocessing? I'm just showing that you (and others) can solve the multicore issue quite easily with a couple of well known modules. And you tell me not to talk to you because I didn't anticipate you wanted to talk about /video gaming/? There's a stereotype of early 2000's Perl people: misanthopes who discuss LARTing, hitting users with 'cluesticks' etc. You're reenforcing it.
    - Mithaldu 13y ago
      I was hoping to get you to be creative and come up with your own problem/solution pairs. :) Anyhow, rather than having you both take my word for it, and at the same time try to prove how bad i am at argumenting (i really am terrible!), i'd prefer to see you actually try a minecraft clone in multiple processes, just in case i'm wrong.
      - nailer 13y ago
        You wanted me to come up with a scenario like gaming graphics pipelines in a discussion of Perl, a language primarily used for Unix scripting tasks? OK.
        kbenson 13y ago
        a language primarily used for Unix scripting tasks? I wouldn't say that's necessarily an accurate description, or at least not a foregone conclusion.

nailer 13y ago

By no means would I try and build a high bandwidth graphics pipeline that runs between processes. That's a very specific problem requiring a very specific solution. However it wouldn't be correct to abandon multiple process single thread for the (much more common, particularly on HN) situation of a web app that's running on a server with multiple logical cores in non-evented programming language. > I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers. When? Please quote.

Mithaldu 13y ago
> it wouldn't be correct to abandon multiple process single thread I never said that should be done and in fact mentioned that as a solution/problem pair, see the bit about webservers in the PS of my previous comment. :) (A web app is just a specialized webserver.) > When? Please quote. I did so in a much more concise form here: > different use profiles that make certain multi-processing paradigms better suited than others
- nailer 13y ago
  I guess the issue is the full version of the quote: "If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion" That was the first time you've proposed the topic! I didn't imagine it because you hadn't actually brought up the subject. I asked you specifically what you needed. And already you've told me not to speak to you about it. How about: "well in games which need single copies of large in-memory assets a multi-process setup wouldn't work due to copy latency"? Seriously. You're not very good at discussing things with people. Perhaps you were a Perl person - who, in general, doesn't create high performance games - avoiding Python for typical Perl task because of lack of multiprocessing? I'm just showing that you (and others) can solve the multicore issue quite easily with a couple of well known modules. And you tell me not to talk to you because I didn't anticipate you wanted to talk about /video gaming/? There's a stereotype of early 2000's Perl people: misanthopes who discuss LARTing, hitting users with 'cluesticks' etc. You're reenforcing it.
  - Mithaldu 13y ago
    I was hoping to get you to be creative and come up with your own problem/solution pairs. :) Anyhow, rather than having you both take my word for it, and at the same time try to prove how bad i am at argumenting (i really am terrible!), i'd prefer to see you actually try a minecraft clone in multiple processes, just in case i'm wrong.
    - nailer 13y ago
      You wanted me to come up with a scenario like gaming graphics pipelines in a discussion of Perl, a language primarily used for Unix scripting tasks? OK.
      - kbenson 13y ago
        a language primarily used for Unix scripting tasks? I wouldn't say that's necessarily an accurate description, or at least not a foregone conclusion.