John ROM wrote:
> ...[stuff zapped]...
> I think this is great because grizzly should always try
> to take advantage of multicore.
>
> DynamicPool.start() pool uses
> Runtime.getRuntime().availableProcessors()
> to init Pool.
> Maybe one should use code like this in furture more often in grizzly?
>
>
We should be careful with Runtime.getRuntime().availableProcessors()
since CMT (chip multi-threaded) cores will report each hardware thread
as a virtual processor. For example, a Sun T2000 with 8 cores and 8
hardware threads per core will result
Runtime.getRuntime().availableProcessors() returning 64 processors.
Out of those 64 available processors, only 2 hardware threads per core
can execute on a given clock cycle, (there's two pipelines per core).
So, you may have a few more available threads in the pool than you
really wanted / intended.
We'll likely see additional chip vendors introducing similar chip
architectures. So, we might need to do some further "learning" of the
runtime to initialize the pool.
However, I really like the idea of dynamic / adaptive thread pool sizing.
charlie ...
... [other stuff zapped]...