Submit Search
Upload
Intel TSX HLE を触ってみた x86opti
•
12 likes
•
7,275 views
Takashi Hoshino
Follow
Intel TSX HLE の可能性を探るべく,いくつかのマイクロベンチマークで性能評価した.
Read less
Read more
Technology
Report
Share
Report
Share
1 of 39
Download now
Download to read offline
Recommended
Intel TSX について x86opti
Intel TSX について x86opti
Takashi Hoshino
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
Preferred Networks
Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報
NVIDIA Japan
Gpu vs fpga
Gpu vs fpga
Yukitaka Takemura
そろそろSELinux を有効にしてみませんか?
そろそろSELinux を有効にしてみませんか?
Atsushi Mitsu
Java でつくる低レイテンシ実装の技巧
Java でつくる低レイテンシ実装の技巧
Ryosuke Yamazaki
Linuxのsemaphoreとmutexを見る
Linuxのsemaphoreとmutexを見る
wata2ki
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
Recommended
Intel TSX について x86opti
Intel TSX について x86opti
Takashi Hoshino
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
Preferred Networks
Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報
NVIDIA Japan
Gpu vs fpga
Gpu vs fpga
Yukitaka Takemura
そろそろSELinux を有効にしてみませんか?
そろそろSELinux を有効にしてみませんか?
Atsushi Mitsu
Java でつくる低レイテンシ実装の技巧
Java でつくる低レイテンシ実装の技巧
Ryosuke Yamazaki
Linuxのsemaphoreとmutexを見る
Linuxのsemaphoreとmutexを見る
wata2ki
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
CPUから見たG1GC
CPUから見たG1GC
Kenji Kazumura
仮想マシンにおけるメモリ管理
仮想マシンにおけるメモリ管理
Akari Asai
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
Kouhei Sutou
CPU / GPU高速化セミナー!性能モデルの理論と実践:実践編
CPU / GPU高速化セミナー!性能モデルの理論と実践:実践編
Fixstars Corporation
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくい
wata2ki
TVM の紹介
TVM の紹介
Masahiro Masuda
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
Norishige Fukushima
Ormとの付き合い方
Ormとの付き合い方
豊明 尾古
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
OSC北海道2014_JPUG資料
OSC北海道2014_JPUG資料
Chika SATO
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
Yahoo!デベロッパーネットワーク
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
BigQuery Query Optimization クエリ高速化編
BigQuery Query Optimization クエリ高速化編
sutepoi
RustによるGPUプログラミング環境
RustによるGPUプログラミング環境
KiyotomoHiroyasu
TIME_WAITに関する話
TIME_WAITに関する話
Takanori Sejima
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
Shigeru Hanada
MySQLテーブル設計入門
MySQLテーブル設計入門
yoku0825
条件分岐とcmovとmaxps
条件分岐とcmovとmaxps
MITSUNARI Shigeo
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
Preferred Networks
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
Takanori Sejima
YARN: a resource manager for analytic platform
YARN: a resource manager for analytic platform
Tsuyoshi OZAWA
10分で分かるデータストレージ
10分で分かるデータストレージ
Takashi Hoshino
More Related Content
What's hot
CPUから見たG1GC
CPUから見たG1GC
Kenji Kazumura
仮想マシンにおけるメモリ管理
仮想マシンにおけるメモリ管理
Akari Asai
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
Kouhei Sutou
CPU / GPU高速化セミナー!性能モデルの理論と実践:実践編
CPU / GPU高速化セミナー!性能モデルの理論と実践:実践編
Fixstars Corporation
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくい
wata2ki
TVM の紹介
TVM の紹介
Masahiro Masuda
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
Norishige Fukushima
Ormとの付き合い方
Ormとの付き合い方
豊明 尾古
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
OSC北海道2014_JPUG資料
OSC北海道2014_JPUG資料
Chika SATO
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
Yahoo!デベロッパーネットワーク
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
BigQuery Query Optimization クエリ高速化編
BigQuery Query Optimization クエリ高速化編
sutepoi
RustによるGPUプログラミング環境
RustによるGPUプログラミング環境
KiyotomoHiroyasu
TIME_WAITに関する話
TIME_WAITに関する話
Takanori Sejima
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
Shigeru Hanada
MySQLテーブル設計入門
MySQLテーブル設計入門
yoku0825
条件分岐とcmovとmaxps
条件分岐とcmovとmaxps
MITSUNARI Shigeo
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
Preferred Networks
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
Takanori Sejima
What's hot
(20)
CPUから見たG1GC
CPUから見たG1GC
仮想マシンにおけるメモリ管理
仮想マシンにおけるメモリ管理
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
CPU / GPU高速化セミナー!性能モデルの理論と実践:実践編
CPU / GPU高速化セミナー!性能モデルの理論と実践:実践編
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくい
TVM の紹介
TVM の紹介
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
画像処理ライブラリ OpenCV で 出来ること・出来ないこと
Ormとの付き合い方
Ormとの付き合い方
分散システムについて語らせてくれ
分散システムについて語らせてくれ
OSC北海道2014_JPUG資料
OSC北海道2014_JPUG資料
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
BigQuery Query Optimization クエリ高速化編
BigQuery Query Optimization クエリ高速化編
RustによるGPUプログラミング環境
RustによるGPUプログラミング環境
TIME_WAITに関する話
TIME_WAITに関する話
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
PostgreSQLのトラブルシューティング@第5回中国地方DB勉強会
MySQLテーブル設計入門
MySQLテーブル設計入門
条件分岐とcmovとmaxps
条件分岐とcmovとmaxps
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
Viewers also liked
YARN: a resource manager for analytic platform
YARN: a resource manager for analytic platform
Tsuyoshi OZAWA
10分で分かるデータストレージ
10分で分かるデータストレージ
Takashi Hoshino
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
Effective Modern C++ 勉強会#6 Item25
Effective Modern C++ 勉強会#6 Item25
Takashi Hoshino
Effective Modern C++ 勉強会#8 Item38
Effective Modern C++ 勉強会#8 Item38
Takashi Hoshino
10分で分かるバックアップとレプリケーション
10分で分かるバックアップとレプリケーション
Takashi Hoshino
CMSI計算科学技術特論B(15) インテル Xeon Phi コプロセッサー向け最適化、並列化概要 2
CMSI計算科学技術特論B(15) インテル Xeon Phi コプロセッサー向け最適化、並列化概要 2
Computational Materials Science Initiative
トランザクションの並行処理制御
トランザクションの並行処理制御
Takashi Hoshino
整数列圧縮
整数列圧縮
JAVA DM
Viewers also liked
(9)
YARN: a resource manager for analytic platform
YARN: a resource manager for analytic platform
10分で分かるデータストレージ
10分で分かるデータストレージ
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Effective Modern C++ 勉強会#6 Item25
Effective Modern C++ 勉強会#6 Item25
Effective Modern C++ 勉強会#8 Item38
Effective Modern C++ 勉強会#8 Item38
10分で分かるバックアップとレプリケーション
10分で分かるバックアップとレプリケーション
CMSI計算科学技術特論B(15) インテル Xeon Phi コプロセッサー向け最適化、並列化概要 2
CMSI計算科学技術特論B(15) インテル Xeon Phi コプロセッサー向け最適化、並列化概要 2
トランザクションの並行処理制御
トランザクションの並行処理制御
整数列圧縮
整数列圧縮
Similar to Intel TSX HLE を触ってみた x86opti
CMSI計算科学技術特論A (2015) 第9回
CMSI計算科学技術特論A (2015) 第9回
Computational Materials Science Initiative
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
信之 岩永
Boost Tour 1.50.0 All
Boost Tour 1.50.0 All
Akira Takahashi
中3女子でもわかる constexpr
中3女子でもわかる constexpr
Genya Murakami
0から理解するニューラルネットアーキテクチャサーチ(NAS)
0から理解するニューラルネットアーキテクチャサーチ(NAS)
MasanoriSuganuma
リバースエンジニアリングのための新しいトレース手法 - PacSec 2010
リバースエンジニアリングのための新しいトレース手法 - PacSec 2010
Tsukasa Oi
Deep Learning Lab MeetUp 学習編 AzureインフラとBatch AI
Deep Learning Lab MeetUp 学習編 AzureインフラとBatch AI
喜智 大井
機械学習 / Deep Learning 大全 (4) GPU編
機械学習 / Deep Learning 大全 (4) GPU編
Daiyu Hatakeyama
HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQL
akirahiguchi
Parquetはカラムナなのか?
Parquetはカラムナなのか?
Yohei Azekatsu
lispmeetup#63 Common Lispでゼロから作るDeep Learning
lispmeetup#63 Common Lispでゼロから作るDeep Learning
Satoshi imai
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
20200709 fjt7tdmi-blog-appendix
20200709 fjt7tdmi-blog-appendix
Akifumi Fujita
CRF を使った Web 本文抽出
CRF を使った Web 本文抽出
Shuyo Nakatani
Prosym2012
Prosym2012
MITSUNARI Shigeo
Boost Tour 1_58_0 merge
Boost Tour 1_58_0 merge
Akira Takahashi
最尤系統樹推定と系統樹の信頼性評価 講義編
最尤系統樹推定と系統樹の信頼性評価 講義編
astanabe
Haswellサーベイと有限体クラスの紹介
Haswellサーベイと有限体クラスの紹介
MITSUNARI Shigeo
エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao
エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao
Torao Takami
リテラル文字列型までの道
リテラル文字列型までの道
Satoshi Sato
Similar to Intel TSX HLE を触ってみた x86opti
(20)
CMSI計算科学技術特論A (2015) 第9回
CMSI計算科学技術特論A (2015) 第9回
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
Boost Tour 1.50.0 All
Boost Tour 1.50.0 All
中3女子でもわかる constexpr
中3女子でもわかる constexpr
0から理解するニューラルネットアーキテクチャサーチ(NAS)
0から理解するニューラルネットアーキテクチャサーチ(NAS)
リバースエンジニアリングのための新しいトレース手法 - PacSec 2010
リバースエンジニアリングのための新しいトレース手法 - PacSec 2010
Deep Learning Lab MeetUp 学習編 AzureインフラとBatch AI
Deep Learning Lab MeetUp 学習編 AzureインフラとBatch AI
機械学習 / Deep Learning 大全 (4) GPU編
機械学習 / Deep Learning 大全 (4) GPU編
HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQL
Parquetはカラムナなのか?
Parquetはカラムナなのか?
lispmeetup#63 Common Lispでゼロから作るDeep Learning
lispmeetup#63 Common Lispでゼロから作るDeep Learning
Vacuum徹底解説
Vacuum徹底解説
20200709 fjt7tdmi-blog-appendix
20200709 fjt7tdmi-blog-appendix
CRF を使った Web 本文抽出
CRF を使った Web 本文抽出
Prosym2012
Prosym2012
Boost Tour 1_58_0 merge
Boost Tour 1_58_0 merge
最尤系統樹推定と系統樹の信頼性評価 講義編
最尤系統樹推定と系統樹の信頼性評価 講義編
Haswellサーベイと有限体クラスの紹介
Haswellサーベイと有限体クラスの紹介
エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao
エンジニア目線で見る TLA+ と PlusCal - TAKAMI Torao
リテラル文字列型までの道
リテラル文字列型までの道
More from Takashi Hoshino
Serializabilityとは何か
Serializabilityとは何か
Takashi Hoshino
Isolation Level について
Isolation Level について
Takashi Hoshino
データベースシステムにおける直列化可能性と等価な時刻割り当てルールの提案 rev.3
データベースシステムにおける直列化可能性と等価な時刻割り当てルールの提案 rev.3
Takashi Hoshino
WalB Driver Internals
WalB Driver Internals
Takashi Hoshino
Effective Modern C++ 勉強会#1 Item3,4
Effective Modern C++ 勉強会#1 Item3,4
Takashi Hoshino
WALをバックアップとレプリケーションに使う方法
WALをバックアップとレプリケーションに使う方法
Takashi Hoshino
メモリより大きなデータの Sufix Array 構築方法の紹介
メモリより大きなデータの Sufix Array 構築方法の紹介
Takashi Hoshino
WalBの紹介
WalBの紹介
Takashi Hoshino
10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ
Takashi Hoshino
Intel TSX 触ってみた 追加実験 (TTAS)
Intel TSX 触ってみた 追加実験 (TTAS)
Takashi Hoshino
Suffix Array 構築方法の紹介
Suffix Array 構築方法の紹介
Takashi Hoshino
An Efficient Backup and Replication of Storage
An Efficient Backup and Replication of Storage
Takashi Hoshino
ログ先行書き込みを用いたストレージ差分取得の一手法
ログ先行書き込みを用いたストレージ差分取得の一手法
Takashi Hoshino
WalB: Block-level WAL. Concept.
WalB: Block-level WAL. Concept.
Takashi Hoshino
VMware Backup in Cybozu Labs
VMware Backup in Cybozu Labs
Takashi Hoshino
Vmbkp: VMware vSphere Incremental Backup Tool
Vmbkp: VMware vSphere Incremental Backup Tool
Takashi Hoshino
Inside database
Inside database
Takashi Hoshino
More from Takashi Hoshino
(17)
Serializabilityとは何か
Serializabilityとは何か
Isolation Level について
Isolation Level について
データベースシステムにおける直列化可能性と等価な時刻割り当てルールの提案 rev.3
データベースシステムにおける直列化可能性と等価な時刻割り当てルールの提案 rev.3
WalB Driver Internals
WalB Driver Internals
Effective Modern C++ 勉強会#1 Item3,4
Effective Modern C++ 勉強会#1 Item3,4
WALをバックアップとレプリケーションに使う方法
WALをバックアップとレプリケーションに使う方法
メモリより大きなデータの Sufix Array 構築方法の紹介
メモリより大きなデータの Sufix Array 構築方法の紹介
WalBの紹介
WalBの紹介
10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ
Intel TSX 触ってみた 追加実験 (TTAS)
Intel TSX 触ってみた 追加実験 (TTAS)
Suffix Array 構築方法の紹介
Suffix Array 構築方法の紹介
An Efficient Backup and Replication of Storage
An Efficient Backup and Replication of Storage
ログ先行書き込みを用いたストレージ差分取得の一手法
ログ先行書き込みを用いたストレージ差分取得の一手法
WalB: Block-level WAL. Concept.
WalB: Block-level WAL. Concept.
VMware Backup in Cybozu Labs
VMware Backup in Cybozu Labs
Vmbkp: VMware vSphere Incremental Backup Tool
Vmbkp: VMware vSphere Incremental Backup Tool
Inside database
Inside database
Recently uploaded
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
Hiroki Ichikura
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
sugiuralab
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版) 2024年4月作成
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版) 2024年4月作成
Hiroshi Tomioka
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
Recently uploaded
(9)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版) 2024年4月作成
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版) 2024年4月作成
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
Intel TSX HLE を触ってみた x86opti
1.
Intel TSX HLE
を触ってみた x86/x64最適化勉強会6 2013-08-31 星野喬@サイボウズ・ラボ / @starpoz 1
2.
自己紹介 • 星野 喬(@starpoz) –
サイボウズ・ラボ • 興味 – データベース,ストレージ,分散アルゴリズムなど • 今の仕事: #walbdev – Linux における block device の効率的な 増分記録ドライバ • http://developer.cybozu.co.jp/tech/?p=5130 2
3.
今日の話 • Intel の最新
CPU (Haswell) の 新機能のひとつ TSX HLE を使い 性能評価をしてみて トランザクショナルメモリの可能性を探る • 後追い実験大歓迎 J 3
4.
トランザクショナルメモリ (TM) • 「Intel
TSX について」参照 – http://www.slideshare.net/starpos/intel-tsxx86opti4 • 要約: atomic メモリアクセスを実現する技術 – 他と競合したくない一連のメモリアクセス – Lock-free な時代がすぐそこに(反論アリ 4
5.
Intel TSX • Transactional
Synchronization eXtension • 2 つのインターフェースを提供 – HLE: Lock prefix の拡張で細粒度の排他を実現 – RTM: 制約はあるが HardwareTM そのもの • 楽観的な振舞 • CPU L1 キャッシュ上で必要なデータを管理 • キャッシュライン単位での競合検出 5
6.
競合 (collision) • あるリソースへの複数主体からのアクセスが 同時に起きること(要出典) •
Intel TSX の場合: – リソース: キャッシュライン単位のメモリ領域 – 主体: スレッド – アクセス: read/write (全て read の場合を除く) – 同時: クリティカルセクションの実行期間が重複 6
7.
HLE: Hardware Lock
Elision 競合発生しないケース 競合発生するケース 時間 ロックを無視して 投機実行開始 競合発生しなかった めでたしめでたし 時間 競合発生 ロック取れたので 変更破棄 必ず実行できる ロック待ち体制 • 楽観的挙動 –(失敗)à 悲観的挙動 • 失敗すると電気代が無駄になる 7
8.
Spinlock with HLE •
GCC 4.8 の場合 (マニュアル参照) class SpinlockHle { private: char &lock_; public: explicit SpinlockHle(char &lock) : lock_(lock) { int flags = __ATOMIC_ACQUIRE | __ATOMIC_HLE_ACQUIRE; while (__atomic_exchange_n(&lock_, 1, flags)) _mm_pause(); } ~SpinlockHle() noexcept { int flags = __ATOMIC_RELEASE | __ATOMIC_HLE_RELEASE; __atomic_clear(&lock_, flags); } }; 8
9.
HLE on/off の違い ---
t1.hle0.s 2013-08-31 09:23:58.000000000 +0900 +++ t1.hle1.s 2013-08-31 09:23:30.000000000 +0900 @@ -13,12 +13,12 @@ .L3: rep nop .L2: movl %edx, %eax xchgb -1(%rsp), %al + xacquire xchgb -1(%rsp), %al testb %al, %al jne .L3 movb $0, -1(%rsp) + xrelease movb $0, -1(%rsp) xorl %eax, %eax ret .cfi_endproc .LFE859: 9
10.
実験環境 • CPU: Core
i7-4770 – 4cores 8HT – HT 有効 – TurboBoost 有効 • メモリ: 16GB • OS: Ubuntu 13.04 x86_64 kernel 3.8.19 • コンパイラ: GCC 4.8.1 – 最適化フラグ: -O2 のみ 10
11.
実験方法 • スレッドを必要なだけ起動して,X 秒間クリティカル セクション
(CS) を繰り返し実行 • Spinlock を使って CS の排他を取る – HLE 有効/無効は実験パラメータ – 終了判定のために CS 実行毎に atomic<bool> を load するオーバーヘッドあり • CS の実行回数の合計値を X で割ったものを スループットとする • 上記実験を Y 回行い,スループットの avg, min, max を計算 11
12.
Experiments • • • • • Expr1: Expr2: Expr3: Expr4: Expr5: simple counter(s) counter(s) with
delay collision timing access area size map operations 12
13.
Expr1: simple counter(s) •
クリティカルセクションループ while (!isEnd_.load(std::memory_order_relaxed)) { SpinlockHle<useHLE> lk(mutex_); counter_++; } • パラメータ – 競合率 100%: counter を全スレッドで共有 – 競合率 0%: スレッド毎に counter を持つ • キャッシュラインが異なるように 64byte 毎に配置 Counter Thread 競合率 100% Thread 競合率 0% Counter 13
14.
Expr1: result 44.7x 10 sec,
20 trials spinlock なしの 8 threads 実行で 4309M なので, isEnd.load() のオーバーヘッドは 8% 程度 14
15.
Expr1: result (scaled) 競合100%
のときは オーバーヘッドの分 性能悪化 10 sec, 20 trials 15
16.
Expr2: counter(s) with
delay • 1us delay (誤差は実測 70ns 以下) void delayUsec(uint64_t usec) { auto ts0 = std::chrono::high_resolution_clock::now(); uint64_t diff = 0; while (diff < usec * 1000) { auto ts1 = std::chrono::high_resolution_clock::now(); diff = std::chrono::duration_cast< std::chrono::nanoseconds>(ts1 - ts0).count(); } } • クリティカルセクション while (!isEnd_.load(std::memory_order_relaxed)) { SpinlockHle<useHLE> lk(mutex_); counter_++; delayUsec(1); } 16
17.
Expr2: result 10 sec,
20 trials cs が 1us でも最大 5 倍程度の性能アップを期待できる 17
18.
Expr3: • 1us
delay の前/後にカウンタを更新する while (!isEnd_.load(std::memory_order_relaxed)) { SpinlockHle<useHLE> lk(mutex_); if (isBefore) delayUsec(1); counter_++; if (!isBefore) delayUsec(1); } • 目的 – 競合発覚するのが CS の最初か最後かで楽観的 実行が失敗する頻度が変化するのを観察したい 18
19.
Expr3: result 10 sec,
20 trials 19
20.
Expr4: • 目的 –
write buffer や read flag を管理する領域は有 限なので,HLE で恩恵が受けられるアクセスサイ ズの上限を知りたい • 手段 – X 個の 64bytes メモリ断片をスレッド毎に用意 – CS の中で Y 個にアクセスする(重複アリ) – 他の条件を同じにするため,Y は固定 – 2 <= X <= Y で評価 – 今回は write の評価のみ 20
21.
Expr4: 1-4 thread
16 clines 1 threads 3 threads 10 sec, 20 trials 2 threads 4 threads CS 内では 12 lines までのアクセスにした方が良さそう 21
22.
Expr4: 5-8 thread
16 clines 5 threads 7 threads 10 sec, 20 trials 6 threads 8 threads 安定しない結果.12 lines を越えても効果があるケースも 22
23.
Expr4: 5-8 thread
64 clines 5 threads 7 threads 5 sec, 100 trials 6 threads 8 threads 安定しない結果,実験方法に問題があるかも? 23
24.
Expr5: • 目的: –
実用的なデータ構造で HLE の効果を知る • 手段: – std::map<uint32_t, uint32_t> をひとつの spinlock で排他 – read 比率を変える: 0%, 90%, 99%, 100% • read 操作: ランダムキーで lower_bound 検索 • write 操作: ひとつ削除,その後 insert – 初期アイテム数: 10K (約2MB), 1M (約100MB) – (ついでに自作の btree map でも試す) 24
25.
20131022追記 • 以下 expr5
の結果グラフのスループットは全 て誤って 3 倍に集計されていたことが発覚 – 集計スクリプトのミス • スループットを見るときは表記の 1/3 にして ご覧ください 25
26.
Expr5: 10K items,
read 0% std::map はスレッド数増加で HLE on が逆転 性能上昇は最大で 39% (8 threads) btree も同様の傾向 26
27.
Expr5: 10K items,
read 90% std::map では 2 threads 以上で HLE on が上回る. 最大46%性能Up (3 threads) btree では傾向が安定しないが 概ね同程度と言える 27
28.
Expr5: 10K items,
read 99% std::map は最大 2.9 倍の性能 (3 threads) btree も最大 2.4 倍の性能 (3 threads) 28
29.
Expr5: 10K items,
read 100% std::map は 6 threads で 7.4 倍 btree は 4 threads で 3.4 倍 29
30.
Expr5: 1M items,
read 0% 3 threads 以上で HLE on の方が良い std::map 6.9% up (3 threads) btree: 7.3% up (3 threads) 30
31.
Expr5: 1M items,
read 90% std::map は 58% up (3 threads) btree は 54% up (3 threads) 31
32.
Expr5: 1M items,
read 99% std::map は 2.4 倍 (3 threads) btree は 2.4 倍 (3 threads) 32
33.
Expr5: 1M items
read 100% std::map は 2.6 倍 (4 threads) btree は 2.6 倍 (3 threads) 33
34.
Expr5: まとめ • 性能向上 –
10K items で 最大 7.4 倍 (read 100%) – 1M items で 最大 2.6 倍 (read 100%) • 現状の結論 – データがキャッシュに乗る程度に小さく read 比 率が低いと HLE のオーバーヘッドが目立つ • 考察 – critical section でより多くの操作をするケースも 評価すべき 34
35.
HLE 評価まとめ • 手間なしで性能が向上する魔法 –
楽観的挙動 à 悲観的挙動なので 性能最悪値を保証してくれるのも魅力 – デッドロックは従来通り気をつける必要あり • 使うべき条件 – 条件1: 競合が起きにくい (read 比率が高い) – 条件2: クリティカルセクション実行時間が短い – 条件3: アクセス対象メモリが少ない 35
36.
今後の展望 • HLE には条件分岐予測のように
elision すべきかど うかを予測して性能向上させる余地があるのではな いか? – 今回あまり調べてないので既にやってたらごめんなさい • RTMは? – L1 のみならず,L2/L3 そしてメモリコントローラまで TM のことを考えてくれるようになるまで様子見したい – 速度が重要じゃない用途なら STM と連動できるように なった時点で開発効率の点から有用なのではないか 36
37.
おまけ: 私の単体 CPU
購入歴 • • • • • • AMD K6-300 Intel Pentium II 333MHz AMD Athlon 64 3200+ AMD Athlon X2 BE-2400 AMD Phenom II X4 910e AMD Phenom II X6 1065T • こんな私が買う気になってるのだから Haswell は凄い! 37
38.
実験してみたい人へ • 用意するもの – TSX
サポート付きの Haswell CPU – Linux OS (古いものはオススメしない) – GCC 4.8 以降 • ソースコード – https://github.com/starpos/hle_bench 38
39.
ありがとうございました • ご質問,コメントはご気軽にどうぞ J 39
Download now