Hi,

I will make it short and will leave this for a discussion rather then bringing my own opinion which might subjective.

I dont really see the disadvantages of multithreading in LFS.

Quote from Nadeo4441 :

I dont really see the disadvantages of multithreading in LFS.

Same - however from what I've heard it would add a small overhead to single-core PC's.

I'd be interested to know what anyone who understands programming thinks, though...

Slight overhead for single-cpu's, check.
A lot of added complexity, but kinda depends on how LFS has been coded. A few bugs might be introduced, deadlock is a stupid one.

Is it nescessary? Currently it will probably have no advantage at all, considering any current CPU with more than 1 core is fast enough to run LFS pretty well anyway.

Quote from Nadeo4441 :

I dont really see the disadvantages of multithreading in LFS.

Thats why I wanted open it rather for open discussion then coming with some argument for or aganst together.

My argument for would be better framerates at start with full field for example, adding more phzsic calculations hence allowing the modulation going further and deeper.
¨
On the other example like was mentioned already above is overhead for single CPU. Or if developed further only ad multuthreading it would raise the hardware requirements.Hence some people might quite or it might interesting for less people. Alo of option for and against.

Opinions and disucssing is welcome...

The overhead for single core is nothing to consider, it is possible to disable multithreading in the software by checking the number of cores. Of course, this results in even more coding.. Not simple at all.

The main issue with multiple threads is all the sync work that is required to keep everything in line.

Thread based programming can be very error prone and difficult to debug. The tools are getting better but deadlocks and overwritten data are the main fights from how I see it.

If LFS was not created with threads taken into account it could be a fair amount of work pulling everything apart so the correct sync logic can be implemented.

What about with hyper threading?
I mean if you have a computer that doesn't have hyper threading then it was bought like.. nearly a decade ago now, I just don't see an issue, you have to try hard these days to get a single core computer, and either way it has hyperthreading in it so.. what's to worry?

What about coding wise, does seperate piping translate to more code or what?
ei would it make sense to do it, unfortuantely I hate to put a burden on Scawen but the answer would be yes, LFS is still using dx7, I hate to say it but if there is any way forward.. it needs to start because LFS is far behind in many accounts, but that is just totally biased and easy for me to say because I'm not the one coding.. which is why I changed my major to art lol!

Quote from XCNuse :

What about with hyper threading?
I mean if you have a computer that doesn't have hyper threading then it was bought like.. nearly a decade ago now, I just don't see an issue, you have to try hard these days to get a single core computer, and either way it has hyperthreading in it so.. what's to worry?

You are forgetting about AMD. Hyperthreading is only a Intel thing. Also Hyperthreading only offers around 10% (iirc) advantage over a traditional single core processor.

Multithreading requires more code to control all the threads. There is more polling between threads required too, other threads have to ask in what state certain thread is and only get the data if the thread is in the right state. This is why with multithreading you need to structure the code in a different way than with only one thread. Ideally you want the threads to work as independently as possible. How long switching to multithreading would take depends on how LFS is structured.

In my opinion this should be quite high on the todo-list. Multi-core CPUs are pretty much the norm already and making the switch will become harder as more features are added on.

I know HT isn't that efficient, but it still works with multiple core code is all I was getting at with that.. (since LFS has always been careful to include as low possible spec computers as possible!)

Quote from XCNuse :

LFS is still using dx7, I hate to say it but if there is any way forward.. it needs to start because LFS is far behind in many accounts

Hey, you speak out of my mind but its true.We are not coders and Scawen is the boss here.

It's really not that complicated to write a multithreaded application, all the polling between threads thing and what have you, you use something called a mutex. If you have a good mutex system it all sort of falls into place.

However applications do need to be structurally written in such a way as to support multi-threading. Personally I could not even imagine doing multithreading in a non-OOP environment and LFS isn't exactly OOP internally, having said that i'm not Scawen either and in his way of working it might be easy for him.

There isnt really any noteable issue for single core systems. When I write a multi-threaded application I extend off a threading class - as some people elluded to above sometimes it can be hard to debug a multi-threaded application - so when this happens I simply switch things to extend off a non-threaded class that works in much the same way but from the main thread. (which one of the reasons I couldnt imagine doing multi-threading in a non-oop way), so there's that approach - but more significantly we're talking about a very minor increase in overhead anyway, at a guess i'd say less than a tenth of a percent, maybe less than a hundredth.

In terms of what benefits it brings, on the Windows platform only the main process can access DirectX, daughter processes cannot access DX, so the enhancements aren't necessarily as great as imagination might suggest. (Note: although not rellevent to LFS being Windows only, different platforms have different limitations on what daughter threads can access).

Ultimately however the decision is down to Scawen, and he has spoken on this before - around a year ago he mentioned that he did see multi-threaded support as something LFS would eventually have. He estimated it would take him roughly a month to convert LFS. That, more than any subject analysis that us lot can make, is gospel.

Hey we never know that could be what is holding up 0.6A scawen could have decided to introduce multi-threading.

Quote from Becky Rose :

LFS isn't exactly OOP internally

Any fact to back this up? Just being curious here

Quote from BurnOut69 :

Any fact to back this up? Just being curious here

Yes, I read what Scawen says, sometimes, when i'm not feeling narcassistic and re-reading my own posts.

what is multithreading?

Quote from swisscosmo :

what is multithreading?

Multithreading in very simple terms is the ability for a program to use multiple cores of a processor simultaneously - so in your dual core system LFS could make use of both cores at once.

In more complex terms, a thread is an 'object' or 'package' of code that runs as it's own entirely seperate process. The OS then moves these threads around between processor cores to distribute processing load. You can have lots of thread in a single program. So you might for instance have a different thread to handle the physics on each car, one to handle network communication, one to handle insim, and so on...

Each thread could, in theory, run on a totally different processor (if you had enough processors), though in practice with dual and quad core processors what happens is the threads get moved about between the cores and share processor time with all the other background tasks running on your computer.

Multi-threading makes full use of modern processors to get more out of your system. It's quite easy for an experienced programmer to do, but:

* You need to design the structure of your program to work well with threading.
* Debugging after implementing multi-threading becomes a little more difficult
* When doing anything complicated you end up with so many mutexes to stop it from crashing that the threads spend most of their time waiting for mutexes to unlock anyway and you dont actually gain anything - oh the bitter irony... (and as most of you wont understand this last point or the bitter pills of experience it is spoken from, i'll just toddle off now).

Quote from Becky Rose :

Yes, I read what Scawen says, sometimes, when i'm not feeling narcassistic and re-reading my own posts.

Thanks for the insight but I was asking for a link, not a half arsed joke or whatever that was.

Quote from BurnOut69 :

Thanks for the insight but I was asking for a link, not a half arsed joke or whatever that was.

oh right, well I can hunt through his many thousands of posts for you but I charge quite a high hourly rate :P

Sorry, I have been around a very long time and can't place it and I have a terrible memory anyway, so i've read a lot of posts by Scawen, I pay attention to a lot of what he says because I admire what he has done with LFS. I find it inspiring, and i'm not so big as a programmer that I can't learn from others - so yah, I listen to what he says when I see something, in the idle thought that one day I might be able to recreate what he's done here in some other genre or other. I regard observing and understanding success as a step toward achieving it, so that the next time I have a huge project on the go (and i've had several in the past) I don't blow it by acting like me.

Quote from XCNuse :

I know HT isn't that efficient, but it still works with multiple core code is all I was getting at with that.. (since LFS has always been careful to include as low possible spec computers as possible!)

HT is a complete bodge by Intel to pretend there are multiple cores when this is not true. Each "pretend" core shares resources so only one action occurs at a time as per single core CPU. The only gain is context switch speed.

Net result is HT is faster sometimes and slower others.

What would benefit LFS is WORK.

And that stoped to an unbearable crawl over 2 years ago.

Some people left , tired of contributing to a non working engine, who to this day, some still think works.

Bottomline, humans can convince themselves of anything.

In LFS being deaf has become a strategy. Its oh so quiet.

I typed this from a confortable sofa.

Back to iracing.

Quote from DoctorZoom :

And that stoped to an unbearable crawl over 2 years ago.

A bitter banned user, or a completely unknowledgeable post .. given your join date in January 2009...

I tried to explain how hard it is to take a single threaded program and make it work on multiple core systems to some people on another forum and they just woulden't listen to me.

I'm glad to know that I was right at least. Unless LFS was written with future multi-threading in mind it could take an insane amount of time to re-write the whole code base to play nicely on a multiple core system

Multi-threading won't hurt anyone with an intel single core processor these days though, as others have said, the overhead will basicaly be offset by hyper-threading. And on AMD systems it's still so little that it won't realy hurt them anyway.

As far as hyper-threading giving no real gain in performance, AMD claimed it hurt performance in some cases, that seems to be partialy true. But I find it's also largely based on the program and in most games made for it, and even some that arn't, I see higher frame rates with it on. Maybe even more than %10 gain in some cases, but it isn't anything like a dual core.

Quote from DragonCommando :

Unless LFS was written with future multi-threading in mind it could take an insane amount of time to re-write the whole code base to play nicely on a multiple core system

Oddly in LFS' case it may not be so bad as other games, the reason being 1 person wrote it.

When decoupling a piece of code to run it as a seperate thread you have to add mutexes to 'lock' resources that it will write changes too so that other threads dont try to read off partially written data and cause a crash. Once finished you release the mutex and other parts of the program can then lock the resource down to use it.

Mutexing has two ramifications. Unless you carefully design your mutexes you wont gain any performance out of the extra cores because your other processes will be waiting to execute. This is indeed specifically what is meant by "structuring your program for multi-threading".

The second ramification, based upon this, is in knowing what resources use what other resources. In todays modern object orientated programming world it's quite common to be completely unaware of other parts of a program written by somebody else - in big projects it's not uncommon to find multiple objects/methods that do the exact same thing - written by different programmers completely unaware of the others work. This makes planning your mutexing strategy extremely difficult, which is why converting a single core program and actually making use of the extra power can be a real pig.

LFS has a huge advantage here because it is written by 1 programmer, who therefore has a far greater understanding of the entire program flow and understands what resources cross reference each other.

Multithreading won't hurt LFS. But any multithreaded application needs to have a damn good way to synchronize data between the threads, or else you can get into deadlock situations which will be very painful to debug, which is very hard to do as it is.

Scawen has said he would like to separate the graphics and the physics engine and make them run on separate threads, which sounds like a very difficult task to me. I'm not sure how much it would help though, as LFS doesn't have revolutionary graphics which would need to run in their own thread. I would just have the physics for each car on the track run in it's own thread, I feel that would get more out of the CPU. Again, they would need to be synchronized very well for this to work properly.