4 ms·

I'm sorry if that wasn't clear, sharing doesn't only mean "making the data available" but also means high performance and direct access. Quite simply though: If

I'm sorry if that wasn't clear, sharing doesn't only mean "making the data available" but also means high performance and direct access. Quite simply though: 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 and should be getting more experience outside of what you're doing right now.

nailer 13y ago
I'm just pointing what's solved the problem for me, and how it can be useful for others. I'm aware there's a performance overhead. > 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 and should be getting more experience 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 - based on your last comment, I think this is because you are an asshole. That's not an ad hominem attack, but rather an assessment of your personality after conversing with you here. I have tried discussing with you technically, and not acknowledging other's points, then responding with "if you can't imagine my points, I can't tell you" is not how a rational, polite adult with a technical viewpoint converses with others.
- Mithaldu 13y ago
  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.

nailer 13y ago

I'm just pointing what's solved the problem for me, and how it can be useful for others. I'm aware there's a performance overhead. > 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 and should be getting more experience 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 - based on your last comment, I think this is because you are an asshole. That's not an ad hominem attack, but rather an assessment of your personality after conversing with you here. I have tried discussing with you technically, and not acknowledging other's points, then responding with "if you can't imagine my points, I can't tell you" is not how a rational, polite adult with a technical viewpoint converses with others.

Mithaldu 13y ago
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.