New Article: ARM Goes 64-bit

EduardoS (no.delete@this.spam.com) on November 23, 2012 10:09 am wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on November 21, 2012 7:44 am wrote:
> > Install-time compilation would be far better than using a JIT indeed. But you still may not have
> > enough memory/performance for link-time whole program optimization with profile feedback.
>
> On desktops the time consuming compilation is done at background,
> in phones it can be done during recharge time, no?
>
> Oh, and with the most up to date and relevant profile feedback.
>
Background != Free
App has to run slow interpreter/baseline compiler.
Background compilation has a large working set and seriouly competes for LLC.

>
> Every allocator use more memory than strictly necessary (later about C++), GC does
> the job of moving data toghether from time to time wich negates fragmentation.
>
> > Also the much higher memory allocation rate and resulting collections are bad for locality.
>
> Allocations are cheap, collecting short lived objects is cheap too.
>
No, collecting short lived objects is expensive.
Copying is expensive.
To make copying possible is also costy.

> > Concurrent GC has even larger overheads. It stops threads for shorter periods but stops them more often, so
> > takes far longer overall. And then we haven't considered the far higher overheads on the generated code.
>
> I don't know about what GC you are talking...
>
> The concurrent GC I have in mind originated from the non-concurrent GC, the most recent generation
> collections still blocking wich the full GC running in background until it needs blocking, so
> there is the same numbers of full stops but the most time consuming stop is shorter.
>
> Yes, it uses more resources, but on s single-threaded application
> such resources does exist, and wouldn't be used in another way.
>
However it does hurt throughput.

> > No, no space is wasted, unlike GC which requires descriptors for every object.
>
> Descriptors aren't strictly necessary and can be encoded in the vtable pointer, the
> reason many VMs doesn't omit the descriptor is because it is not that expensive.
>
> But C++ allocators waste space, for example, on Windows, before LFH deallocated objects left holes
> in the heap, some wich were left unused for lack of a suitable object, a problem called "fragmentation"
> and it is accumalative, the longer the app runs the worse it gets, see the wasted space? Locality
> isn't good either, objects go were there is space, not near related objects.
>
> LFH allocates 64k for every object size rounded to lowest higher power of 2, wich, by definition waste
> the space between that power of 2 and the actual object size, and, if there is not enough objects of
> a given size to fill the segment, it also waste the segment unused space. Locality suffers as well
> since objects are placed by it's size and related objects may end very far from each other.
>
Allocators waste space.
VM allocators have no magic over C++ allocators, except that you can't customize.

> > Since when is a memory access cheap? Every unnecesary instruction has a cost.
>
> Sure it have a cost, a non-blocking load will consume one decoder, one port
> for one cycle and one slot in a modern processor, wich will likely pass without
> being noticed, so it is a small cost, that's why I called it cheap.
>
Such small cost accumalates and it results in visible penalty.

> > The barriers and other checks for concurrent GC or multithreaded access
> > to fields are not exactly zero-cost and block many optimizations.
>
> Maybe that's why the "volatile" keyword exists?
>
> Anyway, MS doesn't implement the weak memory model that the C# or
> C++ specs allow, many applications wouldn't work if they did.
>
Totally irrelevant.

> > Wrong. Exceptions can only happen explicitly with throw in C++.
>
> Or when the program hits an undefined behaviour...
>
> And there are quite a few undefined behaviours in C++ spec.
>
> BTW, I am not limiting myself to C++ exceptions, any hardware exception is valid, VMs may handle
> exceptions by traping the hardware exceptions, if there is no try...catch block no need to
> care about order or barries, the program will crash anyway... Like it is done in C++.
>
So you elaborated that VM has overhead because it has to take more care than C++.

> > The problem is not just the ordering, but the fact that more operations can cause exceptions. That alone
> > creates a lot of overhead as you need to model flows from
> > every possible exception to all possible exception
> > handlers. Local variable values need to be preserved for example, severely limiting optimizations.
>
> If there is a registered handler...
>
How can you know if there is a registered handler?

> And the implementation can, for example, let the heavy lifting of restoring state for
> the exception handler, giving more freedom for optimizations in the normal flow.
>
> > The performance cost is high if you happen to use arrays a lot.
>
> And if the optimizer fails to remove the redundant checks.
>
C++ needs 0 check.
The optimizer usually has to leave some check uneliminated unhoisted.
And even redundant checks is diffcult to eliminate.