Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: STOP Trading Memory for Speed

by Abigail-II (Bishop)
on Oct 02, 2002 at 11:07 UTC ( [id://202231]=note: print w/replies, xml ) Need Help??


in reply to STOP Trading Memory for Speed

Well, I read the article (I wasn't at YAPC::Munich), and there it's just a side note. Nothing as dramatical as you sketch it here.

Our machines are 32bit and because of cost there will be no big iron (64bit) used for our development.
Since when is 64 bits "big iron"? With "big iron", people usually mean mainframes. But for instance Sun hardware has been 64 bits for years - even their cheapest desktop (which used to be less than $1000 - I don't know if that's still the price). "All the world is Intel" is no more true than "all the world is a VAX" used to be.

I'm willing to bet that 64bit hardware will be common way before RAM is so much faster than memory that trading "memory for speed" isn't worthwhile anymore.

One should also realize that the trade "memory for speed" also means you gain a lot of flexibility. If we hadn't the overhead we have for values, we couldn't easily implement functions like "push", ".=", or length in (average) constant time - it would suddenly be linear in the size of the data. It also mean symbolic references wouldn't work the same way they do now. You'd end up with something that wouldn't be Perl anymore.

Abigail

Replies are listed 'Best First'.
Re: Re: STOP Trading Memory for Speed
by Anonymous Monk on Oct 03, 2002 at 03:30 UTC
    When do you bet that 64-bit hardware will be common?

    16-bit hardware and paging extensions lasted from the Commodore to the 386 Intel's PAE hack and lack of a visible 64-bit consumer strategy (Itanium is not a consumer strategy) suggest that they will try to put off the 64-bit migration in the same way. Given the performance and space hits you get with 64-bits, it might win.

    As for memory for speed, if the amount of pre-buffering assigned to arrays, hash fill for a split of hashes, and similar parameters were tunable at runtime, then less could be made to work. Perl would still trade memory for performance, but how much could be adjusted significantly.

Re: Re: STOP Trading Memory for Speed
by PetaMem (Priest) on Oct 03, 2002 at 08:00 UTC
    Oh - come on Abigail,

    64bits from Sun @ $1000. You're joking. Not even the recent 32bit linux systems from Sun cost less than 1500,- US$ with 256MB RAM. They're PC's with the Sun label.

    And I say "big iron", because the memory overhead in perl is much worse for 64bit architectures than it is for 32bit, so to get everything to memory you get on a 32bit/4GB config, you need an up to 64bit/12GB configuration. YES factor of 3. So to double your capacity with the help of 64bit, you need to buy BIG iron with at least 24GB. Try it. And try to get this for something less than 50.000US$

    But I'm happy, that most of the replies (and current considerations for 5.10) give more focus to this problem. So the most realistic scenario for us will be, that solutions for this problem will come from 3 directions:

    • We are designing the architecture of the application partitionable, so it can be distributed over n nodes of a cluster.
    • Some work on the perl side will surely be done to lower Perls memory overhead (thanks for the use less pragma pointer).
    • maybe in 3-5 years we'll really have 64bit with xx GB for a few bucks and will build clusters with these.
    If all that is going to work out that way, I'll be a happy man. :-)

    Bye
     PetaMem

        You are really good at joking. This "thing" offers MAX 2GB RAM (what were we talking about?), has 128MB and a 500MHz CPU and a 20GB HD.

        So I looked at the relevant configs:

        cheapest Sun Blade 2000. It can have up to 8GB of RAM: $10.995,00 But 8GB are not available, as there are only 512MB sticks and 8 slots. Given very optimistic prices, one would have to pay around $17.000,00 to get 8GB

        (we paid $7000,- for our 3GB dual-P3 with 100GB RAID)

        Ok. Let's look a little bit further:

        The smallest reasonable config would be a Sun Fire V480 Entry-Level Server. With 16GB RAM it costs: $46.995,-

        Big Iron for us...

        Bye
         PetaMem

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://202231]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (8)
As of 2024-04-18 08:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found