On heap segregation, GC optimization and @nogc relaxing

via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 12 04:37:56 PST 2014


On Wednesday, 12 November 2014 at 11:51:11 UTC, ponce wrote:
>> Haswell does not have buffered transactions so you wait for 
>> the commit, but there are presentations out where Intel has 
>> put buffered transactions at around 2017… (but I would expect 
>> a delay).
>
> I wasn't arguing of the current performance (which is not 
> impressive).
> My point is that transactional memory has limited 
> applicability, since locks already fits the bill well.

Yes, Intel style HTM is only an optimization for high contention 
where you already have locking code in place, since you need to 
take a lock as a fallback anyway. But useful for database-like 
situations where you might have 7 readers traversing and 1 writer 
updating a leaf node.

It is of course difficult to say how it will perform in 2./3. 
generation implementations or if the overall hardware 
architecture will change radically (as we see in Phi and 
Parallella).

I can easily imagine that the on-die architecture will change 
radically, within a decade, with the current x86 architecture 
remaining at a coordination level. This is the direction Phi 
seems to be going.

In that case, maybe the performance of the x86 will be less 
critical (if it spends most time waiting and buffering is done in 
hardware).

> And I'd argue the same with most lockfree structures actually.

I think in general that you need to create application specific 
data-structures to get performance and convenience. (I seldom 
reuse lists and graph-like data structures for this reason, it is 
just easier to create them from scratch.)

I also agree that you usually can get away with regular locks and 
very simple lockfree structures where performance matters (such 
as a lockfree stack where only one thread removes nodes).

Where performance truly matters you probably need to split up the 
dataset based on the actual computations and run over the data in 
a batch-like SIMD way anyway. (E.g. physics simulation).


More information about the Digitalmars-d mailing list