flat assembler
Message board for the users of flat assembler.

Index > Heap > Intel's TSX thing

Author
Thread Post new topic Reply to topic
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
the only benefit i can see about Intel TSX http://en.wikipedia.org/wiki/Intel_TSX
comes from the read/write consistency on the single cache-line (64 bytes).
the last good instruction on older processors was the CMPXCHG16B, allowing a 16 bytes perfect lock.

i didnt read docs carefully,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
nor i can test the new instros XACQUIRE,XTEST etc (btw, in FASM already ?) i may be missing something, ok.

now, granted improvements after the fact that associativity in the L1 set has been scaled to 8 on Haswell,
you have however to re-invent the wheel to assure coherence on transactions involving more than one line of datas and/or
on accesses on the whole set.

this interesting document about Haswell
http://natsys-lab.blogspot.ru/2013/11/studying-intel-tsx-performance.html
confirms me that on older processor it is exaclty the same but relatively to the L1 size or associativity.
(i told here on board about my own 3C rule, giving out empirical guideline-formulas)

Intel states this (from http://software.intel.com/en-us/blogs/2013/06/23/tsx-fallback-paths ). i quote it again
Quote:
If you already have a good lockless algorithm implemented, in many cases it may be fast
enough by itself, so you don't even need a transactional fast path. But in other cases
the lock less implementation may have high overhead, so transactions may still win.
but that is just the point Exclamation if i had good algo, i scale it simply to the Haswell properties,
avoiding also to reinvent the wheel by using that new technology !
what i exactly dont need is their good "fast-path" library, or a presumed GCC compiling capability.

also, if you can address me with documents explaining/showing the benefits of this
TSX-thing i will be very thankful.

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 08 Dec 2013, 07:07
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17463
Location: In your JS exploiting you and your system
revolution
Acquire and release mechanisms are good in certain situations. And lock mechanisms are also good in certain situations. It is a mistake to think that one method will be better in all situations. One must look at their requirements and decide based upon that which mechanism will be best suited.

Note: These are by no means the only two possible mechanisms available for synchronisation, but they are the most commonly used and most easily understood in most cases.
Post 08 Dec 2013, 07:22
View user's profile Send private message Visit poster's website Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
Interesting. IBM also came out with this after many decades of supporting many other locking and serialization mechanisms. I wonder if it has to do with demand from database or high throughput transaction code. Because as far as I can see (on IBM, where I work) we really don't need this. IBM has a guaranteed consistency model that doesn't require memory barriers. I realize this is different from Intel and various other microprocessors.
Post 17 Dec 2013, 18:55
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.