Re: Alpha remembrance day

Bill Todd wrote:
Glenn Everhart wrote:

...

Nowadays of course, with J.Q. Public working with ever larger pictures or sound files, the limitations of a 32 bit address space are obvious to a much larger population.

Are these actually good examples? Pictures indeed tend to want to be entirely resident in your process's virtual address space, but it's a pretty rare picture that requires gigabytes to fit in (if you're heavily into Photoshoping some can start to tax the limits, but I'm not sure that such people really qualify as being "John Q. Public"). Video has been too large to fit into a few GB for a long time, and is processed quite adequately piece-meal rather than in one bloated mmap segment (I'm not as familiar with sound-only applications, but I'd expect that long compositions might encounter the same kinds of problems and hence be processed as video is - since in both cases there's no need whatsoever to have the entire work resident at once).

While there have been a lot of legitimate applications for 64-bit hardware since the early '90s at the latest, including some lower-end ones more recently, I'm nut sure that any have been common *desktop* applications (even the vagaries of the NT/2K/XP 32-bit file cache don't really affect typical desktop users much).

- bill
Well, I thought they were good examples, seeing I have hit them myself on various occasions. Consider such projects as trying to scan in numerous photo albums a page at a time, at fairly high res so as not to lose the detail in old photos. Capture and then manipulation of such things takes a lot of memory and pushes the limits of a 32 bit box.

We could edit huge text files since practically forever with TECO or the like, editing a bit at a time. Sometimes there arise cases where it is easier to have the whole shmear in memory at once than to deal with the boundary conditions.

While existing apps perforce don't try to keep several gigs of video in memory at a time, I think from articles I see now and then that the problems of photo editing have occurred to a good many, and suspect there will occur other apps in the video space where designers will be
able to use huge buffers once these become available.

This is a minor point, but the photo editing problem has occurred within my family, and we are not by any stretch power users of photoshop or other such apps. Anyone with parents with old photos they want to convert could easily have such a problem. There were after all millions of cameras in use back in the 50s...

I have also had a few cases where an operation on a sound file wanted to read the whole thing in at a time. I suppose it might have been done otherwise, but the software writer apparently found it easier to scale timing and pitch all at once rather than deal with the boundary conditions. When your box, equipped with what you thought was ample memory (and not too far from the limits of address space), runs out, you may well start thinking about the desirability of larger address spaces.

There will probably be many many times more cases thought of once desktops are mainly 64 bit addressed where such space will be used. It has happened for every significant increase in address space so far that I can recall. In the case of 64 bit space, while perhaps issues of mapping large files to memory were early considerations, the dbms case happened to get tried early and was surprisingly effective. The desktop apps could be written to use smaller memory (or people could drop back and use lower resolution), but some global operations are just painful when emulated off disk. ("Virtual memory is fine as long as you want to do virtual work" - Martin Minow). The photo album page at 9600 dots/inch
can occupy 10**10 pixels even in gray scale. It seems a simple problem to want to capture and edit such things and already fails. Surely there are others besides me who have photos their parents took that might be converted. So I suspect there are a number of folks who have noticed their memory limitations and that the 32 bit limitation is already limiting what they can do.

that was the reason for the side comment.

Glenn Everhart

.

Relevant Pages

  • Re: Large Pages - Linux Foundation HPC
    ... -- Memory and interface to it - mapping memory into apps ... Some of their apps get a 6-7x speedup from large pages! ... Based on Dave's descriptions that HPC apps typically ... true of the kernel in general... ...
    (Linux-Kernel)
  • Re: Tech directions for Delphi?
    ... allocator, ... Most desktop apps build a relatively modest working set (a ... the case for .NET doesn't really rest on automatic memory ... management being cheaper overall than manual memory management. ...
    (borland.public.delphi.non-technical)
  • Re: Id appreciate your opinion(s)
    ... The fact that so much memory is used really doesn't mean you ... When it comes to all of the apps except for ones defined in the ... then I would say that .NET or Java are perfectly fine ... Java and .NET can both do "smart" clients, fat clients, or web-based ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: memory requirements of closed vs quit apps
    ... majority of programs remain open when all their windows are closed. ... they use bugger all memory - and are ... individual apps Real and Virtual memory entries. ... In order to push it out to swap, ...
    (uk.comp.sys.mac)
  • Re: memory requirements of closed vs quit apps
    ... Close those tabs. ... I'd imagine it's the OS just trying to work out which memory needs ... The UI thing is exacerbated by the behaviour of apps to ... IMO 1Gb of RAM should easily ...
    (uk.comp.sys.mac)