[sldev] Multithreading, Garbage collection, Caching

[Tleiades]

I am still not convinced that multi threading will significantly improve the
performace of the client, I admit it is based on guesswork, but I would
suggest you look into the render pipeline before deciding where to implement
your performance improvements.

I believe it was Dijkstra who first coined the statement about not
optimizing before you have made measurements, in any case, I think you
really need to do some serious performance measurements before deciding if
multithreading is the way to go.

Tleiades

----- Original Message ----- 
From: "Laurent Laborde" <kerdezixe at gmail.com>
To: <sldev at lists.secondlife.com>
Sent: Sunday, March 18, 2007 2:59 PM
Subject: Re: [sldev] Multithreading, Garbage collection, Caching


> On 3/18/07, Tleiades <tleiades at hotmail.com> wrote:
>>
>> Third, - I admit this is speculation - but I doubt that CPU is the true
>> bottleneck for the SL viewer.
>
> As far as i know, the JPEG2000 decoding cost a lot of cpu time in SL.
> What about multithreading this ?
> Secondlife have to be multithreaded anyway. Newer CPU won't run faster
> (we're stuck between 2Ghz-3Ghz since a long time ago now).
> SL need faster cpu : cpu won't be faster
> CPU are now dual, quad, maybe octocore : SL have to be multithreaded
> to run faster.
>
> I'm going to buy a QuadCore + 4GB RAM + 8800GTX 768MB VRAM.
> I'd like to have some kind of "advanced" option saying :
> - Fell Free to use the 3 other core to decode jpeg2000, audio, QT
> coded, cache managment.
> - Load all the cache into RAM
> - Cache the whole sim's textures into the VRAM if you think it may help.
>
> Loading the cache in a ramdisk may sound stupid. What if the client
> crash ? You lose your cache ! Well... usually, when you crash the
> client, your cache is fuxored... so .... why not ?
>
> -- 
> Kerunix
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>