separate threads

[psi29a]

If everything else fails, I think we should put the animations into a seperate thread. That way it wouldn't affect the FPS of the rendering thread, and animations playing with 25 frames per second are pretty much acceptable.

^-- this please.

[jhooks1]

If you guys could figure out the separate thread, that would be awesome! We only utilize one core processors now right? Dual core would be sweet, I bet it would be a lot of work though.

[psi29a]

If you guys could figure out the separate thread, that would be awesome! We only utilize one core processors now right? Dual core would be sweet, I bet it would be a lot of work though.

In theory there could be many threads (music, AI, the different subsystems), the OS balances the threads across available logical CPUs. It really depends on the threading implementation though.

Background music should also sit in apart thread as it is just 'mood' music anyway. This keeps it out of the way of sound effects and other potential latency issues.

[ezzetabi]

Guys, if you go multicore (and... well... it must be done soon or later) you have to use a messaging library, here is a quote about it from the ØMQ guide:

To make utterly perfect MT programs (and I mean that literally) we don't need mutexes, locks, or any other form of inter-thread communication except messages sent across ØMQ sockets.

By "perfect" MT programs I mean code that's easy to write and understand, that works with one technology in any language and on any operating system, and that scales across any number of CPUs with zero wait states and no point of diminishing returns.

If you've spent years learning tricks to make your MT code work at all, let alone rapidly, with locks and semaphores and critical sections, you will be disgusted when you realize it was all for nothing. If there's one lesson we've learned from 30+ years of concurrent programming it is: just don't share state. It's like two drunkards trying to share a beer. It doesn't matter if they're good buddies. Sooner or later they're going to get into a fight. And the more drunkards you add to the pavement, the more they fight each other over the beer. The tragic majority of MT applications look like drunken bar fights.

Far too many programs still ignore this fact and in the end they are plenty of subtle bug that are virtually impossible to fix.

When in MT always think you are working with processes that communicate with TCP messages. How actually the different thread of executions exists (threads or processes) and how actually they communicate (tcp or ipc, epgm, ...) is an implementation detail you have to decide.

In my humble opinion (I am working on this stuff now, I hope it counts a little) the library that helps this better is ØMQ. Since openMW is using C++ in a single computer environment you can use POD structs as messages.

[Greendogo]

The above quote is taken from this part of the above linked-to page: http://zguide.zeromq.org/page:all#toc38

[corristo]

message passing ftw!

[Yacoby]

I skip read the multithreading part of the ØMQ intro, but it didn't ever sell me on why I should use it? Or the performance/api benefits over TBB or something like that. It also isn't used as much, so hasn't generated as much documentation/questions. Compare the result in google of "ØMQ thread help" and "tbb thread help"


But yeah, shared state is generally a bad idea (Well, state is generally a bad idea and should really be avoided as well). I thought everyone had realised that quite a time ago?

[ezzetabi]

Yes, tbb is nice too. I guess it is a matter of experience. The shared state thing is an old news now, but I just wanted to be sure.

[Yacoby]

In theory there could be many threads (music, AI, the different subsystems), the OS balances the threads across available logical CPUs. It really depends on the threading implementation though.

Background music should also sit in apart thread as it is just 'mood' music anyway. This keeps it out of the way of sound effects and other potential latency issues.

I am now slightly less tired.

In my view threads is a great idea, and anything that doesn't require excessive synchronization or data storage could be a good easy candidate for threading.

I would also quite like (at some point) to have the IO loading stuff threaded, although I am not sure how that would work with regards to esm files (although is it only terrain that we don't store in memory?)

Yes, tbb is nice too. I guess it is a matter of experience. The shared state thing is an old news now, but I just wanted to be sure.

+1



The added bonus of this is that everyone wants OpenMW to use more cores. You just have to look at the Bethsoft thread. Being able to say "OpenMW can use up to 6 cores", even if it doesn't fully utilise them would probably be quite good PR.

[Greendogo]

If you want to know more about it, check youtube for videos about zeromq (like this one by one of its developers) if you don't want to read it. But it seems to be geared towards needing to only right code once but allowing it to use multiple cores, or processors or connected computers, and having it just work. And I read the api is supposed to be very simple.

The multiple computers thing doesn't really seem like it would be useful for OpenMW.

I'm not really advocating for it, I just think it's interesting.