「RISC-V」という言葉が徐々にエンジニア界隈に普及し始め、技術界隈のニュースサイトだけでなく、一般的なニュースを扱うような新聞社の記事でも見かけるようになってきました。例えば以下のような記事です。 www.nikkei.com 半導体エンジニアではない人がこのような記事を書く場合、「設計IP」について正しい知識を持っておかないと、少しおかしなことになってしまいます。しかしこれは記事を書いている記者だけを責めることは出来ません。半導体設計業界はソフトウェア開発業界に比べて小さな業界で、プレーヤの数も少なく、ネット上にあまり情報も出てきません。時事ネタを速攻で記事に起こさないといけない新聞記者が「IPってなんだっけ？」「リスクファイブってなんぞや？」ということをいちいち厳密に調べてられない、ということも理解できます。 そこで、非エンジニア（というか非半導体産業の方）でも理解できるように、R
プロセッサにはスタックを操作するためのレジスタや命令があります。 スタックは主に次のデータを格納するために使用します。 リターンアドレス ベースポインタ 引数 ローカル変数 スタック スタックとは後入れ先出し(LIFO;Last In First Out)方式のデータ保存領域です。 データをスタックに入れる操作をpushといいます。 データをスタックから取り出す操作をpopといいます。 popで取り出すデータは最近pushしたデータです。これがLIFOといわれる理由です。 具体例を示します。最初スタックに61,27,67のデータがあるとします。 push 20するとスタックのトップにデータが追加されます。 popするとスタックのトップのデータが削除されて取り出されます。 スタックという言葉には干し草の山という意味があります。 干し草の山(スタック)に干し草(データ)を積み上げたり(push
4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC
これまでのおさらい 前回の記事では、QEMUのVFAT機能にバグがあり、そしてその原因がメモリ破壊である、というところまでを突き止めました。 しかし、バグを発生させる直接の要因がわかっただけでは、そのバグを修正することはできません。今回はさらにもう一歩踏み込んで、どのような仕組みでメモリ破壊が発生したのかを突き止めると共に、それに基づいて修正パッチを投稿するところまでの道のりを紹介します。 lldbのwatchpoint機能 メモリ破壊系のバグらしき挙動を発見した際には、どのプログラムがそのアドレスのデータを書き換えたのか特定できれば、多くの場合原因が判明します。これを特定するために使える機能として、デバッガのwatchpointという機能があります。これは、特定のアドレスに対しての読み書きアクセスが発生した場合に、プログラムの動作を止めてデバッガで調査できる機能です。 この機能は通常、ハ
この記事はQiitaで公開されていました 以下のコードは通常分かりづらいバグを持っています。 package main import ( "fmt" "runtime" "sync" ) type Counter int32 func (c *Counter) Inc() { *c++ } func main() { var c Counter var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { c.Inc() wg.Done() }() } wg.Wait() fmt.Println("Count =", c, "GOMAXPROCS =", runtime.GOMAXPROCS(0)) } このコードは、GOMAXPROCS の値が2以上の場合、最後にプリントされるカウンタが1000にならない場
※これは、 RC（The Recurse Center：プログラマ教育施設） によって組織された講演シリーズである”localhost”を始動するために、Two Sigma（ツーシグマ）での2017年8月22日の分岐予測に関する講演の原稿を仮に書き起こしたものです。 コードで分岐を使われている方は、どれくらいいらっしゃいますか？ ifステートメントやパターンマッチングを使われているという方、よろしければ手を挙げてください。 ほとんどの聴衆が手を挙げる 次の質問に関しては手を挙げてもらうつもりはありませんが、もしそうお願いした場合、恐らく手を挙げる人の数は少なくなるのではないでしょうか。その質問とは、「分岐を実行する際、CPUが何をして、そのパフォーマンスは何を意味しているのかを十分に理解しているか」、そして「分岐予測に関する最新の論文を理解できるか」というものです。 この講演の目的は、CP
English version 要約 dockerはデフォルトでセキュリティ機構（Spectre脆弱性の対策）を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります（実行時間が倍くらいになることがあります）。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合： $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
October 1, 2007 This article was contributed by Ulrich Drepper [Editor's note: This is the second installment in Ulrich Drepper's "What every programmer should know about memory" document. Those who have not read the first part will likely want to start there. This is good stuff, and we once again thank Ulrich for allowing us to publish it. One quick request: in a document of this length there are
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
はじめに 技術顧問のsatです。前回に引き続き、EPYCマシンの検証についての話をします。手元のEPYCマシン(Super Micro AS-1023US-TR4)はNUMAアーキテクチャ(後述)を採用してます。今回はこのマシンにおけるNUMAノードをまたいだメモリアクセスに関するデータを採取しましたので、その結果をお伝えします。 NUMAについて知っているかた向けの結論 2CPUパッケージから成るEPYCマシンにおいては、CPUパッケージごとに4つのノード、合計8つのノードがある 同じCPUパッケージ上のリモートノード上のメモリへのアクセス速度はローカルノード上のメモリへのアクセス速度に比べて1.7倍程度遅い 別のCPUパッケージ上のリモートノード上のメモリへのアクセス速度はローカルノード上のメモリへのアクセス速度に比べて3.3倍程度遅い (記事では省略したが)"numactl --in
「割り込み処理」とは、読んで字のごとく、通常の流れでプログラムを実行している所へ割り込んで別のプログラムを実行させることです。通常は、周辺デバイスなどからのイベント通知に使われるハードウェア割り込みを指しますので、本稿でも以下その意味で使います。 Linuxに限らず、現在一般的なOSでは、ディスクやマウスなどのデバイス入出力の他、タスクの切り替えや定時処理などさまざまな場面で割り込み機能を駆使して作られています。 ところで、現在一般的なPC/PCサーバは、IBM PCやIBM PC/AT以来約30年間、互換性を保ちながら発展してきたものであり、こと割り込みまわりに関しては、たいへんに複雑です。これを制御するLinuxも、この複雑さに対応するために、複雑な作りになっています。 本稿では、この複雑なLinuxの割り込み処理の低レイヤ (もっともハードウェアに近い部分) について解説していきます
他の多くの命令セットアーキテクチャ（ISA）設計とは異なり、RISC-V ISAは、使用料のかからないオープンソースライセンスで提供されている。多くの企業がRISC-Vハードウェアを提供したり、発表したりしており、RISC-Vをサポートするオープンソースのオペレーティングシステムが利用可能であり、いくつかの一般的なソフトウェアツールチェーンで命令セットがサポートされている。 RISC-Vは縮小命令セットコンピュータ (RISC) の原則に基づいている。RISC-V ISAの注目すべき特徴は、ロードストア・アーキテクチャ[3][4]、CPU内のマルチプレクサを簡素化するビットパターン、IEEE 754浮動小数点、アーキテクチャ的に中立な設計、符号拡張を高速化するために最上位ビットを固定位置に配置することなどである。命令セットは、幅広い用途に対応できるように設計されている。可変幅で拡張可能なの
諸事情でperfのソースコードを読んだのでせっかくなので簡単に解説。 今回はperfの中でもイベントの記録を担当するperf recordコマンドの処理を見ていく。特に近年はCPUがトレース機構を持っておりperfもその恩恵に預かっているため、本記事ではperf recordの中でもCPUのプロセッサトレース機構との連携部分に注目したい。 本音を言えば、perfよりIntel Processor Trace(Intel PT)やARM CoreSightといったプロセッサトレース自体に興味があるのだが、これらはLinux上ではperfイベントとして実装されているためperfコマンドの実装を皮切りに解析する腹づもりだ。 1. Perf アーキテクチャ 元々perfはPerformance counters for Linux (PCL)という名前の前身が存在しており、CPUの提供するパフォー
インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基本的な考え CPU使用率が80％から90%をずっと推移している！と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く