Wow Thanks becky I do have a Dual Core 2.4GHz Intel Processer so i would be ok i think
Poll : Multithreading as option in LFS?
Yes
115
No
30
Wow Thanks becky I do have a Dual Core 2.4GHz Intel Processer so i would be ok i think
In fact data is not syncronised at all, it is shared, and this is part of the problem.
Allow me to put this in a simple example form so that the general readership can follow it, I hope I can express it clearly:
Imagine you have a cars position in 3D space stored in the 3 axis: X, Z and Y for height. We have one thread doing the physics and another thread doing the drawing.
Now if the physics thread update the co-ordinates it will do so one co-ordinate at a time: X, Y and then Z.
If the graphics thread then reads the new X position but gets to the Y before the physics has updated it, you might get co-ordinates that look like this:
X New
Y Old
Z Old
So the car would suddenly move sideways on 1 axis whilst not moving in the other two.
For some things this can be done safely as it doesnt matter if the data is a fraction out-dates, and other things it is more critical and can cause random glitches, or in the worst case a software crash.
This is what mutexing controls, so you get this...
Physics locks the mutex
updates X
updates Y
updates Z
Physics releases the mutex
Graphics locks the mutex
reads X
reads Y
reads Z
Graphics releases the mutex
It's this locking and releasing of mutexes which adds overhead for single core systems, so the extent of how it effects single core systems is once more down to the design of the software and how extensive the various locks and unlocks need to be.
The other big problem that can occur and is the bain of multi-threaded programming is when two threads are dealing with multiple mutexes and end up waiting for each other to release resources... Imagine this scenario
Graphics locks mutex 2
Physics locks mutex 1
They each do some stuff
...
Graphics tries to lock mutex 1 but it is alread locked so graphics waits
Physics locks mutex 2 but it is already locked so physics waits
Both threads are now paused waiting for the other to finish and unlock the mutex, but this never happens because the threads are paused.
This is what causes some modern games to 'freeze'.
Fascinating stuff Becky. Really, really interesting.
Are you joking or beeing serious here? I never know with you
When that is said, so to say it more easly (sorry, did not read all replie in topic), it's all about just using more than one core at same time when playing LFS? Dual Core?
Most of the computers nowdays has that, so I don't see that as a neagtive thing, to utlize the system better.
I also remember Scawen said it probally would take 1 month of coding to get it right, I am not bottered to search sorry, but know it was in Improvement Suggestion forum, and about some dual core thingy.
Being serious. I'm finding it very educational. I love to hear about stuff that I don't know about.
Whilst I'm not a big fan of off-topic (and I realised this isn't off topic per se), there should be more threads about the finer aspects of other activities/hobbies etc. I put my heart, soul and mind into my hobbies, and try to understand them as well as I possibly can, and put all my energy into them. But some things just aren't for me, so I never get an inkling of, in this case, how interesting multi-threading techniques actually are.
Whilst I'm not a big fan of off-topic (and I realised this isn't off topic per se), there should be more threads about the finer aspects of other activities/hobbies etc. I put my heart, soul and mind into my hobbies, and try to understand them as well as I possibly can, and put all my energy into them. But some things just aren't for me, so I never get an inkling of, in this case, how interesting multi-threading techniques actually are.
Scawen's post, regarding dual core usage:
http://www.lfsforum.net/showthread.php?p=241752#post241752
http://www.lfsforum.net/showthread.php?p=241752#post241752
Glad to have been of service *deep bow*
Now when are you taking me on that race meeting date hun?
Now when are you taking me on that race meeting date hun?
Great find, thanks for doing the search
August 1st, Silverstone. Be there, or be square!
I'm in no way an experienced programmer, but even in simple programs and even with a lot of discipline there *will* be difficult to identify bugs related to multi-threading.
A couple of months ago I started to develop a basic game engine that utilizes multi-threading. Even though I kept my game structure as simple as possible the darned thing will generate the most outrageous bugs.
So far I could only solve the issue by making the program switch between it's threads sequentially (physics thread finishes, GFX starts, GFX finishes, physics start, etc.) which completely defeats the purpose...
I can't imagin having to restructure a program that wasn't written with multi-threading in mind.
An example:
In a sequential program its a good idea to group e.g. the graphical properties of a car together with it's physical properties. That makes sense because a dented front bumper both has a visual effect and physical effects. Also an engine has both a physical effect and a sound effect. So why not stuff all these properties into a common data structure?
Enter multithreading. Up to now you thought you had a well structured program but now, since multiple threads can't work on the same data structure simultaneously, you have to treat a car's physical properties in one thread, the graphical properties in the other and have another thread to have sound effects. And you have to make sure that at no time one thread uses the other thread's data, so your sound thread isn't allowed to just ask the physical car data structure for the current revs. You have to either make the physics calculations stop for a bit, get the data, and make it continue or write some sort of moderator that distributes data between the threads. And in a complex program you have to be some sort of walking program data flow diagram to not at any point get your data mixed up. But if you get it wrong anywhere the program will behave oddly and cause crashes, freezes or unsynchronized data between clients (read: drop outs).
From what I've read from some developer diaries complex real time strategy games face a similar problem because they have to strictly differentiate between the shared network-state of the game and the presentation on screen. Most people propably noticed how long it takes the developers of such games to find random desync-bugs because somewhere an invisible object that is only created every 25th game uses a time-variable from the GFX-particle system to determin it's own life-time and thus causes a desync if the framerates of the involved clients are sufficiently far apart or something similarly absurd.
Bottom line: Switching to multi-threading is, in my mind, an extremely difficult job to handle.
Vain
Quoted for truth. It really is more complex than it seems, which is actually a property of the linear (procedural) way C(++) seems to be.. At least IMO.
That's why languages like Haskell have been made, which is more easily parallelizable. It's required when we get the 100+ core processors Intel promised :ices_rofl
Yes debugging is harder with multi-threading, but with experience it gets easier. Like the first time you write something in 3D and 18 pages of code later you finaly get a spinning cube, and a year later you do the same thing in 3 lines...
Everything in programming seems complex on the first attempt and becomes 'a system', then years later it's totally trivial and arbitary.
For instance I have particle systems in some of my old games and test projects which are much better than those in use in LFS, to me it's an utterly simple and menial process and something that happens in my games when I go "oh i'll quickly do the particles" and a few minutes later there they are. Yet I look on indi programming boards and people buy 'particle systems'. It's simply a case that i've done a lot of them, so it's become trivial.
The same is true with multi-threading, and any other programming concept. I'm not yet 'expert' with multi-threading but already I can see the difference in the way i'm using mutexes compared to when I started, and although not yet heavily practiced i'm finding it much easier.
As a result of practice i'm now much more proficient at debugging multi-threading than before, and have devised various methods and tools for doing so (such as moving an object to run under the main thread by a simple class extension and a hook in the main loop etc).
Having said the above, you are absolutely right. One could find that moving stuff around becomes a necessity and that can break all many of obscure scenarios, however...
This is why I like the OO approach even on projects I develop by myself, things become self contained. Scawen isn't a fan of this approach however so I know LFS isn't written this way. Certainly, under a well considered OO approach the decoupling of processes into threads in LFS isn't something i'd be particularly put off by.
However, because of where we are in the LFS timeline, the fact that it hasn't yet been done, and the fact it causes issues with debugging later - I strongly suspect we wont see multi-threading until much later in development.
Wicked - I happen to be free that day
.nvm, my brain is mush today
I saw what you wrote before the edit
.Core2Duo processors don't have hyper-threading on them. Hyper-threading was dropped after the Pentium4, and only since November 2008 where they introduced the (re-badged) Core i7 processor (Quad core), did they use it again.
Don't suppose that many people are using Core i7 processors yet. And if you're talking about that kind of speed to be running LFS, then who cares if you have multi-threaded applications anyway? It'll walk anything, pretty much, on a single core.
@Becky Rose: I've spent two 12 hour shifts reconfiguring networks, my sense of humour is somewhat wonky. I read what I wrote and thought "no-one will get that & you will look like a lunatic" 
"delete" post.
Hope you have a nice day at the races. I'm very envious.
</OT> sorry.
"delete" post.Hope you have a nice day at the races. I'm very envious.
</OT> sorry.
I've got a Core i7 920
I don't think LFS is CPU limited
I don't think LFS is CPU limited
The Intel Atom's have hyperthreading - Not sure what'll happen with the desktop uses of Atoms in the next few years though.
Oh it's easy you just have to flirt with Tristan until he's having a bad day and relents to letting you come along just to shut you up. Next I have to talk him into picking me up.
Oh, he softens up with a bit of flirting does he?
/flashes some leg
i thought the atoms were single/dual-core... looking at wikipedia (ugh) says Q4 2009 for anything with HT in it...
Thats wrong then.
http://www.youtube.com/watch?v ... T7y-c&feature=related
Check the video out at 3:30 it will show you that it has 4 threads.
EDIT: wrong your post wrong, they do have dual core versions with HT enabled
Indeed, earlier atoms didn't have HT, later models do. I stand semi-corrected.
:Eyecrazy::vomit:
Multithreading - benefit for LFS or not?
(118 posts, started )
FGED GREDG RDFGDR GSFDG