Sunday, 4 December 2016

Adventopolis #4 - Freaking threads

I need to write this, no matter what, and I hoped to finish some part before 11:00 but it's what happens when you get some nasty bugs and you want to just write hacky code just to test something and maybe write it better the next day. You think it's gonna end in 5 minutes and then you realize the last thing you wanted to try tonight doesn't fucking work and you are flipping tables.

Anyway, long story short, I tried std::threads on my PC framework and the idea is to test multithreading in some bitmap effects like the usual plasma. I have tried threads before by calculating something that takes like 10seconds and can fall to 5, 2.5 and so on. That worked like a charm. Now I am getting puzzled trying to create threads, split the image rendering in parts for each thread, then destroy them of course (task done). And I realize everything is going much slower and there are jumps. Wtf, using more threads makes things slower? Well yes, but there is a well known reason I didn't know..

Most of the tutorials on threads before was to calculate something that takes time. Create new threads, run some raytracing that might take 8 seconds, then destroy threads when you finish. But realtime effects have to refresh several times per second. It could be 60 times per second but if you are testing something for extreme performance, so if my plasma runs at 700fps and I am testing it if it can go more (don't know because of video ram bandwidth, but that's what I am curious for) then I init and destroy threads 700 times or more. And even if it seemed little, I realize this totally kills it and I get jumpy frames from 200 to 500.

And then it hit me. For things like that, I should create the threads in the start of my program, and let them continue running, having a boolean to wait for jobs, only when a part of the image rendering wants to run on a thread let it work with that, then when it finishes that part go back to waiting state. Don't destroy threads unless we exit that demopart or even the app. Maybe I could have for example four threads always on and waiting for works, till I give them some of my effects.

What I was thinking is something called thread pooling. Now I know the hard way. I have heard someone mentioning it and I thought ok that sounds good, I'll check it. Although I didn't know what that is. Now I thought it for myself and then by searching I found I was thinking of thread pooling.

So, because I at least wanted to see my effect running multithreaded correctly for a chance, I wanted to make a fast hack with some booleans. And I was getting into crashes. I knew for a thread pooling I have to sit back and think about how to implement it, but it was 10:30pm and I wanted to finish a fast test by 11:00pm. So, I was flipping tables, when my fast hacks where crashing. I thought I almost got it now but I stopped to write this post before midnight.

I guess I should scrap my code and think of thread pooling thoroughly. Tomorrow? I don't know. It's an interesting subject, however I am waiting for the day to switch to some other projects. This will take more time, I shouldn't rush it.

p.s. other than that, I spent most of my day playing Doom (classic) and then watching some 100% speed runs of Metal Slug series.

No comments:

Post a Comment