Seriously? It is an example and a joke at that to exemplify how a truly distributed system does not care about order as the components negotiate their communication without a central authority. I like anarchy :-) But sure you could make the main thread just wait or sleep on a signal. I guess you will gain 0.0000001 seconds performance ;-) But ok if your aim is to exit as fast as possible then sure a long sleep and then a poll will delay that. I give you that.
Polling for main game loops may be fine for turn-based or event-based games and can be used for them. However, most modern games do not rely on that method, instead operating on a tight main loop that runs "as fast as possible". These tight main loops decouple rendering, animation, simulation, and input because that allows them to bypass steps that are not required during that instance of the loop.
As for gaining 0.0000001 seconds (100 nanoseconds), there have absolutely been times when profiling and optimizing code that a 100 nanosecond improvement was a godsend. When you start multiplying things by 60 or 75 or 120 frames per second, multiplied again by hundreds or thousands of elements to update every frame, those nanoseconds become important pretty quickly.
Nice straw man argument. Here is a pat on the back.
Transparent message passing is the way to go and I am quite amased why not everyone has transitioned to the paradigm already. I guess laziness. And I totally can't stand Intel TBB it just plainly over complicates things (yes all programmers know this is not a message passing interface, next...)
What do you mean that you NEED to know? I don't understand. Do you mean knowing the clock cycles that were spent? Curious.
PS - and people wonder why coders have zero personal skills. You hung up on a detail on a polling loop when 99% of the post was about how to design a proper distributed game environment. Sheesh.
True, a few coders have zero personal skills. Fortunately they make up a small portion of the community. There are many books that might be useful on that subject to such people, such as this famous one, that teach techniques such as avoiding direct criticism and condemnation, being sympathetic with others' ideas even when they are different from yours, and allowing other people to save face when they (rightly or wrongly) feel wronged.
Again with the poll. It was shown as an example that you no longer have to use a main thread at all. Yes you can replace that with whatever other sleep/signal that you prefer.
It is not always true though. Unfortunately when working on OS X and iPad some parts have to be polled in the main thread. I hate that :-)
For the rest. Yeah maybe I should have been kinder but it puts my pants on fire when I spend a long post to explain the benefits of asynch and distributed design, to then make an obvious fun remark about how the main loop can now just sleep, that hplus spends all his energy and focus on that joke of a line. It's ironic and black humour. But it also shows how some think they can get out of a stupid comment (by advocating a multi-pass approach for things that should not, like hplus did) by attacking something without rime nor reason. It's weak and he should be the one pointing out his own mistake, not spreading bad information.
This site still is about better not worse coding practices right?
PS I've read that book and usually self help is just some honey for the soul, not really the solution. Sometimes anger is good and helps you get things done. I am sure hplus knows his shit, but why then play stupid and point out something like that, when he should be re-assessing his first answer. We all make mistakes and mine is sometimes to be a bit too confrontational, of which if I hurt anyone, apologize.
PS2 - and I am genuinely curious what would be the NEED in the message passing approach. I am designing such a system and would like to know. Maybe hplus has a good insight on this.
Edited by spinningcube, 29 January 2014 - 12:40 PM.