> 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.

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.

> 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.

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

"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.

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.

OK.

I wouldn't say that's necessarily an accurate description, or at least not a foregone conclusion.

> I was hoping to get you to be creative and come up with your own problem/solution pairs. :)

Also:

http://www.youtube.com/watch?feature=player_detailpage&v=R5F...

https://dl.dropboxusercontent.com/u/10190786/your_perl_on_dr...

Both done in realtime in Perl.

Also, oh god, all that stuff you edited into the reply before that one about LARTing and whatever, you're misinterpreting so much and putting so many words into my mouth, it's not funny anymore. You should try to reread my posts with a conscious effort to not make them sound like a german drill seargant yelling at you. ;)

>> 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?

> I just told you that i exactly did not want you do to that: "I was hoping to get you to be creative and come up with your own problem/solution pairs."

Christ.