半導体業界における「IP」とは何なのかを説明したい - FPGA開発日記
「RISC-V」という言葉が徐々にエンジニア界隈に普及し始め、技術界隈のニュースサイトだけでなく、一般的なニュースを扱うような新聞社の記事でも見かけるようになってきました。例えば以下のような記事です。 www.nikkei.com 半導体エンジニアではない人がこのような記事を書く場合、「設計IP」について正しい知識を持っておかないと、少しおかしなことになってしまいます。しかしこれは記事を書いている記者だけを責めることは出来ません。半導体設計業界はソフトウェア開発業界に比べて小さな業界で、プレーヤの数も少なく、ネット上にあまり情報も出てきません。時事ネタを速攻で記事に起こさないといけない新聞記者が「IPってなんだっけ？」「リスクファイブってなんぞや？」ということをいちいち厳密に調べてられない、ということも理解できます。 そこで、非エンジニア（というか非半導体産業の方）でも理解できるように、R
x86-64プロセッサのスタックを理解する - Qiita
はじめに x86-64プロセッサにおけるスタックについて記載します。 使用したプロセッサ / OS / gcc / gdbは以下です。 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz 64bit Ubuntu14.04 64bit gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7 スタックとは後入れ先出し(LIFO;Last In First Out)方式のデータ保存領域です。 データをスタックに入れる操作をpushといいます。 データをスタックから取り出す操作をpopといいます。 popで取り出すデータは最近pushしたデータです。これがLIFOといわれる理由です。 具体例を示します。最初スタックに61,27,67のデータがあるとします。 push 20するとスタックの
QUICむけにAES-GCM実装を最適化した話 (1/2)
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)への貢献(後半) 〜自作OSのいまと昔 [第4回] | さくらのナレッジ
これまでのおさらい 前回の記事では、QEMUのVFAT機能にバグがあり、そしてその原因がメモリ破壊である、というところまでを突き止めました。 しかし、バグを発生させる直接の要因がわかっただけでは、そのバグを修正することはできません。今回はさらにもう一歩踏み込んで、どのような仕組みでメモリ破壊が発生したのかを突き止めると共に、それに基づいて修正パッチを投稿するところまでの道のりを紹介します。 lldbのwatchpoint機能 メモリ破壊系のバグらしき挙動を発見した際には、どのプログラムがそのアドレスのデータを書き換えたのか特定できれば、多くの場合原因が判明します。これを特定するために使える機能として、デバッガのwatchpointという機能があります。これは、特定のアドレスに対しての読み書きアクセスが発生した場合に、プログラムの動作を止めてデバッガで調査できる機能です。 この機能は通常、ハ
![開発ツール(QEMU)への貢献(後半) 〜自作OSのいまと昔 [第4回] | さくらのナレッジ](https://cdn-ak-scissors.b.st-hatena.com/image/square/8ebd29a74c89a12937872cd0c76541b18eac1ab8/height=288;version=1;width=512/https%3A%2F%2Fknowledge.sakura.ad.jp%2Fwp-content%2Fuploads%2F2019%2F07%2Fjisaku_os.png)
atomicパッケージが必要な理由と使い方 - Plan 9とGo言語のブログ
この記事は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にならない場
分岐予測の簡単な歴史 - Part 1 | POSTD
※これは、 RC（The Recurse Center：プログラマ教育施設） によって組織された講演シリーズである”localhost”を始動するために、Two Sigma（ツーシグマ）での2017年8月22日の分岐予測に関する講演の原稿を仮に書き起こしたものです。 コードで分岐を使われている方は、どれくらいいらっしゃいますか？ ifステートメントやパターンマッチングを使われているという方、よろしければ手を挙げてください。 ほとんどの聴衆が手を挙げる 次の質問に関しては手を挙げてもらうつもりはありませんが、もしそうお願いした場合、恐らく手を挙げる人の数は少なくなるのではないでしょうか。その質問とは、「分岐を実行する際、CPUが何をして、そのパフォーマンスは何を意味しているのかを十分に理解しているか」、そして「分岐予測に関する最新の論文を理解できるか」というものです。 この講演の目的は、CP
CPU律速なRuby/Pythonコードはデフォルト設定のdocker上で遅くなる - まめめも
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
Memory part 2: CPU caches [LWN.net]
Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today! [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
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
EPYCマシンの検証(2) - NUMAノードをまたぐメモリアクセス速度 - Cybozu Inside Out | サイボウズエンジニアのブログ
はじめに 技術顧問の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 / x86_64の割り込み処理 第1回 | 技術文書 | 技術情報 | VA Linux Systems Japan株式会社
「割り込み処理」とは、読んで字のごとく、通常の流れでプログラムを実行している所へ割り込んで別のプログラムを実行させることです。通常は、周辺デバイスなどからのイベント通知に使われるハードウェア割り込みを指しますので、本稿でも以下その意味で使います。 Linuxに限らず、現在一般的なOSでは、ディスクやマウスなどのデバイス入出力の他、タスクの切り替えや定時処理などさまざまな場面で割り込み機能を駆使して作られています。 ところで、現在一般的なPC/PCサーバは、IBM PCやIBM PC/AT以来約30年間、互換性を保ちながら発展してきたものであり、こと割り込みまわりに関しては、たいへんに複雑です。これを制御するLinuxも、この複雑さに対応するために、複雑な作りになっています。 本稿では、この複雑なLinuxの割り込み処理の低レイヤ (もっともハードウェアに近い部分) について解説していきます
RISC-V - Wikipedia
2013年1月に製造されたRISC-Vプロセッサのプロトタイプ RISC-V（リスク ファイブ）はカリフォルニア大学バークレー校で開発されオープンソースで提供されている命令セットアーキテクチャ（英: instruction set architecture、ISA）である[2]。 本稿ではISAであるRISC-Vの実装（RISC-Vコア）およびエコシステム（対応OS、開発ツール）を含めて解説する。 概要[編集] オープンソースライセンス[編集] 他の多くの命令セットアーキテクチャ（ISA）設計とは異なり、RISC-V ISAは、使用料のかからないオープンソースライセンスで提供されている。多くの企業がRISC-Vハードウェアを提供したり、発表したりしており、RISC-Vをサポートするオープンソースのオペレーティングシステムが利用可能であり、いくつかの一般的なソフトウェアツールチェーンで命令セ
perfから読み解くプロセッサトレースの仕組み (perf + Intel PT/ARM CoreSight) - Qiita
諸事情で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ページを開く
opv86
【後藤弘茂のWeekly海外ニュース】 AppleがArmベースのSoCをMacに採用する背景
AMDはなぜ資金面で圧倒的に勝ると思われるIntelを凌駕するCPUを開発できるのでしょうか？
https://usr.lmf.cnrs.fr/~jcf/ens/compil/x86-64.pdf
How many bytes does the push instruction push onto the stack when I don't specify the operand size?
x86_64 align stack and recover without saving registers