🪁
taisablog
Hardware Memory Models 訳 - Introduction: A Fairy Tale, Ending
🔖

Hardware Memory Models 訳 - Introduction: A Fairy Tale, Ending

元記事

Russ Cox

モチベーション

Introduction: A Fairy Tale, Ending

イントロダクション: おとぎ話の終焉

A long time ago, when everyone wrote single-threaded programs, one of the most effective ways to make a program run faster was to sit back and do nothing. Optimizations in the next generation of hardware and the next generation of compilers would make the program run exactly as before, just faster. During this fairy-tale period, there was an easy test for whether an optimization was valid: if programmers couldn't tell the difference (except for the speedup) between the unoptimized and optimized execution of a valid program, then the optimization was valid. That is, valid optimizations do not change the behavior of valid programs.

シングルスレッドの時代

  • より早いプログラムを動かす効果的な方法は座って何もしないことだった

次世代のハードウェアやコンパイラ

  • 以前より明らかにプログラムを早くできた
  • 「正しい最適化は正しいプログラムの振る舞いを変えない（valid optimizations do not change the behavior of valid programs）」と言われた
    • いくら最適化していってもプログラムの振る舞いは変わらないと言われていたけどこのあとそうならない時代がやってくる、ということだと思われる

One sad day, years ago, the hardware engineers' magic spells for making individual processors faster and faster stopped working. In response, they found a new magic spell that let them create computers with more and more processors, and operating systems exposed this hardware parallelism to programmers in the abstraction of threads. This new magic spell—multiple processors made available in the form of operating-system threads—worked much better for the hardware engineers, but it created significant problems for language designers, compiler writers and programmers.

時代は進み個々のプロセッサは高速化できなくなった

  • 代わりにプロセッサの数を増やした
  • ハードウェア上の並行処理は抽象化され、それらはプログラマへ公開された
  • マルチプロセッサにより OS のスレッド化が可能になったことは、ハードウェアエンジニアにとっては嬉しいことだったが、言語設計者・コンパイラ開発者・プログラマにとっては新たな課題となった。

こちらも合わせて読んでいます。

Many hardware and compiler optimizations that were invisible (and therefore valid) in single-threaded programs produce visible changes in multithreaded programs. If valid optimizations do not change the behavior of valid programs, then either these optimizations or the existing programs must be declared invalid. Which will it be, and how can we decide?

ハードウェアやコンパイラの最適化がもたらしたこと

  • マルチスレッドプログラムに明らかな変化をもたらした
  • これまでのシングルスレッドプログラムにはなかったこと

Here is a simple example program in a C-like language. In this program and in all programs we will consider, all variables are initially set to zero.
If thread 1 and thread 2, each running on its own dedicated processor, both run to completion, can this program print 0?

例）C like なシンプルなプログラム

  • 初期値は 0 とする
  • スレッド 1 と 2 がそれぞれのプロセッサで動いていて両方が完了すると過程した場合、このプログラムは 0 を出力する可能性はあるか？

image

It depends. It depends on the hardware, and it depends on the compiler. A direct line-for-line translation to assembly run on an x86 multiprocessor will always print 1. But a direct line-for-line translation to assembly run on an ARM or POWER multiprocessor can print 0. Also, no matter what the underlying hardware, standard compiler optimizations could make this program print 0 or go into an infinite loop.
  • 答え）ハードウェアやコンパイラによる
  • x86 マルチプロセッサで実行されるアセンブリへの行毎の直接変換では、常に 1 を出力する
  • ARM/POWER マルチプロセッサで実行されるアセンブリへの行毎の直接変換では、0 を出力することがある
  • 基盤となるハードウェアに関係なく、通常のコンパイラでは 0 を出力するか、無限ループに陥る可能性がある

“It depends” is not a happy ending. Programmers need a clear answer to whether a program will continue to work with new hardware and new compilers. And hardware designers and compiler developers need a clear answer to how precisely the hardware and compiled code are allowed to behave when executing a given program. Because the main issue here is the visibility and consistency of changes to data stored in memory, that contract is called the memory consistency model or just memory model.

「場合による」では困る

  • プログラマは、プログラムがどんな新しいハードウェアやコンパイラで動いていたとしても明確な答えが必要とするし、ハードウェア設計者やコンパイラ開発者は、ハードウェアやコンパイルされたコードがどれくらい正確に実行されるかについて明確な答えを必要とする
  • 主な課題は、メモリに格納されたデータ変更の「可視性」と「一貫性」であり、これらは メモリ一貫性モデル、またはメモリモデルと呼ばれる

Originally, the goal of a memory model was to define what hardware guaranteed to a programmer writing assembly code. In that setting, the compiler is not involved. Twenty-five years ago, people started trying to write memory models defining what a high-level programming language like Java or C++ guarantees to programmers writing code in that language. Including the compiler in the model makes the job of defining a reasonable model much more complicated.
  • 元々メモリモデルは、ハードウェアがアセンブリで書かれたコードを保証することであり、コンパイラは関係なかった
  • 25年前 Java や C++ のような高水準言語が、プログラマに保証するメモリモデルを書くのを試しはじめた
  • モデルにコンパイラを含むと、合理的なモデルを定義することがはるかに複雑になる

This is the first of a pair of posts about hardware memory models and programming language memory models, respectively. My goal in writing these posts is to build up background for discussing potential changes we might want to make in Go's memory model. But to understand where Go is and where we might want to head, first we have to understand where other hardware memory models and language memory models are today and the precarious paths they took to get there.

この記事はハードウェアメモリモデルとプログラム言語メモリモデルについての 2 つのうちの最初の 1 つである

  • 最終的には changes we might want to make in Go's memory model 記事にある可能性についてディスカッションするための背景を示すことが目的
  • Go がどこへ向かうか、向かいたい場所がどこかを理解するためにはまず、今とこれまでの他のハードウェアメモリモデルや言語メモリモデルの歩んできた経緯を知る必要がある

Again, this post is about hardware. Let's assume we are writing assembly language for a multiprocessor computer. What guarantees do programmers need from the computer hardware in order to write correct programs? Computer scientists have been searching for good answers to this question for over forty years.

あらためて、この記事はハードウェアについてである

  • マルチプロセッサのためにアセンブリ言語を書いていると過程しましょう
  • プログラマが正しいプログラムを書くために、ハードウェアからどのような保証が必要ですか？
  • コンピュータサイエンティストは40年間この問題に対する答えを探し続けている

Sequential Consistency へ続く

FacebookTwitterGitHub