Thomas Pornin <pornin@[EMAIL PROTECTED]
> writes:
>Filling a file from a virtual memory view also often leads to high
>filesystem fragmentation, unless you preallocate the complete file,
>which is almost invariably a waste of space on a non-dedicated system.
Writing a file with mmap() is more complex than reading a file with
mmap(); IIRC you have to specify the file length in advance with
truncate() or ftruncate(), so in some sense you do pre-allocate the
complete file (although on many OSs (f)truncate() alone creates a
sparse file, which does not need much space).
Also, reading a file with mmap() can save a lot of overhead compared
to read() (one copying of the data) or, worse, fread() (two copyings
of the data). But the mmap() advantage is not so pronounced when
writing, because in that case the OS typically writes to disk anyway,
and the copying is cheap compared to that.
>When the programmer uses a
>strongly-typed programming language, it becomes possible for the
>operating system (or virtual machine implementation) to actually _move_
>objects in RAM dynamically to better fit the access patterns. This is a
>feature of modern Garbage Collectors and is applicable only if the GC
>precisely knows which data element is a pointer and which is not
That's a nice dream, but in the real world I have yet to see a case
where that effect outweighs the overhead of copying garbage
collection.
>If simply using mmap() is 2006-programming, then improved cache
>coherency through an object-moving GC must be from year 2015, at least.
>Strangely enough, Sun Microsystems has sold the idea at industrial
>levels for the last decade (under the name "Java").
Yes, and it's not known as a champion of high performance.
Another Java myth I have read is that the JIT results in faster code
than possible with static compilation, because:
1) It knows exactly which CPU it is compiling for, whereas a static
compiler typically generates code that runs on all CPUs and does not
run too badly on any of them (and maybe even optimized for a different
one than you have).
2) It knows how the program is used at run-time and can optimize for
that usage, and adapt to changing usage patterns.
Yet, these advantages do not seem to outweigh the overheads of JIT
ompilation. AFAIK Andrew Haley is still working on static Java
compilation.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
|
