Re: [Algorithms] General purpose task parallel threading approach

[<asy...@gm...>]

How do you utilize multicore in your game then?  I'd like to cover as many
areas in programming world as I can, so I wonder what kind of functionality
am I missing which you would like to have ? That automatic task switching on
blocking condition has no cost if you don't use it. In this case you have
something close to openmp style multithreading.

Alexander.

2009/4/4 Nicholas "Indy" Ray <ar...@gm...>

> On Sat, Apr 4, 2009 at 2:55 AM,  <asy...@gm...> wrote:
> > Originally I was trying to solve the problem of how to write a server,
> > serving multiple clients simultaneously utilizing all cores without
> writing
> > a state machine for each client (I found out that it is damn complex to
> > extend logic when it is expressed via state machine).
> > The solution I have now perfectly fits imho - I only need to write a task
> > per client which does simple send/receive (as if you'd write a single
> > threaded application), and I get ideal multicore scale.
>
> It's problematic trying to take an approach that works well for
> servers and extend it for video games. Most servers have very low data
> contention, don't worry to much about small variances in latency and
> spend a lot of time waiting around on IO and the like. On the other
> hand, video games not designed for multi threading generally have very
> high data contention, which require many locks, and at that point, the
> cache misses generally provide just as much of a performance hit as
> the lock itself. Latency requirements are very strict, and
> additionally, most games spend very little to zero time in IO and when
> so it is almost always in loading, or designed async to begin with.
> And given such there is not a lot of time to fit in extra cycles for
> worker threads on the main CPU.
>
> Indy
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Regards,
Alexander Karnakov