According to Anton Ertl <anton@[EMAIL PROTECTED]
>:
> That depends on the file system. However, I don't know how usual file
> systems deal with non-linearly written files.
File systems with no support for sparse files (e.g. FAT) simply write
zeroes on the "holes" and have no real problem here.
For file systems with support for sparse files, consequences ranges from
relatively benign (data chunks will be spread accross the disk, and you
may have bad interactions with the read-ahead strategies of the kernel
and the logic implemented by the disk itself, which both optimize the
usual linear access pattern) to rather inconvenient (e.g. much more
extra space used to describe the more complex file structure).
Moreover, if your system supports sparse files and has a kernel and a
disk which perform read ahead, then the OS is probably a kind of Windows
or Unix-like system and most plausibly there are parts of the system
which will read the file linearly (if only the backup system) and suffer
from the fragmentation.
> but if you believe that it works well in systems with little memory,
> you are suffering from delusions.
Depending on what you call "little memory", of course. 1 megabyte is
small when compared to what desktop PC have now, and it is certainly
very small if you consider what Sun's JVM usually uses, and yet I have
found the GC to work well within that megabyte. Of course I am not
claiming that on a system with 32 kB of RAM things would be as sleek --
but I do not dismiss the thought a priori. It is worth a try.
> If it used only a few % of execution time in that situation, then the
> application did not allocate much compared to whatever else it spent
> its execution time on.
Some cryptography. It can be pretty heavy on a low-end CPU. Yet there
was some string processing, decoding and encoding of structures, and
some computations with big integers, all of which performing GC-based
allocations.
I am not talking about a programming language allocating function frames
through the GC, because THAT would be very heavy on the GC side and I am
not sure how that would fare (there again, this deserves some
experiments).
> A compacting memory manager (GC or not) can be a good design for this
> situation (it will fail even later, after even more thrashing:-), but
> it's different from a copying collector.
A mere terminology issue. I am talking about a memory manager which may
move objects in memory, transparently from the application code point of
view, and a compacting GC surely does that.
Depending on the situation, some memory management technologies may be
more appropriate than others, not always the same. The idea I am playing
with here is that managers which move objects have opportunities for
optimization which are not to be neglected. But this is applicable only
to situations where pointers are unambigously recognized as such, hence
strong typing, hence not-for-Forth. But this should be applicable to
derivatives such as StrongForth.
> In any case, that's not what you claimed earlier: you claimed that the
> copying GC moves objects around to better fit the access patterns,
> resulting in more cache-friendly behaviour by the program.
Well, I claimed that, and then you claimed that it would not compensate
the overhead of using the GC, which is why I began to state that the
overhead is not big and may be zero, or even less. If the overhead is
zero then whatever chache-related gain is obtained is a net gain.
Besides, the notion of "overhead" is relative: the overhead of the GC is
the amount of extra resources needed by an application in a language
which uses a GC, compared to an application which uses a very similar
language, and the same algorithms, but with a more conventional dynamic
allocator (ALLOCATE / FREE). This is the notion of overhead that I use
in the present discussion. If we use the same words with distinct
definitions, then the debate will be of suboptimal quality.
> Boy, Java takes a factor of 2-3 on array bound checks (after
> optimization), when the typical numbers of the array bound checking
> overhead I have read are 10% (and that's from papers on optimizing
> them, which have every reason to inflate their significance).
It is possible that Sun's JIT compiler does not perform a good job at
optimizing array bounds checks, and I know that my translator does not
either because it does not even try to perform any optimization on those
checks, but I positively confirm that these checks have such an effect.
Which probably indicates that Sun's JIT compiler really does nothing
smarter than my own code.
Consequently, if array bounds checks can be optimized to have an
overhead of only 10% (I have to trust your word on this), then Java code
can mechanically reach within 90% of compiled C code by the simple
expedient of applying those optimization. And I would deem such
performance "not bad".
> BTW, if Sun is the impediment to Java speed, then Java should be fast
> on the non-Sun JVMs. While I have seen some benchmark results that
> indicate that there are faster JVMs than Sun's, the difference is not
> big.
I observed speedups by a factor of almost 2 with IBM's JVM, on the same
code. Of course, it depends on the code, and you can observe such things
only on code which is not otherwise limited by network, disk or memory
bandwidth, a rather unusual occurrence actually.
> If performance is overrated, why would anyone use such machines?
Overrated does not mean unimportant. Let's not radicalize terms;
I prefer informed scientific debates over messy verbal brawls.
Optimizing scalability in cluster environment is more important,
asymptotically speaking, than local optimization (i.e. a JIT
compiler which produce fast code). In quite the same way that
better algorithms win over opcode tuning. That Sun invests more
on that subject of scalability makes sens to me if they want to
get their share of the high-end clustering market.
(That targetting the high-end clustering market is a good idea from an
economic point of view is quite another question -- and I bet that Sun's
shareholders often ask that question.)
> But how is the scaling measured? With benchmarks again.
Macrobenchmarks, hopefully. E.g. expressed as a number of concurrent
clients handled by the system. That kind of benchmark is more
representative of the actual performance of a system than a measure such
as the number of method calls per second.
> BTW, on such big machines a GC that rearranges data for the cache
> would be even more beneficial. Does Sun's JVM use such a GC? I think
> they would have made big PR about it if they did.
As I said, Sun and the concept of PR have a rather uneasy relationship.
--Thomas Pornin
|
