[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ABI Compatibility (was Re: Installation woes for the average user...

From: David Chisnall
Subject: Re: ABI Compatibility (was Re: Installation woes for the average user...)
Date: Sat, 7 Mar 2009 12:21:04 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]