|
To break it down in a more general way, multthreading is about
parallelism. To enable a piece of code to work in parallel on multiple
CPUs, the specific task has to offer a structure where multiple blocks
of operation, which do not depend on each other, have to be executed
individually and afterwards are combined to create a single output. This
obviously applies to rendering, where each ray shot into the scene is
such a task, with the picture created from them being the combinded
output. Deformers, like enveloping, also offer this structure, where the
same task has to be performed on each and every vertex, without the
individual deformation of the vertices depending on each other.
Modelling is pretty much the opposite, it is sequential by nature and
therefore possibilities of parallelism are very limited.
-André
peter boeykens wrote:
as the wiki page points out, task manager is the way to make sure.
with it, you can see the number of cores you have, and by analyzing
their usage you can know what's multithreaded or not.
first of all: its not because you see activity graphs on several CPU's
that there is multithreaded activity going on. A single threaded task
can jump back and forth between several CPU's and will usually do so.
it's all in the percentages:
if you have 2 cpus or cores, a single threaded task can take up to 50%
cpu usage.
with 4 cpu's the percentage would be 25%, 8 cpu's 12,5 % and so on.
If a task goes above theses percentage it can be said to be
multithreaded, and the closer a task approximates 100% the more
effective it is at it.
Keep in mind that complex tasks, such as rendering, or playback of a
3D scene, can have a combination of single and multithreaded tasks.
A very common misunderstanding is assuming that with dual CPU's, the
software will perform twice as fast. (and so on for multiple cores)
That is a dangerous expectation that comes up both with artists and
those paying for hardware, and this usually leads to disappointment.
It is for certain tasks, but not everything. Rendering with mental ray
is thoroughly multithreaded, FXtree (rendering) is too, some animation
tasks are to some extent (I think enveloping for example) but most of
the modelling tasks are not. I'm not so sure about simulation - I
think most of it isnt, but dont take my word for it.
An official detailed overview of this would be very welcome.
So overall you can definitely say that XSI is not a singlethreaded
application, since substantial parts of it are multithreaded - but not
everything inside it is, and the benefit of multiple CPU's and/or
cores very much relates to the kind of tasks you're doing with it.
(sorry if its a newbie answer)
----- Original Message -----
*From:* Marc-Andre Carbonneau
<mailto:marc-andre.carbonneau(at)ubisoft.com>
*To:* XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>
*Sent:* Monday, November 12, 2007 8:25 PM
*Subject:* Is XSI multi-threaded now?
Some animators are asking me if XSI is multi-threaded.
My first answer was yes but I believe not everything is…
I then searched the Wiki and found that same answer but it was
good for 3.5 (information posted in 2004)
So what is the state of XSI’s multi-threading these days? What is
multi-threaded and what’s not?
Can someone from Softimage answer about this?
Thank you!
http://softimage.wiki.avid.com/index.php/How_to_verify_that_your_second_cpu_is_being_used
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
|
