Making Revolution faster with really big arrays

[Frank D. Engel, Jr.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A 32-bit address space has a *total* of 4GB of addressable memory.  Of 
that 4GB, the operating system normally reserves 2GB for its own use, 
leaving only 2GB for the process.  The operating system reserves that 
much space because it maps the SAME 2GB of memory for every process 
into that portion of the address space.  So 2GB of the address space is 
consumed by the operating system, and cannot be used by the process.  
Each process gets only 2GB of address space to work with.

Some operating systems allow you to vary this somewhat.  For example, 
some server versions of Windows allow you to change the configuration 
to 3GB per process, 1GB for the operating system.  This is intended for 
apps with large data sets (like the one presented in this thread), and 
is mainly of interest to database servers.  Reducing the address space 
of the operating system limits the number of concurrent tasks that can 
be managed by the system and the amount of potential buffer space 
available for use by disk/file cache, etc., so the 2GB/2GB split is 
fine in most cases, but in cases where you are juggling a great deal of 
data (as in this case), it can make the application program feel just a 
bit crowded.

That's where 64-bit processes come in handy.  For smaller apps, a 
64-bit address space (meaning 64-bit pointers which consume more 
memory, etc.) can actually slow down execution rather than speeding it 
up, but when dealing with huge data sets, the ability to map huge 
amounts of data into the same address space can simplify program 
authoring and improve performance.  Unfortunately, I don't believe Rev 
currently offers a 64-bit engine.

That wouldn't be a bad idea, though -- particularly with the 
improvements showing up in Tiger related to 64-bit processing, the 
availability of 64-bit Sun and SGI workstations (among others), etc...

Anyone want to BZ a request for 64-bit engines, mainly for G5 towers 
and the iMac G5, but then also for SPARC64 (Sun workstations) and 
MIPS64 (SGI workstations) while we are at it?


Again, though, with processor-intensive operations on huge data sets, 
*any* scripting language is a poor choice.  You definitely want 
native-compiled code for that.  Pascal, Ada, a compiled BASIC...


On Apr 12, 2005, at 6:37 PM, Richard Gaskin wrote:

> Frank D. Engel, Jr. wrote:
>> That is only significant if Rev takes advantage of the 64-bit address 
>> space, which I seriously doubt.  Your Rev process will still be 
>> limited to 2GB of addressing space, regardless of how much RAM is in 
>> the system.
>
> Wouldn't that be 4GB, or have I slipped a digit?
>
> --
>  Richard Gaskin
>  Fourth World Media Corporation
>  __________________________________________________
>  Rev tools and more: http://www.fourthworld.com/rev
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
- -----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCXFy77aqtWrR9cZoRAvdpAJ0S0s0YDD8pKa3zE7CtnHfCKVIRKACgiYoz
Sx7tq658YZV6deC0bGDvpzE=
=I2kb
-----END PGP SIGNATURE-----



___________________________________________________________
$0 Web Hosting with up to 200MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com