> Uni Durham? How recently?
Mid 1993. Yeah, it was a while ago. It's the only one I haven't kept
current with.
> IDL's absurd resource usage kind of makes it too much of a strain on
> servers (3 users on our 333MHz alpha with 512Meg of memory makes it
> painbfully slow) and more suited to individual machines.
Do they still have that stupid busy-waiting stuff? The machines loaded
even when you don't actually compute.
> Anyway... I don't see how you require such huge swapspace - I
> regualraly work with 2 gig files on my desktop PC with only 64Meg of
> memory (and 190 Meg swap spread ofver 2 disks). I just never try to
> mmap teh whole file at once.....
When you're doing visualisation you really want to have the entire
dataset in VM at one time. For several applications access is
esentially random.
> Personally I don't see the preformance difference I just see that
> it's easier for the application programmer who's dealing with one
> type of data.
The issue is keeping it all in VM at once. mmap() does this
beautifully without the need for lots of swap space. I've gone down
the storage manager path, but that's really awkward and slows things
down for everything. You end up implementing the MMU in software. And
even worse, you're copying data around all the time.
> OTOH my data is generated and stored in my own format...
I have my own too, but despite it's obvious superiority, people prefer
to use FITS ;-)
> Basically whatever way people go they make it marginally more
> difficult for certain types of application programmers. Someone
> always loses out.
If there was a MAP_BE flag for mmap(), then I wouldn't care. Or a
MAP_USER flag (where I'd read in the data myself and byte swap, but on
swap the page is discarded).
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/