Rob,
In dotNetRDF, there is parallel execution, isn't there?
I have been thinking (toying with) the idea of parallel execution and I
wondered what unit of work is for the parallelism in dotNetRDF.
What little thinking I've done suggests that tapping into the
parallelism in java streams is not the right way to do it (which is a
shame as that's less work). It needs more control and probably larger
units of work. There is a danger that small/fast queries slow down due
to too much thinking.
It needs more control as well to limit how much of the machine it will
take over because, in Fuseki, it might lead to starvation of other
requests. As some usage is " many clients, many small requests",
parallelism can impact the the system negatively as well as positively.
At some point, the limitation will be the connection of CPUs to RAM
rather than cycles.
Andy
Historical note: RDQL had true parallelism once-upon-a-time. An RDQL
query is a BGP+Filter and not more. The filter ran on a separate thread
to the BGP solver. Timed gain ... just 10%. This was on a early
generation 2 CPU, 2 processor machine so the cost of threading was huge.
Most users then did not have a multi-anything machine. It lead to lots
of problems with thread management when Java wasn't what it is today.
