Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gatleos]

I have verified that the .exe does indeed not find the graphic files. Gotta figure out why.

Obvious question: what file type are they?

[Darvi]

Bitmap.

[Valid_Dark]

I've recently been looking through the changes brought about by c++11, and honestly if DF was made in c++ it really shouldn't be too hard to implement multithreading support, now that it is supported by the standard library, and appears to be much much easier that the old way of doing it.
Basically
step 1: include <thread> header
step 2: change how functions are called so they are assigned to a thread
step 3: join thread with main

anything that is written as a series of functions should be easily converted to multi threaded support.

example of a program that prints hello world from 4 different threads.

Spoiler (click to show/hide)

Code: [Select]

#include <iostream>
#include <thread>

 
void helloworld() {
    std::cout << "Hello, World!" << std::endl;
}
 
int main() {

    std::thread t1(helloworld);
    t1.join();

    std::thread t2(helloworld);
    t2.join();

    std::thread t3(helloworld);
    t3.join();

    std::thread t4(helloworld);
    t4.join();
 
    return 0;
}

can someone with experience with c++11 tell me I'm wrong or agree with me?
Dont just say multithreading is harder than that if you don't know what your talking about.

most compilers aren't able to work with c++11 yet, which is kind of lame.
including the one I'm working with, and I really don't want to change my ide,
perhaps when I get around to actually using some of the new c++11 features either the compiler I'm using will be upgraded, or I can swap out the compiler but still use my ide.

[Stargrasper]

I'm not sure about C++11, but in Java, getting threads in is easy.  Keeping them synchronized is the hard part.  Making sure nobody is concurrently trying to write something and making sure you don't have race conditions; things like that.  You can fork a thread anywhere, but join is a blocking operation in Java and it may be in C++11, but I don't know this.  Basically the real problems usually boil down to synchronization.  At least in my experience.

[Gatleos]

The problem was never that Toady didn't have multi-threading support available to him, but that implementing it would require a re-write of most of the code to function properly.

Also what Stargrasper said.

[Siquo]

I've recently been looking through the changes brought about by c++11, and honestly if DF was made in c++ it really shouldn't be too hard to implement multithreading support, now that it is supported by the standard library, and appears to be much much easier that the old way of doing it.
Basically
step 1: include <thread> header
step 2: change how functions are called so they are assigned to a thread
step 3: join thread with main

Yeah, except that wouldn't help anything. "thread::join" makes the main thread wait for the current thread, so there's no speed increase anywhere, AFAICS.
And secondly, putting the joins at the end might render stuff like "HHHHeeeelllloooo,,,,    WWWWoooorrrrlllldddd!!!!", or "Hello, World!Hello, World!Hello, World!Hello, World!", or any weird permutation in between, depending on the implementation of your print-function (I'm guessing the c++11 cout is ok, but you can't just put any function in a thread).

[Valid_Dark]

I've recently been looking through the changes brought about by c++11, and honestly if DF was made in c++ it really shouldn't be too hard to implement multithreading support, now that it is supported by the standard library, and appears to be much much easier that the old way of doing it.
Basically
step 1: include <thread> header
step 2: change how functions are called so they are assigned to a thread
step 3: join thread with main

Yeah, except that wouldn't help anything. "thread::join" makes the main thread wait for the current thread, so there's no speed increase anywhere, AFAICS.
And secondly, putting the joins at the end might render stuff like "HHHHeeeelllloooo,,,,    WWWWoooorrrrlllldddd!!!!", or "Hello, World!Hello, World!Hello, World!Hello, World!", or any weird permutation in between, depending on the implementation of your print-function (I'm guessing the c++11 cout is ok, but you can't just put any function in a thread).

either

"HHHHeeeelllloooo,,,,    WWWWoooorrrrlllldddd!!!!", or "Hello, World!Hello, World!Hello, World!Hello, World!"

would really be perfectly what I was going for.

"thread::join" makes the main thread wait for the current thread, so there's no speed increase anywhere

then that solves the synchronization problem that was supposedly the difficult part in implementing strings in java.
multiple threads running at a time but making main wait for them all to finish would be much faster than 1 thread doing it all one at a time. do you even know what multithreading is? honestly

The problem was never that Toady didn't have multi-threading support available to him, but that implementing it would require a re-write of most of the code to function properly.

this version of threads wasn't around when toady started making DF, the version that was around was a massive headache
the only re writing this would require is re writing how functions are called.
(scan code, find function, add a few words before it, BAM)
I think the reason you said that is because thats what everyone says when multithreading is ever brought up, and no one actually thinks about it, they just regurgitate what they heard others say.

[Siquo]

do you even know what multithreading is? honestly

That's not really nice...
I merely pointed out that creating a thread, then waiting for it to finish, is NOT faster than one thread doing that same thing, even if you do it x times in a row.
I think what you meant was:

Code: [Select]

    std::thread t1(helloworld);
    std::thread t2(helloworld);
    std::thread t3(helloworld);
    std::thread t4(helloworld);
    t1.join();
    t2.join();
    t3.join();
    t4.join();Which is substantially different.

[Valid_Dark]

ya, thats what I meant >.<
a semantic error/logic error on my part.

I thought you were trying to say waiting for all of the threads to finish wouldn't be as fast as doing them one by one because you'd have to wait for them all to finish.

[alway]

The main reason threads aren't used for DF is because Toady sees them as too much of a hassle. Aside from simply learning and rewriting code, multithreading bugs are much harder to find and get rid of, which overall would slow down the development of DF. Every time a new module of code is added, you need to ensure it doesn't interact improperly with other threads, ect, also removing a lot of flexibility in rewriting or modifying systems.

[Gatleos]

The problem was never that Toady didn't have multi-threading support available to him, but that implementing it would require a re-write of most of the code to function properly.

this version of threads wasn't around when toady started making DF, the version that was around was a massive headache
the only re writing this would require is re writing how functions are called.
(scan code, find function, add a few words before it, BAM)
I think the reason you said that is because thats what everyone says when multithreading is ever brought up, and no one actually thinks about it, they just regurgitate what they heard others say.

I never said he couldn't do it, just that it's a low priority of his because it would require a re-write and slow down future development (as alway said). You're correct in saying it would be easier now, but it's far from trivial to implement at this point.

That said, C++11 is AWESOME.

[Siquo]

That said, C++11 is AWESOME.

QFT.

[Stargrasper]

--stuff--

You're misunderstanding some fundamental parts of threading.  join() is a blocking operation, which means it waits at that operation for the thread to return.  That does not, by any means, solve the vast majority of concurrency problems.  The only problem that solves is ensuring that certain threads have returned by the time you do some subsequent action.  It doesn't solve concurrent writing nor does it solve race conditions.  Nor really any other concurrency problem...  Use enough threads for enough things and you'll start running into funky behavior.  Also forking off a thread does not make things faster.  It lets the program use an extra process, which might be run concurrently with the original if you have multiple CPU cores.  In fact, if you have too many more threads than cores, it actually slows down the program because it has to round robin all the threads.  Basically, when the CPU needs to run more processes than it has core, it starts and stops them seemingly at random to make sure they all get a turn to do what they're supposed to.  At this precise moment, my computer is running 65 processes.  I have two cores.  The OS has its work cut out for it figuring out how to let all of them do their thing.  A lot of these processes are blocking or sleeping or something, but the OS still has to give them their turn so they can basically say "come back later".  Then there's all of those daemons; any processes that run in the background without user intervention.  They run in the background without you ever noticing them...although you'd probably notice if one of them suddenly died when, say, the internet suddenly stops working because the daemon running your network card died.

Threading DF wouldn't be beyond Toady's ability.  It would take awhile, but if done correctly, could potentially improve performance.  The hardest part about threading existing work is that you need to figure out what you can thread.  You absolutely can't just throw any function into a thread and expect it to work right.  Threading involves a lot of careful planning.  If the program isn't designed with threading in mind, it can be difficult to figure out what you can and can't reasonably do.

Threads aren't magic.  They don't automagically make programs faster.  They just give it the ability to do more than one thing at a time.  Whether you call it threading, concurrency, or parallel; it's a major subject that's rather complicated.  Universities have entire classes on parallel...

[Valid_Dark]

i don't know what a race condition is,
but solving concurrent reading/writing to my knowledge should be as easy as making sure only 1 thread has access to certain variables at a time.
I know it's much more complex then i'm making it out to be,
dumb analogy time
I imagine it like a series of gears, and i'm saying just make sure no 2 cog teeth are occupying the same physical space a the same time.  because then it won't run,  sounds easy, but in order to do so the whole system has to be carefully designed and each cog made to specific specifications so it will all mesh nicely.

Universities have entire classes on parallel...

yes, but universites also have entire classes on intro to java, or entire classes on storytelling,
Just because it's something thats offered in a class at a university, or has an entire class at a university devoted to it, doesn't mean you need to take that class to understand it.

[Darvi]

yes, but universites also have entire classes on intro to java,

They do؟ *totally missed that part of college. Aherp*