new principle of division between structures and classes

[Weed]

Andrei Alexandrescu пишет:
> Brad Roberts wrote:
>> Andrei Alexandrescu wrote:
>>> Weed wrote:
>>>> Weed пишет:
>>>>
>>>>>>> 4. Java and C# also uses objects by reference? But both these of
>>>>>>> language are interpreted. I assume that the interpreter generally
>>>>>>> with
>>>>>>> identical speed allocates memory in a heap and in a stack, therefore
>>>>>>> authors of these languages and used reference model.
>>>>>>>
>>>>>> Neither of these languages are interpreted, they both are compiled
>>>>>> into
>>>>>> native code at runtime.
>>>>> Oh!:) but I suspect such classes scheme somehow correspond with
>>>>> JIT-compilation.
>>>>>
>>>> I guess allocation in Java occurs fast because of usage of the its own
>>>> memory manager.
>>>>     I do not know how it is fair, but:
>>>> http://www.ibm.com/developerworks/java/library/j-jtp09275.html
>>>>
>>>> "Pop quiz: Which language boasts faster raw allocation performance, the
>>>> Java language, or C/C++? The answer may surprise you -- allocation in
>>>> modern JVMs is far faster than the best performing malloc
>>>> implementations. The common code path for new Object() in HotSpot 1.4.2
>>>> and later is approximately 10 machine instructions (data provided by
>>>> Sun; see Resources), whereas the best performing malloc implementations
>>>> in C require on average between 60 and 100 instructions per call
>>>> (Detlefs, et. al.; see Resources)."
>>> Meh, that should be taken with a grain of salt. An allocator that only
>>> bumps a pointer will simply eat more memory and be less cache-friendly.
>>> Many applications aren't that thrilled with the costs of such a model.
>>>
>>> Andrei
>>
>> Take it as nicely seasoned.  The current jvm gc and memory subsystem is
>> _extremely_ clever.  However, it completely relies on the ability to
>> move objects during garbage collection.  If it was purely the allocator
>> that behaved that way, you'd be right.  But it's interaction with the gc
>> is where the system comes together to form a useful whole.
> 
> I understand. My point is that a 10-cycles-per-allocation allocator

10 *cycles* per allocation?

> will
> necessarily use more memory than one that attempts to reuse memory.
> There's no way around that. I mean we know what those cycles do :o).
> Some application don't work well with that. Escape analysis does reduce
> the number of cache-unfriendly patterns, but, as of today, not to the
> point the issue can be safely ignored.
> 
> There's no contention that GC has made great progress lately, and that's
> a great thing.

In any case, we cannot add such memory manager in D. And such resource
allocation does not approach us, and mandatory creation of objects in a
heap does not approach for D.