UPDATE: The post below is obsolete. I have a Pentium 4 with Hyper-Threading (SMP) so I made one part of my code multi-threaded to get a speed-up. Two threads are created, each of which evaluates roughly equal amounts of data. In Linux this gave me a nice ~50% increase in framerate, but in Windows it actually decreases -- single-threaded, it's 17 fps, but multi-threaded, it's 11 fps. The threads do not write to the same memory, though each thread does read from memory that the other thread writes to, without any sort of mutex (the order of the read/write is irrelevant). I don't know if that somehow causes a slowdown. My code for creating the threads looks like: [removed] AIThread is the function, ThreadData is the parameter passed, and SimTime is initialized to zero, and set to some value when the thread finishes (at the end of the AIThread function). So the while loop merely loops forever, doing nothing, until both SimTimes are nonzero, indicating both threads have finished. Does anyone know why I could be getting such a drastic framerate decrease? [Edited by - CGameProgrammer on December 17, 2004 2:54:12 AM]

Quote:Original post by Skizz
Windows doesn't support multiple CPUs - you need to get a multiple CPU version of the OS (NT only IIRC and I'm not sure it even supports HT). You pay a license per physical CPU, so a dual CPU in one chip counts as one. So, in Windows, your multithreaded app was running on one CPU so it was never going to be quicker.

That's only true for a certain licence agreements with Windows Server on high-grade server machines, certainly not true for workstation editions.

NT, Win2K and XP Pro handle multiple CPUs and HT processors fine, right out of the box. XP Home, however, has been crippled and only supports one CPU (and HT is disabled).

Ysaneya: I have no synchronization of any sort. Yes I'm aware of how Hyper-Threading works, and my framerate had increased by roughly 50%, though my performance in Linux was bad to begin with for some reason (partly ATI-related). Anyway, I have uploaded a new GDomin.zip. Press 'm' to toggle multithreading on or off (it's off by default). Note that you will see no difference unless you have a bunch of ships flying around, so select alot of ships and right-click somewhere on screen so they'll go there (don't forget to press Space first so you can select stuff). Let me know if it crashes; the MT conversion is not totally finished, but it should be stable. I can run the program forever and it never crashes. Also, ignore the workload statistics; they're wrong... the framerate is correct however.

Oh, I should probably mention the game will run much slower than it did with the first release; this is not due to multithreading, but due to improved collision avoidance. It's slower though, but there are still ways to speed it up.

Skizz: Windows XP Professional supports multiple CPUs; I can open the Task Manager and see the workload on each virtual CPU.

Anonymous: Interesting... very interesting. What you say makes alot of sense. I did it that weird way because I couldn't find a good way in Windows of waiting for a thread to finish; the available functions seemed weird. Linux just has a nice simple pthread_join function. Ah well.

Thanks darookie. I haven't looked at mutexes yet, but I used WaitForSingleObject (and then switched to WaitForMultipleObjects which is better for me) and I no longer get a framerate decrease when being multithreaded, so the AP was correct. But I don't get a noticeable framerate increase either.

I've now updated GDomin.zip with the 'fixed' version, Ysaneya, so I'd be interested to here your results. I probably need some sort of synchronization, though I'm not sure how that works... I get using a mutex variable to prevent conflicting writes, but no memory is written to by both threads.