[sldev] Cache speed experiment & results...
Barney Boomslang
bboomslang at googlemail.com
Fri Jun 6 05:45:25 PDT 2008
Hey,
yep, I run that option enabled for as long as I know about it's
existance - and yep, it does help definitely. I have a dual-core
machine, so it actually enhances FPS since part of the code is
offloaded to the other core. And I never had any problems that were
linked to that option - or to put differently, everytime I had
problems I thought might be related to it, they didn't improve by
switching it off and usually where solved by one of Nicholaz' patches
;)
bye, Barney
On 6/4/08, Nexeus Fatale <nexeus at nexeusfatale.com> wrote:
> I wonder if anyone has tested the run multiple threads and have found
> any improvements
>
>
> - Nexeus
>
>
> On Tue, Jun 3, 2008 at 9:11 PM, Matthew Underwood <sakkaku at gmail.com> wrote:
> > On Tue, Jun 3, 2008 at 8:45 PM, Dahlia Trimble <dahliatrimble at gmail.com> wrote:
> >> If the goal were to improve seek time in a cache, how about keeping the
> >> cache on one of those readyboost-capable usb flash drives? They can have
> >> seek times as low as 1 ms or better, although the transfer rate and write
> >> times arent all that fast.
> >>
> >> Then again it's probably moot if the bottleneck is the decoding :/
> >>
> >> On Tue, Jun 3, 2008 at 5:12 PM, Felix Duesenburg <kfa at gmx.net> wrote:
> >>>
> >>> Dale Mahalko wrote:
> >>>>
> >>>> ...
> >>>> Windows isn't good at dealing with directories containing tens of
> >>>> thousands of files. Ever tried opening a folder containing 20,000
> >>>> files? There is a delay of several seconds trying to do this in
> >>>> Windows. Also the hidden MFT and directory structures can become
> >>>> ridiculously fragmented, also leading to slowdowns.
> >>>>
> >>>
> >>> Reiser4 is excellent with exactly these requirements. It's not mature
> >>> enough to be considered reliable for critical systems, but for a cache? It
> >>> doesn't help that Reiser himself is removed from the development process,
> >>> but it's still there and the source available. Shouldn't that be possible to
> >>> be included as a virtual filesystem even under Windows?
> >>>
> >>> I also always thought it must be a good way to boost performance if the
> >>> cache lived on its own partition, like a Linux swap partition. For the Linux
> >>> version of SL this would even sound like the most natural way to do it.
> >>> Setting such a thing up on an existing Windows machine has a slight fear
> >>> factor attached and is not for everyone, but if a savvy user can handle it,
> >>> why not offer. I'm speculating, but the difference could be dramatic,
> >>> especially if we had a better file system than NTFS on that partition.
> >>>
> >>> >
> >>> > A proper local database engine would likely deal with these huge
> >>> > numbers of tiny files more efficiently than the local operating
> >>> > system.
> >>>
> >>> Yes, but the usual architecture with the database running as a localhost
> >>> server is not ideal for our situation since everything is squeezed back and
> >>> forth through the network system, plus SQL parsing, unnecessarily. With
> >>> MySQL you could build directly on top of the storage engine though, even
> >>> bypassing the parsing with direct API calls. It would just serve as a
> >>> virtual file system the same way as suggested above. I still believe that
> >>> Reiser4 would be even faster. And according to the description on its (now
> >>> defunct) website, they claimed reaching 94% package density with small
> >>> files.
> >>>
> >>> Felix
> >
> > SQLite in a single user environment is incredibly fast so long as you
> > don't let the database grow too large. Of course you have to figure
> > out how efficiently textures can be stored and retrieved in SQL
> > compared to the current caching system.
> >
> > On a side note: Does anyone know where it defines the polygon meshes
> > for rendering cubes. I really want to try forcing untwisted, un-holed
> > cubes down to 1-2 polygons per side and see if that will help out with
> > the frame rate. I tried looking through the source but it is lacking
> > in [helpful] comments.
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > /index.html
> >
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
More information about the SLDev
mailing list