On 7 Mar 2009, at 08:30, Riccardo Mottola wrote:
- I do not want any additional runtime overhead. Performance needs
to be
maximum. Always.
Don't use Objective-C then. The language compromises performance for
flexibility all of the time. How much in GNUstep is CPU-bound? Most
of the bottlenecks I see are network and I/O-related.
No overhead is not possible. All of the proposed solutions add
overhead:
If you add extra, unused, space in objects, you bloat memory usage and
(much worse) data cache usage and trigger more cache misses and more
paging on memory-constrained systems.
If you make private ivars into a structure and make a pointer to this
an ivar, you add an extra malloc for every +alloc (expensive) and you
add an extra load for ever ivar access.
Non-fragile ivars work by storing the offset in a global and setting
it at runtime. This adds one word per ivar of memory usage (per
class, not per instance), which is negligible. It also adds a load
for every ivar access. This load is in the same location for every
instance, so is likely to be in cache already for frequently-used
classes / ivars. On x86 and ARM there are addressing modes that make
this a very quick operation.
- I do not want to relay on some magic compiler and runtime
trickery. I
want to be easily compatible with the widest range from compilers, not
only gcc 2.95, but also for example apple's compilers and who knows
what else
Leopard shipped with two runtime, the `legacy' (NeXT) runtime and the
`modern' (64-bit) one. The modern runtime supports non-fragile ivars,
as do both of the compilers that Apple currently ships. Support for
the modern runtime went into clang a few months back, so there are now
four compilers (gcc, llvm-gcc, clang) capable of supporting non-
fragile ivars on OS X.
As for other compilers, GNUstep never supported POC and probably will
never do so. GCC 2.95 is an abomination that needs to die. It is so
far away from being standards-compliant in any modern sense that it's
not even funny. If there are any platforms that actually work with
GNUstep and have such an archaic compiler, then I would suggest that
the best long-term strategy for supporting them is to use clang with
LLVM's C back-end, and compile the result with the platform's C
compiler.
Keeping support for old platforms should not come at the expense of
making GNUstep a first-rate platform for developing today.
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev