Wieviel bringt Transactional Synchronization Extensions TSE?

[TSX nicht bei K Modellen]

Bringt das bei heutiger Multithreaded Software überhaupt schon etwas?

http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions

Unterstützen das schon die Compiler? GCC, LLVM vielleicht?

Und wieso bietet Intel dieses Feature bei den K Modellen, also die, die man übertakten kann, nicht an?

[knivil]

Bringt das bei heutiger Multithreaded Software überhaupt schon etwas?

Sicher nicht, weil im kompilierten Code keine dieser Instruktionen enthalten ist.

[TSX nicht bei K Modellen]

Das müßte doch Compilerabhängig sein, oder?
Wenn die das unterstützen, dann sollte es möglich sein, derartige binarys zu compilieren.

Und wie sieht es mit x264 & Co aus?

[hustbaer]

TSX nicht bei K Modellen schrieb:

Das müßte doch Compilerabhängig sein, oder?

vermutlich braucht man compiler support dafür, ja. oder zumindest library support.

Wenn die das unterstützen, dann sollte es möglich sein, derartige binarys zu compilieren.

japp. wobei der compiler nicht magisch dafür sorgen kann dass transactional memory verwendet wird. ne library könnte ihre mutexen so anpassen dass das lock nicht blockt sondern statt dessen "transparent" ne transaktion aufmacht. glaub aber nicht dass das irgend eine lib vollkommen transparent macht, also einfach die bestehende mutex klasse abändert, weil es halt fälle gibt wo man wirklich blocken will und keine transaktion versuchen. bzw. es gibt ja zwei verschiedene arten transaktionen zu machen, und die sind nicht 100% kompatibel. d.h. wenn du zwei libs hättest wo die eine variante A verwendet und die andere variante B, und du hast nen callback von einer lib in die andere, dann kanns probleme geben. bzw. halt schlimmt performance einbrüche.

kurzfassung: ich glaube nicht dass man ohne anpassung des source-codes der applikation zu brauchbaren EXEn mit transactional memory support kommen wird.

Und wie sieht es mit x264 & Co aus?

keine ahnung. glaub aber nicht dass der synchronisierungs-overhead von x264 so wild ist dass es da viel bringen wird. aber da kann ich mich natürlich auch täuschen - hab noch nie nen H.264 encoder programmiert

[volkard]

Denke, das wird schnell Einzug halten (per Inline-Assembler) bei der Implementierung von malloc/new, vielleicht auch bei manchen Containern und Smartpointers. Und vielleicht für die Implemetierung des BS für Mutexe, Semaphoren etc.

Für Usercode ist das wohl eher nix.

[hustbaer]

volkard schrieb:

vielleicht für die Implemetierung des BS für Mutexe

Meinst du dass das OS für seine eigenen, internen Mutexen transactional memory verwenden wird, oder dass so Sachen wie CRITICAL_SECTION lock elision über transactional memory machen?
Bei ersterem sag ich: hoffentlich, und nicht ganz unwahrscheinlich. (Bei Linux könnte das vielleicht sogar recht schnell gehen.)
Was implizite lock elision bei CRITICAL_SECTION & Co angeht bin ich allerdings ziemlich skeptisch.
Maximal opt-in, also über irgend ein Flag dass der Usermode Code bei InitializeCriticalSectionEx übergeben muss.

[TSX nicht bei K Modellen]

Was für eine Haswell CPU würdet ihr an meiner Stelle denn nun, was TSE anbelangt kaufen?

Eine K Version, die man übertakten kann, aber kein TSE hat.

Oder eine normale Nicht-K Version, die man nicht übertakten kann, aber dafür das TSE hat?

Intel gibt den Performanceschub von TSE mit 40 % an.

Wenn der Linux Kernel und die verwendete Software wie z.b. x264 TSE nutzen, dann könnte das schon mehr bringen, als eine übertaktete CPU.
Overclocking bringt dagegen überall etwas, also auch bei Spielen.

Was meint ihr?

Einsatzweck der CPU wäre:
- SW compilieren
- Videos kodieren (-> x264 usw)
- Games (inzwischen selten geworden)

[hustbaer]

Ich würde werde mir nen Haswell Xeon kaufen. Der hat TSE, VT-d, vPro und ECC Support. Dafür halt nicht übertaktbar.
Ist mir persönlich aber ziemlich egal, mich interessiert wenn dann eher ob er sinnvoll untertaktbar ist (weniger Stromverbrauch => weniger Hitze => leiser).

Für mich persönlich ist der relativ geringe Speed-Boost, den man durch Übertakten mit normaler Luftkühlung rausholen kann, weniger wichtig, als dass ich ne aktuelle CPU mit all den netten, oben erwähnten Features habe (speziell ECC Support, aber TSE finde ich auch nicht uninteressant).
Was für dich Sinn macht kann ich natürlich nicht beantworten.

[TSX nicht bei K Modellen]

Okay, dann frage ich mal so.

Meint ihr, dass TSE beim kodieren von Videos einen wesentlichen Vorteil bringt, wenn TSE softwareseitig berücksichtigt wurde?

Wie ist das beim Kodieren bezüglich Multithreading?
Ergibt das viele Threads, die miteinander arbeiten müssen und gegenseitig auf sich warten müssen?

Ich schätze mal das TSE für Physikeffekte in Spielen sehr viel bringen könnte, da hat man ja solche Szenarien wo Thread Locks öfters vorkommen können. Richtig?