Boian Mitov wrote / napísal(a):
Thank you!
I agree.
To summaries my opinion:
1. Massive multicores are slowly becoming a reality.
2. The modern compilers do little to support them aside from some
library support.
3. The need for such support is not urgent, and probably will not be
for at least 1-2 more years, but the demand will start to rise.
4. The best approach is to keep an eye on what the other compiler
developers are doing, and try to follow the proven path ;-) .
5. In the mean time any good developer an utilize the existing tools
and design true multithreading architectures. We have enough tools for
that (Well maybe with the exception of a fast "Multi Read Single
Write" implementation, but the life is never easy ;-) )
With best regards,
Boian Mitov
--------------------------------------------------------------------
Mitov Software
http://www.mitov.com
--------------------------------------------------------------------
I didn't want to add fire to this discussion, but I think one thing
needs to be mentioned, and that is graphics card usage from Threads and
possible APIs and their limitations.
I was at #opengl channel a few times recently due to work and personal
hobby too, and once I asked about doing basic texture loading in
threads. It came down to it that the openGL API is completely thread
allergic, however after a short discussion it was concluded that with
today's cards (and the trend here isn't changing AFAIK), the pipeline
would serialize all the calls in the end anyhow.
In other words, having a thread-safe API for gfx calls would bring only
overhead (e.g: DX 11 or original concept of GL 3.0)
Just thought I'd mention this little bottleneck of the future (for games
at least.. with 32+ cores, having only 1 doing the graphics I think
could be fatal, especially since data throughput probably won't get much
better on the main bus, e.g: RAM/Disk/VRAM transfers).
As a tidbit, I *heard* (rumor level truthfulness) that the "objective"
GL 3.0 threadsafe concept was thrown away in the winter, and that GL 3.0
will be a continuation of GL 2.0, not a rewrite. Take with a pinch of
salt, news on this front will arrive soon :)
Ales
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
