this is even more confusing... the nvidia ion has a atom 230 in it, which says it doesn't have HT... then i go look at the list of atom cpu's and the 230 is a single core with HT. (so which is it? lol)
at any rate, my next cpu will probably be an i7 920.
multithreaded software may run faster on a cpu that has simultaneous multithreading (SMT). "hyperthreading" (an intel buzzword) is a light/lame version of SMT.
a single core that has some feature like that might benefit.
not lfs though, lfs is really light on cpu usage considering the CPUs out right now.
I would not really agree here.
Put all the AI on track and then its not that light anymore.Or when someone have all A64 X2 3800+ and you are behind the whole field at start. The second core on this old processor which is not the fastest one could help if multithreading would be used in LFS.
Indeed there is large installed userbase of dual core processors which do labour in LFS under some circumstances that would benefit if LFS where to go dual core.
one thing about having multiple cores, whether it be SMT or SMP, is that you can run windows and all the other crap on one "CPU" and run lfs on the other. most people don't know about affinity and how to tune it.
Short version: I've been programming since I was 6, I was labelled a protege, at age 8 I was offered a job by a major software house after they saw a demo tape I had put together. Then I spent 10 years or so throwing it all away on drugs, and have been rebuilding myself over the last decade or so. I'm still a bit cranky and erratic, but I work professionally doing similar things to Scawen and Victor (but not Eric who's skills I don't possess) in another field - but i'm an employee. Knocking stuff up for LFS is my hobby.
If LFS doesn't use multi-threading, it's one of the few windows games that doesn't implement it. Multi-threading in games has been around since Windows 95, well over 10 years.
Generally the code is much cleaner in a multi-threaded environment because each thread's code focuses on one specific task, instead of having code fragments for the various tasks to be peformed scatterd throughout the mainline code. Separating physics and graphics into seperate threads would probably result in cleaner code.
Some form of messaging between threads makes this a lot cleaner (link to example below).
My first job involved a muti-tasking, multi-computer database system, back in 1973, long before "OOP". It was implemented on 6 mini-computers. One of the mini-computers was hooked up to the hard drive array, and did the actual database work, as well as keeping a transaction log for recovery in case a drive went bad. The 5 other computers communicated to the users, handling database inquiries and updates. Database requests and responses were queued on local hard drives, then sent between systems on a fifo basis.
My guess is that most Windows 95 and later first person shooter and racing games are multi-threaded. Note that NFS games have been multi-threaded since NFS2 (1997), but some of these have issues on multi-core systems.
Depends on the debugger and the debugger environment. Windows NT and later systems support remote debugging, allowing device drivers (some of which are multi-threaded) to be debugged. With the proper tools, it's not an issue. Generally you can choose to stop or not stop the other threads for an application or driver, when hitting a breakpoint in a thread.
However a non-graphics related thread, such as the main physics engine, wouldn't need access to direct x.
You don't need multiple cores for multi-threading to make sense. Any type of operation that requires the main program to "wait" for completion of that operation is a candidate to be spun off into a separate thread. A very simple example (see below), one thread reads data from a file, another thread writes data to another file, and the data is buffered and pointers to buffers are sent as messages between the threads. A third thread could be used to process the buffers if needed.
This is a tool (debugger) and environment issue.
Messaging usually solves this problem. Instead of hacking some global variable, messages are sent, such as position updates, between threads.
Windows solves this issue with WaitForMultipleObjects() (this concept has been around since the 1960's). If a thread needs access to multiple mutexes, and/or semaphores, and/or ..., it simply waits for all of them to become available and then acted on as a group, with a single, indivisible (threading is blocked by the OS during object access) call to the OS. All of the operations associated with each object type are handled by WaitForMultipleObjects(), such as decrementing the signal count in a semaphore.
Below is a link to simple example of a multi-threaded application. It's a file copy program that uses the current thread to read data from one file, and a created thread to write data to another file. The code uses semaphores (these have internal counters) to implement messaging via link lists, and mutexes for ownership for each instance of a link list, and demonstrates the usage of WaitForMultipleObjects(), with a mutex (ownership) and semaphore (message queue counter).
Setting this stuff up is a bit messy, but look at how simple the code in ThreadFile0() and ThreadFile1() is.
Getting back to game implementation, separating the graphics into it's own thread would probably make the code simpler. Similar to online play, the game sends position update messages to the graphics thread. One issue is what to do if the graphics engine can't keep up. The graphics thread could lower the graphics quality and/or skip frames. Being in a separate task, and the logic for doing this wouldn't end up co-mingled with the physics code.
Not quite sure what you're trying to say on account of the only just gotten up and out of bedness thing that I have got going on, but I think you're saying I use global variables, that I should store db transactions on a hard drive, an should set my threads up to message each other rather than use data I already have. *scratches head*
Not enough spacing in your code, don't have the patience for it.
*grumbles and heads off to get more morning coffee*
Two issues with global variables. You want "atomic" (indivisible) updates of those global variables, so you use a mutex. Often some means to let other threads know that a global variable has been updated is needed, so here setting an event or sending a message is useful.
If the global variable is a structure, to reduce the amount of mutex time, one alternative is to use pointers to two structure instances, one structure is the "current" structure, the other structure is the "pending" structure. The "pending" structure is updated as needed, and after the update is complete, the pointers are swapped between "current" and "pending" structures, and the mutex is only used during the pointer swap time. An analogy would be graphics "tripple buffering" when v-sync is enabled.
The messaging alternative is an array of structures, and an array of messages with pointers to those structures, then use messaging between threads to update the structure information. In the gaming example, the car position data could be sent as messages to the graphics task, which would then use this information to update and output video frames.
On modern systems, ram is used for messaging, but db transaction history is always stored on a hard drive, as part of the recovery process. If hard drive fails, then the previous backup is restored to a new hard drive, and transaction history is used to "replay" all activity that occured since the last backup to restore the new hard drive to the state of the hard drive that failed.
Generally, messaging between threads is better than peeking or poking global variables asynchronously.
Spacing ?.. I don't understand the problem. Note that the important pieces of that code are ThreadFile0() and ThreadFile1(), which are small simple routines. The rest of the code is overhead to setup the threads and messaging, plus the normal stuff like allocating memory and opening files. mtcopy.c is just a template I use for creating multi-threaded apps. I didn't intend on using it as an learning example when I wrote it, but it's simple enough to serve that purpose, since it shows the overhead coding required for multi-threading, mutexes, semaphores, combined with linked list messaging routines that make inter-task communication as shown in ThreadFile0() and ThreadFile1() simple.
I wasn't. You had listed a few problems that can occur with multi-threaded applications, and I was pointing out the fact that solutions to those problems were determined decades ago (such as WaitForMultiple...).
The small sample code I provided would help explain multi-threading to any programmers interested in this, and my main point was on topic:
The main point here is that by using multiple threads, you eliminate the co-mingling of otherwise independent code.
Not really, understanding the benefits for the entire userbase and of course for the application itself, and the work involved, the science involved. It's no simple feat to rewrite LFS code to become a true multithreaded application.
The more proffesionals discuss the differing mechanics within applications that are multithreaded, the better imo.
It probably is but with Moore's law having been negated, it seems like multicore uPs are not going to go away any time soon.
Then again despite are PCs that would benefit from having both cores used on full grids (mine is probably one of them), but the more Scawen waits, the more this PCs will be outdated, with the number of newer multicores becoming increasingly able to handle LFS single-coredly.
In the end I think with LFS needing developer time in an increasing number of areas, as far as I'd like to have multicore and as much as I'd benefit from it, on a bigger scale it's probably not the most useful way to spend Scawen time.
Finally, we commoners are bound to have absolutely no idea about how Scawen spends his worktime, so all of this is, just as Tristan hinted at, discussing for the pleasure of it.
Sorry i've been grumpy today and it's no fault of yours, I just read your post more as lecturing and I shouldn't have. I wouldn't pretend to be able to give an advanced lecture on multi-threading, as I said, i've used it in a number of tests and small-medium projects over the last year and am gaining experience at the pitfalls of doing so. The information I posted was for demonstrating to those interested without programming knowledge of some of the pitfalls of it and to give a basic understanding of the concept and what goes on.
Your reference to global variables and this point you made before suggests to me we have very different basic practices. This isn't unusual for me as I have found since turning to programming as a profession rather than just a hobby that I work in a completely different way to every other programmer i've worked with and I attack things from totally different angles. On the down side this meens I suck at some stuff, I meen really suck, but on the plus side it meens I often deliver things my co-workers and bosses didnt think possible. I'm self taught and being female I think differently anyway - before you add the after-effects of all the drugs I did in my youth...
To me, the things you mention are utterly not an issue even without multi-threading, it's just part of OO programming.
I don't use variables because I'll pass an object (or pointer to it) around, my objects are self-contained.
As for my own work I resist the urge to use messaging between threads and duplication of objects as any form of data replication is by definition simply too slow for me - and even when coding non-game stuff old habbits die hard, yes I understand messaging can be faster if a thread is waiting on a mutex anyway, but that's a matter of careful design work of the mutexing and also of knowing when you can get away with not locking the mutex in the first instance.
I dislike event driven approaches anyway as the code is messy and less optimiseable so I try to avoid it, especially in games, where consistent framerate is important and event queues can run awry, so I preffer to take a polled approach.
However you must consider I have no business with high end hardware - professionally I need things to run on low end single core machines aswell as make use of multi-core CPU's where available because that's where my market is, and in such an environment such overheads are a complete waste.
Anyway as I said i'm still learning and descovering new techniques in the field of multi-threading. It's one thing to know the commands, but it's quite another to gain the wisdom from using them. Like I was saying earlier about the first time you do something becoming trivial over time, it's simply a matter of experimenting with and developing techniques.
I have different view on this. The time he would spend on this now could bring only benefit. Later when the code would be more complex it would be simply more job to do. What could he save now woudl simply pay him back later.
(so which is it? lol)
