Re: thoughts on smp

----- Original Message -----
From: Enrico Weigelt <[email protected]>
Date: Sat, 21 Feb 2004 03:06:08 +0100
To: media-api <[email protected]>
Subject: [Media-api] thoughts on smp

> 
> Hi folks,
> 
> 
> does anyone know how SMP exactly works ?

Maybe not exactly but I've got some pretty good ideas and I've written working code using it before.

> 
> If really wanna benefit from SMP, we IMHO need MT, so the kernel
> has multiple tasks it can put on several CPUs. 
> 

IMHO an API's job is to get data to and from other people's code, not perform heavy number crunching. Therefore, the system will be inherantly memory and bus bound, and CPUs will be unable to split any individual stream properly due to memory dependancy. Multithreading is more something that belongs in the codec or the other CPU intensive bits. For the API you might consider doing each data stream as a seperate thread, but beyond that the task of keeping all the CPU caches synced and all the right data coming out of memory at the right times to make SMP work will hurt more than help. If you tried to do what you proposed with groups of frames on seperate cpus, you'd have a hard time. How many frames? Is the number of frames dependant on the codec? etc. You'd have to read the file at multiple points, and the codecs would probably constantly want keyframes both ahead and behind, which would
  mean even more random seeking, etc. It'd probably be slower making the read head on the H
 D jump around the file grabbing seperate frames and keyframes than just letting one single thread with a nice simple read ahead cache handle things.

In general SMP's overhead means it is only a win for high cpu use/low memory code, and an API's code isn't going to fit that profile at all.


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm