[haiku] Re: Haiku's SMP
- From: Marcus Overhagen <marcusoverhagen@xxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Tue, 18 Nov 2008 13:29:25 +0100 (CET)
Cyan wrote:
> For comparison, with Chart on R5, I get 155 frames per second with
> the star count at maximum, all the star colours enabled, the
> Enabling two-thread mode brings it up to 169 frames per second;
> a 9% increase. Looking at ProcessController, almost all of the CPU
That means that some work was moved to the other CPU.
Chart is just not meant the way you are using it.
> All I'm really saying is that the time wasted by the CPUs, waiting
> to write to the video card, can be very severe in visual demos.
That time is not wasted. It is spent on writing to video card, which
is limited by memory bandwidth constrains.
> The problem is a lot less noticeable on a PCIe x16 card, but on a
> PCIe x1 card (and to a lesser extent standard PCI), it doesn't
Again, memory bandwith. nothing SMP specific.
> matter how many CPUs are generating data; it's all got to be
> crammed down a tiny shared channel!
You chose a very bad example for SMP testing.
> There's another interesting thing that can be observed in Chart --
> try partially obscuring the window. I don't know what happens in
> Haiku, but in R5, the performance drastically increases the more
> the window is hidden by other windows. This might only apply to
That is to be expected. Drawing less data allows to do so more often.
> BBitmap drawing mode, but it's interesting to see clipping making
> a measurable performance difference.
Thats because memory bandwith is the limiting factor.
> Fair enough, but multi-threaded applications also vary in terms of
> how much data-sharing takes place. For applications that split a
> large data set up into (megabyte-size) blocks, and have each thread
> process its own block, wouldn't you say that's pretty comparable
> to running separate apps?
No. If you can split an image into multiple blocks, and process them
with 4 CPUs, even assuming only 90% efficency on each CPU, the
movie would be rendered at about 370% of the speed that a single CPU
would deliver.
> I can see that there'd be a difference in performance if each thread
> was working with a very small data set, but then I'd be concerned
> about how much time is wasted in locking and communication...
That are only a few percent.
I stopped reading your mail at this point.
regards
Marcus
Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr
Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional
60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star
Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in
der Arcor-Videothek. Infos unter www.arcor.de/tv
Other related posts:
