On 2013-12-09 14:46:02 +0000, Dicebot said:
On Sat, 07 Dec 2013 08:51:22 GMT, Sergei Nosov wrote:
On Sat, 07 Dec 2013 08:33:22 GMT, Sönke Ludwig wrote:
As long as everything is I/O bound, which can be considered a common
case when DB queries and sizable pages are generated, a single thread
is the most efficient choice.Thanks, that actually makes a lot of sense.
- A good alternative can be to do complex computations using
runWorkerTask(which lets the task run in one of the worker threads)
and let all I/O and request processing still happen in the main thread.
This can often avoid explicit synchronization, while still fully
exploiting the CPU's cores and thus simplifies the overall program
architecture and may give a performance advantage.I believe, this can be thought of as you treat heavy-CPU parts of the
program as just another asynchronous I/O operations. Thank you for the
insights!Also if there is a continuous CPU-heavy task, it may be effective to
delegate it to own thread with hard processor affinity set (don't know
if vibe.d / Phobos provides wrappers for that) - impact of effective
instruction cache can sometimes be huge. As a general rule of a thumb -
every time you lock for shared resources in multiple threads you have
opportunity to improve your program concurrent architecture ;)
What do you mean? Is there a good way to avoid locking for shared resources?
-Shammah