Re: Alpha remembrance day
- From: Bill Todd <billtodd@xxxxxxxxxxxxx>
- Date: Sun, 03 Sep 2006 23:19:40 -0400
Glenn Everhart wrote:
Bill Todd wrote:Glenn Everhart wrote: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.
...
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
Old photos stored in albums tend already to have lost enough detail that scanning them at more than 1200 dpi is of decidedly questionable utility. Old negatives, if carefully stored, may be considerably better - but then you're dealing with something decidedly different from full album pages.
Capture and then manipulation of such
things takes a lot of memory and pushes the limits of a 32 bit box.
Capturing them needn't take much memory: it's just a bit stream, after all. And I suspect that detailed manipulation is more typically performed at the individual photo level than at the page level.
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.
Not from the user's point of view: it's the programmer's job to make sure that it's all the same to him or her. Unix weenies who jumped on mmap early in the 32-bit transition as a way to avoid dealing with file access properly got bitten as file sizes quickly exceeded virtual memory limits - and, as you well know, using virtual memory mechanisms rather than explicit reads and writes is often a hell of a lot less efficient (both in performance and in use of available RAM) in accessing files as well.
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,
For professionals and semi-professionals, but not for "John Q. Public", which was my point.
and suspect
there will occur other apps in the video space where designers will be
able to use huge buffers once these become available.
Huge buffers have been available for the past decade in 32-bit environments: you're talking about the Unix disease of thinking that the programmer ought to be able to ignore file access entirely and just map *everything*.
That's called single-level storage, and IBM has spent decades making it work reasonably well in its i-series platforms. But it's worth noting that they've never attempted to expand its use to their other offerings: it's definitely not for everyone (and arguably not even for i-series, but with a significant piece of their existing customer base so heavily invested in it it's hard to back away from now).
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...
And my family and my wife's had some of them. But we've never come *close* to encountering the kind of problem that you describe (nor have her parents, retired professional photographers who've retained their interest and do some computer-assisted work of their own) - then again, we don't scan full album pages at 9600 dpi just because the hardware makes it possible to do so...
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.
You know better than that, Glenn: again, it's a *bit stream*, and such manipulations occur in a small sliding window over it that offers minimal 'boundary' challenges to deal with.
Not that there are all that many sound files that are gigabytes in size, unless you're talking 24-track studio-quality (which, once again, is hardly the province of "John Q. Public").
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.
I rather doubt it: I'm just an average user in that regard.
There will probably be many many times more cases thought of once desktops are mainly 64 bit addressed where such space will be used.
More likely misused: there really are *very* few (I'm inclined to say "no", unless you've got a better example to offer than you've come up with so far) common desktop activities that require (or even legitimately desire) more than a 32-bit virtual address space (or 4 GB of physical RAM, for that matter - though of course x86 has supported up to 64 GB of RAM since 1996 for applications that may actually benefit from it).
It
has happened for every significant increase in address space so far that I can recall.
That's because the other examples that you can likely recall (8 -> 16 bits in the consumer/hobbyist space at the start of the '80s and 16 --> 32 bits in the late '70s for minicomputers and in 1995 for the consumer space, when Microsoft finally opened up 32-bit computing to the masses) happened after the previous generation had already become grossly inadequate for many common uses. This transition is not at all the same: 32-bit desktops will be entirely adequate for common use for quite a few years yet (Microsoft didn't even find it worthwhile to wheel out 64-bit consumer Windows for years after AMD gave it a platform to run it on, and now likely views it more as a marketing tool to get people to upgrade than as anything users are actually clamoring for).
- bill
.
- Follow-Ups:
- Re: Alpha remembrance day
- From: prep
- Re: Alpha remembrance day
- From: Villy Madsen
- Re: Alpha remembrance day
- References:
- Re: Alpha remembrance day
- From: Glenn Everhart
- Re: Alpha remembrance day
- From: Bill Todd
- Re: Alpha remembrance day
- From: Glenn Everhart
- Re: Alpha remembrance day
- Prev by Date: Interesting SPAM I received
- Next by Date: Re: Alpha remembrance day
- Previous by thread: Re: Alpha remembrance day
- Next by thread: Re: Alpha remembrance day
- Index(es):
Relevant Pages
|