Re: Version after Version

On Sat, 29 Oct 2005 14:36:27 +0200, "Frank de Groot"
<franciad@xxxxxxxxx> wrote:

>"Maarten Wiltink" <maarten@xxxxxxxxxxxxxxxxxx> wrote in message
>news:436360ab$0$11076$e4fe514c@xxxxxxxxxxxxxxxxx
>
>>
>> I tend to do my operations one method call at a time, not MxN bits at a
>> time.

>Are you saing that when you need to, say, add 1000 numbers in an array, thay
>you do this:

>for i := 0 to High(anArray) do
> AddNextNumber(anArray, i);

I doubt that Maarten would do that
- but if they are 4 byte integers there would be a /loss/ using a 64
bit chip
- and 1000 8 byte numbers is a bit silly if they don't need to be
Int64s

>That would be insane.
>I am sure you are not *that* stupid.

>What you say is nonsensical. Every time you do more than on 32-bit operation
>on an array for example, you can make things much faster by loading 64 bits
>at a time from memory (as my dual-cpu, dual-core 275 machine does),
>operating on those 64 bits and write them back in one operation, to 64-bit
>wide memory.

That is only the case if you have everything 64 bit aligned
- which it ain't
- and you'll probably find that it will seldom be, as that is just
gobbling (doubling) memory usage.

>When you can't imagine that applications do operations on data structures in
>memory, when your own applications don't do such a thing, merely do a few
>"method calls" here & there and for the rest waiting for user input, I feel
>for you.

If you had written your own filing systems then you would be well
aware of the value of 'Packed'

>But please don't think that all desktop software is like yours. Most isn't.
>Some of the software I recently bought is ISObuster (or something). It
>extracts ISO images (a kind of decompressing). This benefits greatly from
>64-bits. Other software I bought is
>ASPack, it is an EXE compressor I use. This would benefit greatly from
>64-bits. Other software I bought is Ghost install, to make installs of my
>1.5 GB install package. The compression engine would benefit greatly from 64
>bits.

Don't count on it
- compression and decompression works at the Bit level

>Other software I bought is Absolute Database. I use ZIP compression (LZW) of
>some fields in my 2 GB of databases. This would benefit greatly from
>64-bits.

LZW is the until recently proprietory algorithm of Uinisys

The ZIP format uses Huffman compression

The 'Z' in LZW is, I believe, nothing to do with the Z in ZIP

>Etcetera, etcetera. You truly haven't got the slightest clue what you're
>talking about. EVERYTHING benefits GREATLY from 64 bits.

No it does not
- some things benefit, huge memory addressing and copying large chunks
of memory
- but most things don't benefit

>I want to go as far as prediction that a software company has no future if
>they do not start the transition to 64 bits NOW.

Well I know a very successful software company that had not migrated
from 16 bit to 32 bit 18 months ago, when they floated a minority
chunk of their equity to make a number of employees GBP millionaires.
( I was at the launch party - a right good shindig, nice seeing old
friends even though I had left 11 years before )

Of course the 'real' shareholders were already well in the Sunday
Times UK 'Rich List' - but I'll not go into details in public.

Incidentally they specialize in fast data interrogation and
presentation - using their own proprietory filing systems that are
designed to minimize disk reads and memory movement.

Personally I would have re-written the systems in 32 bit a long time
ago, but not to obtain speed since any disk based system is choked by
the File Transfer rate
- simply because I would have liked to get them back out of 'C' and
into a sensible development language.

Think about processor bus width like the frequency range on an audio
system
- at a certain stage the higher the frequency range the bigger the
yawn.

Huge addressing ranges might be Ok for servers, but that was around
for a long time on the VAX, and guess what, they had to back it up
with SRAM - it was just one big read cache.
- and the huge address range was generally down to it being needed by
incompetent programmers who did not know how to organize their data.




.

Relevant Pages

  • Re: Version after Version
    ... at a time from memory, ... Some of the software I recently bought is ISObuster. ... GB install package. ... The compression engine would benefit greatly from 64 ...
    (alt.comp.lang.borland-delphi)
  • Re: Quick Huffman theory question
    ... application compresses and decompresses, compression appears to ... categories as context. ... good text compression requires gigabytes of memory. ... don't bother with Huffman codes. ...
    (comp.compression)
  • Re: 18" Mitutoyo micrometer batteries
    ... I bought at a business store a 12 digit nixie 4 banger with memory for $600. ... NRA LOH & Patron Member, Golden Eagle, Patriot's Medal. ...
    (rec.crafts.metalworking)
  • Re: view menu
    ... When the file is opened into any graphical viewer or editor, the data is transferred from disk to memory so that the program can work with the data. ... We know that png uses data compression, so we can expect the uncompressed size to be much more. ... The image is 1080 pixels wide and 902 pixels high for a total of 1080x902 = 974160 pixels. ...
    (comp.graphics.apps.gimp)
  • Re: Suspend 2 merge
    ... >> spend most of your time eating memory so that you only have a few megs ... >> compression I think it achieved something close to double that, ... >> suspend faster, more reliable, more user friendly, more versatile or the ... > They are neccessary because of two-stages LRU saving... ...
    (Linux-Kernel)
Quantcast