[Bf-committers] Re: Thoughts on speeding up...

[GSR - FR]

Hi,
stefang at aon.at (2005-03-23 at 2334.05 +0100):
> On Wednesday, 23. March 2005 23:19, Austin Benesh wrote:
> > Well, the problem is that Blender is currently a mainly single-threaded
> > application. Many of us have robust, dual CPU machines with support for
> > simultaneous multithreading. What should be possible is that Blender
> > computes the scene in the background, and as you edit the scene, it
> > 'builds' upon this current computation.
> How many is many? Dual CPU machines weren't that widespread the last time I 
> checked.

All the Intels with Hyper Toasting^WThreading could * make use of
that, plus the new plans for dual core (and of course the combination
of all them: SMT, discrete and multicore SMP) seem to "paint" a future
where speed ups have to be won by paralelizing. So next times they
will be a bit more common.

Maybe better go ahead if someone wants and can do it, the same way
than new code should be 64 bit clean. :] In the case of threading I
would suggest targeting a reasonable number for next years, not just
2, there is no "beyond 64 bits (TM)" anytime soon, but I do not think
4, 8 or 16 execution pipes are that far away in desktops (dual socket
can be bought for some extra now, so dual core dual socket this year
or next and you have 4).

Of course, coding multithreading is not simple, and it could put
others in a bad place (when they want to add things and make it still
work). So not absurd, but pretty important decission due the
adventages and side effects. :-/

*: depends if the threads relate in such way to fit in HT or only
improve in full SMP solutions.

GSR