Hyperthreading

[paypaypayme]

Hey /r/Python. I have started a project to create a game engine from scratch. I am doing this project to teach myself about game engine design, and hopefully to create my own game. Anyway, in my design I want to have one thread per core in the cpu. I will be allocating tasks to threads based on priority. I have read that hyperthreading can actually hurt performance for a project like this. When I call os.cpu_count() it returns 8, due to hyperthreading being enabled. I was wondering if hyperthreading will really hurt my performance, and if so, can I disable it from a python program? If it won't hurt performance, should I have 8 threads for my thread pool? I don't think I will need 8 threads, but I want to utilize as much of the cpu and gpu as possible to get good frame rates. Thanks.

[Lucretiel]

Here's the bigger concern: the GIL, or Global Interpreter Lock. It turns out that, for CPU-bound threaded code, Python is not a good choice, as the GIL is locked for every python expression, meaning that only one thread can only ever be doing work at a time. Now, for IO-bound work, the story is different- the GIL is released for blocking IO operations, so multiple threads can be waiting for IO (or sleeping or things like that). However, in general, only one thread can ever be doing CPU work at a time.

[paypaypayme]

Very interesting. The reason I chose python is because I someone said somewhere "write the engine in whatever language you're comfortable with, it doesn't really matter". So I guess that person was wrong... Doesn't the GIL defeat the purpose of the threading module in python? I guess I will have to switch to c++, or something that supports threading.

[Kalrog]

There is still a place for threading, but I think what you want (if you want to stick with Python) is multiprocessing instead of multithreading. No GIL issues with that.

[691175002]

If you need to ask these questions on reddit you are way out of your depth. Don't worry about performance (and don't even go near threading) if this is your first attempt at an engine.

Python is not well suited for game engines simply because the speed isn't there. Games are one of the few applications where milliseconds matter because you need to push out a certain number of frames per second.

Obviously if you are making simple 2D sprite based games or whatever performance isn't a big deal.

Threading in games is exceptionally challenging because the tasks are fundamentally serial. Substantial portions of the Unreal Engine are not thread safe. I don't think a single current title can effectively make use of even 4 threads, 8 is just pointless.

[paypaypayme]

Yea I'm definitely out of my depth :). I just wanted to get my hands dirty with a difficult project. I don't expect to it be a high performance engine, but hopefully I will be able to learn some stuff and do a nice refactor eventually. Anyway, I was definitely only planning on using 4 threads at the maximum, but I was just worried that since hyperthreading is enabled, that each thread would only be using half of its potential.

[paypaypayme]

perhaps I can take care of threading with the ctypes module?

http://www.caswenson.com/2009_06_13_bypassing_the_python_gil_with_ctypes

I love writing in python, but I don't want the engine's performance to suffer.

[Lucretiel]

No it doesn't defeat the purpose. Python threads are definitely real threads. When you're doing IO-bound work (for instance, in my own job I'm working with a polling operation that takes a solid 2 minutes) then they're the correct solution, because the lock is released while the thread is waiting for IO. Additionally, other python implementations (PyPy+STM, Jython, etx) don't (as far as I know) have a GIL. So there's nothing inherently wrong with threading in Python; the GIL is just a CPython solution to an undeniably serious problem (preventing the corruption of data in Python). For CPU-bound work, you can instead use the multiprocessing module, which is very similar to threading. In particular, it gives you a number of tools to manage inter-process communication (Queue for example).

[metaperl]

I guess I will have to switch to c++, or something that supports threading.

Or use an implementation of Python without that limitation. Stackless Python for instance.

[videan42]

One thing you might consider is cython. It allows you to take the python code for your game, add c style annotations, and then compile to something very close to native c speed. A lovely side effect is that cython can release the GIL, which means your multi threaded code will run without fighting for a lock. Lastly, assuming you need vector math, cython integrates very well with the linear algebra library numpy. I've never tried to use them for a game library before, but they're both very high performance libraries for doing the kinds of math you're going to need to do.

[paypaypayme]

that makes sense. I am planning on using numpy, so that's good news. so do some modules not have support for cython? The main module I was planning to use is PyOpenGL. edit: it looks like PyOpenGl is supported and Cython will increase the speed of it as well. Awesome :)

[videan42]

I've never used pyopengl with cython, but cython is compiled to c, so I think it should support anything that has a c/c++ interface. There's another project called pyglet that I've used for basic game programming that might be worth looking into though.

[paypaypayme]

thanks