3 ms·
From first look on article, seen something wrong, and now seen code and understand what is wrong. Algorithm I see is very simple, nothing could brake there, bu
by simne 4y ago
From first look on article, seen something wrong, and now seen code and understand what is wrong.
Algorithm I see is very simple, nothing could brake there, but author don't share communication routines, and here is core of problem.
Few years ago I have worked on project, where one thread sends huge amounts of data to other, using standard CriticalSection routines to synchronize threads.
They are simple to use, but even with hardware support are extremely slow - on 3Hgz class cpu give about million transactions per second.
I was too lazy to finish that project, but it's very clear for me, that I just need to rewrite messaging part, to send not one string, but batch of strings, so million transactions per second will be for example, 100 millions strings, or billion strings.
Same thing I see here - accept inter-thread communication is laggy, and rewrite code, so it will send larger packets, so there will be less transactions, and you will get easy performance gain.
- PaulHoule 4y agoYeah, I get into arguments with people all the time whenever I am "teaming" any kind of parallelism. I assume at the beginning that the unit of work is almost certainly so small that you can do many units of work in the time it takes to move a unit of work from one thread to another. Usually the other people are obstinate and insist on implementing something that is slower than serial execution, but they do come around unless they give up entirely when their attempt at a parallel speedup really causes a slowdown.
- simne 4y agoPeople love to talk about smart things. But when asked question about real implementation, people disappear, because nobody want to take even abstract (ethical) responsibility of consequences :)