This is possible under i386_Linux, but my code has to work on other
platforms too, where I don't just byte-swap, but also resize (i.e. if
sizeof (float) == 8). It could make things very messy.
> Also, if you _know_ that you'll then use the data in some specific sequence,
> you can try to minimize this swapping stage by doing the byte swap in
> reverse: that way when you have byte-swapped all the data you're likely to
> have the start of the data buffer in memory (because that's the part you
> touched the latest). NOTE: this only makes sense if you know that the swap
> is a problem, because generally it's slower going backwards than forward if
> there are no swap effects.
It's possible to do this (a fair bit of stuffing around, though),
but this scheme might reduce performance with other operating systems
where the MM is different.
> You can do the same thing with read (read in small chunks and do the data
> massage in small chunks), but it's generally easier with mmap. And it's a lot
> more likely that you'll see a mmap cache hint in the future than a buffer
> cache hint..
In fact, I already do it in chunks (4 MBytes at the moment): read a
bit, massage a bit, and then to the next chunk. This improved things
considerably, but there is still room to go.
Well, since my code "knows" that Linux supports mmap(), I could cope
with a mmap only hint, since my "reads" are really bcopy() from mmaped
region when the file is mmaped.
I do wonder: how much harder is it to have such a hint for the buffer
cache?
What is the hope of getting a mmap hint in the near future?
Regards,
Richard....