How and why to use threading in C++
h
CSharpIsGud (800)

Have you heard of multithreading and just wish you could make your programs faster?
Well... unfortunately just using threads is not enough, you have to use them correctly.
More threads can make things faster, but too many threads or using them on the wrong things can make it slower!

If you are building a house you undoubtedly have a lot of work to do, but if you have a team you can get it done faster.
If you do it all yourself without any help it will take forever, and it will take just as long or longer if all of you are working on the same thing.
So if everyone gets a different task then multiple things can be done at the same time and by the time they are all finished the house is ready to be put together.

Now this isn't a really great example as I couldn't think of a very good example of a program that benefits from threading off the top of my head but the idea is there and if you made it into a game or something with some more complicated logic like physics it would really make a difference.

I also couldn't find a very significant project to demonstrate thread safety reliably but I'll explain it.
To make that house you need wood or whatever you are making it out of right?
Well if everyone needs a piece of wood and two of them want the same piece what then?
Remember that you have a builder team of idiots so instead of just getting a different piece they both work on the same piece! Each one had a different job so the resulting plank came out an unrecognizable mess!
But if you tell them to take turns, everything works how it should. The second person has to wait for the first one to get their piece.

Basically, the whole benefit of threading is that you can do multiple things at the same time, like web requests for example.
If you don't have anything else to do while your threads are working, you might be better off with just a single thread.

You are viewing a single comment. View All
xxpertHacker (627)

More threads can make things faster, but too many threads or using them on the wrong things can make it slower!

More threads won't slow stuff down? More atomic operations will, right?
Unless you spawn over 50 threads that consume large amounts of memory and are CPU intensive, the threads themselves won't slow anything down.

Besides that, this really should've used std::cin.get() instead of std::cin operator>>.

CSharpIsGud (800)

@xxpertHacker The whole point of concurrency is to do multiple things at once, if you make a whole bunch of threads to do one thing it can be slower, or if you make a bunch of threads for a task only to turn around and wait for them all to complete it can definitely be slower than if you had just used a single thread.
I have a fibonacci program in C++ that I used a fast algorithm for, I tried to add threading to it and generate different parts of the sequence at the same time but it made it slower either because of the threads or that I had to wait for them to finish.

https://discuss.graphhopper.com/t/why-multi-threading-slower-than-sequential/538
https://www.quora.com/Does-a-multithreaded-program-run-faster-than-a-program-with-just-a-single-thread
https://www.techrepublic.com/blog/how-do-i/how-do-i-use-threading-to-increase-performance-in-c-part-1/
etc

xxpertHacker (627)

@CSharpIsGud Ah yes, I seem to have forgotten that your house building examples were given to emphasize that threads aren't meant to all do the same thing.
I forgot that too soon.

But I still feel like that ties more into the last part of your sentence, not the beginning, which is what I am arguing against.

...or using them on the wrong things can make it slower!

Whereas just using more threads won't make anything slower, it's the misuse of threads that can slow you down.

Also, do you have any estimate on how expensive it is to spawn a thread? If it's an expensive operation, then simply spawning the threads could waste more time than it could save.

I was recently thinking about making a multi-threaded compiler.
The program that would, from the very beginning, be split into four separate threads: the lexer, the parser, the optimizer, and the compiler (maybe the compiler and optimizer would be the same thing).
They would work in sequence, yet they would each work independently. The parser would have to wait for the lexer to lex the next token, yet the opposite is not true, the lexer would not have to wait for the parser to parse the token.
I am thinking of streaming the code all the way through, instead of just trying to do everything all at once.

In your opinion, would this be a bad idea or not? Do you believe it would operate slower than the single-threaded version? Do you have any suggestions as to how it should be organized overall?

CSharpIsGud (800)

@xxpertHacker Creating a thread can take like a thousand or so cpu cycles.

Even if you create it beforehand you still have the inter-core latency or whatever, so if you have small tasks that don't take much work at all to do you are better off not using threads for it.

A lexer doesn't have to wait on a parser anyway, it would still be parsed at the same speed because everything has to wait for the previous stages to do its tasks, most of the parsers thread time would be idling.

xxpertHacker (627)

@CSharpIsGud

Creating a thread can take like a thousand or so cpu cycles.

Ooh, that is bad. I'll keep that in mind when spawning threads from now on.

Even if you create it beforehand you still have the inter-core latency or whatever...

I have not heard this mentioned anywhere, not even the term; I'll have to go research it later.

A lexer doesn't have to wait on a parser anyway, it would still be parsed at the same speed because everything has to wait for the previous stages to do its tasks, most of the parsers thread time would be idling.

So, you're suggesting that I cannot attempt to stream the process? As it reads a token, I cannot attempt to send it to the parser immediately, but instead must wait for everything to finish? Are there other setups that could allow this?

CSharpIsGud (800)

@xxpertHacker You can stream it, but it will work basically the same. The parser won't be able to do anything until it has enough tokens from the lexer, so it will be idling most of the time. And idling threads kind of nullifies the whole point of using multiple threads.

As for thread creation, you can make threads in advance.
C# has its ThreadPool class which creates N threads that are always ready to be used.

xxpertHacker (627)

@CSharpIsGud I was going to spawn the threads at the start of the program, what is the difference between using a thread pool? Are they ready prior to program start?

CSharpIsGud (800)

@xxpertHacker Spawning them at the beginning of the program should work just as well.