coming pc tech

[neil]

hey ho all,
I have been looking ahead at descriptions of the coming dual core processors
and I have a few questions that maybe someone can help me with...

1) I presume SW performance will not benefit from dual cores at all? but I
will be able to run 2 engineering applications simultaneously provided I
have say 4gb ram- practically limited to 1.5gb each?

2) Is 4 ghz now a general reliability limit? ...so now we have multiple
cores (2-4-8?)rather than scalability? ...so although power requirements
will go down with each nm shrink speeds wont change much for linear appl
like SW?

that is...SW will really not be running any faster in the future than it is
now on an Intel box and when AMD get to ghz say 2 years after the dual core
launch of 2.ghz that's it too??

do I have this right...
neil

[Dale Dunn]

From what I understand, the dual core processors will be at lower clock
speed than similar single core chips. So, unless you can really use the
parallelism, stick with the single core. It seems that the best use for
multi-core chips will be servers and other apps with tons of threads, or
cheaper alternatives to multi-CPU hardware.

I don't know of anything significantly multi-threaded in SW except
Photoworks. There seems to me to be room for multi-threading in SW. Iguess
the economics aren't there yet. I expect AMD and Intel (especially) to push
multi-cores into desktop systems, which should eventually make multi-
threading more likely for SW, since more systems will have it. That'll take
years, I'm afraid.

Clock speeds and perfomance should continue to increase, but at a slower
rate. The P4 architecture is maxed out, but there are other things coming
soon for Intel. Until then, AMD doesn't need to hurry up about releasing
faster processors. It looks like 05 will thus be a slow year for processor
performance increases (except multi-threaded stuff). We'll have to rely on
updating old hardware and SW speed improvements. There are still some
process shrinks coming in the next few years too, 65 and 45 nm.

So, I expect 05 to have slower growth in performance than previous years,
but there is more to come. Maybe a lot of waiting for software to take
advantage of all the new multi-core systems in the mean time.

[neil]

hmmm, ok...well I was thinking I could take advantage of a dual core to run
a SW session and also have Blender doing an animation render at the same
time but if its going to be clocked slower well maybe not.
I would expect that type of exercise could soak up 2gb ram and 2gb page file
fairly readily...it isn't clear to me how page file access would be
compromised with 2 large hungry applications...I guess you would need
another disk just for the page file...can a pf be split up??don't
know...maybe multi core is more suited to domestic purposes.

It would seem unlikely that SW will be in any hurry to pick up multi core
given that they haven't really got into multi threads...64 bit doesn't seem
to be coming either...plus I think Intel sort of made a right angle turn on
multi core so I don't know that anything would have been in the SW pipeline
concerning that.

Maybe I will just wait a bit and see how it all pans out, but it does seem
from what I read that workstn performance really isn't going ahead like I
imagined...

cheers
neil

[Cliff]

Think things like graphics & analysis.
Clearly there will be new compilers to recompile
things with.

In addition, expect better with probably more buffers
& memory on the CPU and shorter signal paths & perhaps
wider busses.

Should be info on Intel's Site ... I did not look.
--
Cliff

[P.]

Dual core doens't even have much effect on running multiple
applications. I run long FEA analysis while running SW. Except for the
memory limitations I don't even know the FEA analysis is running when I
set its priority to low in Task Manager. And given that applications
that require user input get priority when they are being used there is
little incentive for running multiple apps on a dually unless you like
going into Task Manager all the time and setting affinity for each app.
Unlike *nixes, Windoze has never had an elegant way to set task
priority on the fly. The rule is still get the fastest CPU possible.

As Dale mentioned, PhotoWorks utilizes multiple CPUs, but it is not
because of multiple threads. It is because the solution to the ray
tracing algorithm can be spread among many processors and the people
who wrote the software took advantage of that. You may have heard the
term rendering farm even before PW came along. A rendering farm is a
room full of fast processors all working on one frame of a rendering.

[Cliff]

On 5 Jan 2005 03:15:33 -0800, "P." <kellnerp@cbd.net> wrote:

As Dale mentioned, PhotoWorks utilizes multiple CPUs, but it is not
because of multiple threads. It is because the solution to the ray
tracing algorithm can be spread among many processors and the people
who wrote the software took advantage of that.

This is probably the case with any 3D graphics application,
such as SW.
I'd think that the "solving" of BREP solids would also apply
as many edges & faces could also be so computed by the
kernel.

Anyone know more or better? Nobody actually from SW
development/support lurking?
--
Cliff

[neil]

well this has me confused....why are chip manufacturers going to multi core
then?
software that can't use it ...applications that aren't suited to it...hassle
of managing it??
from what I have seen of the roadmaps single processors are being phased
out...and the GHz is staying static...and it seems unfortunately SW isn't
going to get any faster any time soon no matter what hardware you buy...

thinking about it though...surely the bios is going to auto assign new tasks
to a different core...and each core will have a page file of its
own?...presently if I have a render running it consumes 100% of processor
time and trying to get access to some of that time to do something else as
well is a long unresponsive wait....isn't this what multi core is all
about?..it's not feeding the stack...its not distributing calcs...its multi
tasking isn't it??

yes I am aware of render farms...Blender uses multi threading and shortly
will use multi processors for both it's scanline and GI render
engines....and someone is working on internet distributed rendering as well
as networked renders (farm)...however I was interested in utilising spare
time on my single pc and being able do 2 activities at once....dual core had
seemed like a good way to do that...

neil

[P.]

Certain portions of the solution to a SW model do use multiple
processors. But it is not enough to make an appreciable difference in
speed. I think if they went to an associative scheme and away from
parametrics they could use multi processing to better effect.

They could also go to redesigning the feature tree and solve the
branches separately.

[Dale Dunn]

It's all about marketing. Intel continued to sell the P4, even when it
wasn't the best. Hyperthreading was part of that. The idea of being able to
do 2 things at once sells. Consumers (where the money is) are not
necessarily well-informed decision makers. In fact, I think the P4 just
feels faster because of Hyperthreading, even if it doesn't benchmark
faster. I suspect that dual cores will be just the extension of that, when
it gets to the mainstream desktop. And look how many people have dual Xeon
workstations to use SW all by itself. The Xeon isn't even the best platform
for SW, and these people have two of them!

I saw a video of a presentation given by a former chief CPU architect at
Intel, the one who was in charge of the P$ development. I can't remember
his name just now. He spent a lot of time talking about the lessons Intel
had learned about markting, and blue crystals. The blue crystals they used
to advertise in laundry detergent did nothing but sell laundry detergent.
This is why the P4 was designed to achieve high clock speed at all costs.
That's what sold. That, and claiming that the P4 could improve the web
experience, whatever that means.



The OS assigns the threads to the cores. Each core will share physical
memory and page file space, since this is all managed by the OS.

[neil]

so what it all amounts to is that multi core is a dud...and SW speed has
topped out..
...oh well back to the drawing board..
thanks for your replies
neil

[Art Woodbury]

In article <1104952897.937317.82930@z14g2000cwz.googlegroups. com>, kellnerp@cbd.net says...

Certain portions of the solution to a SW model do use multiple
processors. But it is not enough to make an appreciable difference in
speed. I think if they went to an associative scheme and away from
parametrics they could use multi processing to better effect.

They could also go to redesigning the feature tree and solve the
branches separately.


In 8 years of using I-DEAS, my favorite feature was the "bushy" history tree, where branches

could be suppressed. Each branch was essentially a separate part attached by a Boolean join
with constraints. When a branch was completed, it could be suppressed until needed for the
final rebuild.

Could it be that multiple bodies in SW would offer similar results (i.e. suppress the ones
you don't need at the moment)? I'll have to play with this.

[Dale Dunn]

Could it be that multiple bodies in SW would offer similar results
(i.e. suppress the ones you don't need at the moment)? I'll have to
play with this.

I agree that this is an area where it seems that SMP could be used. While
most parts don't have multiple bodies, the real history tree definitely has
multiple branches. Depending on how the part is designed, it might solve
faster on multiple processors. Learning to do "horizontal" modeling would
become even more important to performance.

Now then, I have no idea if the nuts and bolts of implementing such a thing
are practical.

[P.]

You can use folders in SW to accomplish this without multibodies.
Starting from the base feature create a branch, put the branch in a
folder and suppress the folder or roll back to before the folder. Then
work on another branch and do the same. One problem you run into is
that some features don't do history very well. Typical would be
surfaces and Move/Copy features. Anyway, when done the last folder is
the first branch, the second last is the second and so on. Using this
method does speed up modeling becuase everything but what you are
currently working on is suppressed. But there ain't no free lunch here
when it comes to the endgame when everything is unsuppressed.