マルチコア化の未来予測 半世紀前にSF映画「2001年宇宙の旅」に登場するコンピューターHAL-9000が並列コンピューティングの未来を示しました。マルチコアで構成されたコンピューターの物理コアを取り除いてもすぐにクラッシュせずに性能ダウンして処理が継続するという演出がありました。 当時ですらシングルコアコンピューティングの限界が予想されていて、現状のコンピューティングがマルチコア化しているという未来をしっかり予測できていたことがわかります。 演出はコア数に応じてコンピューティング性能がスケールしていることを表現しています。これはマルチコアスケールするソフトウェア実装の未来を示していたと思います。 シングルコア性能向上の頭打ち 2003年以降あたりはCPUの動作周波数が伸び悩み出したところ。 https://queue.acm.org/detail.cfm?id=2181798 より その
この記事について Go言語のスライスについて、その内部構造を整理します。 まとめ スライスとは、配列をラップして使いやすくした型 スライスと、配列の実体はメモリ上では別のオブジェクト スライスは以下の3つのパラメータを持つ構造体 配列の実体へのポインター 配列のうち、そのスライスで使用可能なサイズ (Len) 配列の実際のサイズ (Cap) reflect.SliceHeader を用いてスライスの構造を見ることが出来る
※本記事は2020年3月に公開された内容です。 上田拓也(@tenntenn)と申します。私はGoogle Developer ExpertでGoを担当しており、Go Conferenceの主催やgolang.tokyoなど各種コミュニティ活動も行っています。また、Goを採用している各社の技術顧問として開発現場にも携わっています。 今回はGoの基礎をご紹介します。私が公開している「Goで家計簿アプリを作ろう」というハンズオンの内容も一部抜粋して解説しているので、Goをはじめたばかりの初心者の方はぜひ参考にしていただけると嬉しいです。 Goの概要 サーバーサイドで使われる言語 最初に、Goの概要をご説明します。Goは2009年11月にGoogleがオープンソースで公開したプログラミング言語です。2020年2月に最新バージョン1.14がリリースされました。バージョンアップは大体半年ごとのペース
Apple M1 CPU と Intel CPU では CPUアーキテクチャ(命令文やデータ形式)も異なり バイナリファイル(実行可能なファイル)の中身も別物になる ※M1搭載のMacで従来(Intel CPU搭載Mac)向けのバイナリが実行できるのは Rosetta 2というアプリケーションでM1向けバイナリに変換したものを実行しているため また、macOSの実行ファイル形式Mach-Oでは複数のアーキテクチャのバイナリを格納することが可能で 複数のアーキテクチャ向けバイナリを格納したバイナリをユニバーサルバイナリと呼んだりする バイナリファイルのアーキテクチャを調べる file ファイル名 コマンドで調べることができる # Intel CPU向けバイナリの場合 $ file file ./foo/bar/hoge ./foo/bar/hoge: Mach-O 64-bit execut
go.mod 主にモジュールのインポートパスとバージョン情報を書いておくためのファイルで、いくつかのディレクティブを使ってアプリケーションがどのような依存関係を持っているか記述しておきます。 go mod tidy等を実行するとこのファイルを元に依存先を取得し次項で解説するgo.sumを生成します。 サンプル module github.com/ryo-yamaoka/sample-lib go 1.17 require github.com/ryo-yamaoka/direct-dependent-lib v0.0.2 require github.com/ryo-yamaoka/indirect-dependent-lib v0.0.4 // indirect exclude github.com/ryo-yamaoka/direct-dependent-lib v0.0.1 repl
はじめに 構造化メッセージが構築できる高速なロギングライブラリを謳っている『zap』を触ってみました。 ドキュメントがあまり充実していなくて、どんなことができるのかGodoc見ながら調査したので、その結果を自分用のメモがてら書いておこうと思います。 確認した環境とバージョン Mac OSX 10.11.6 (El Capitan) go v1.8 zap v1.0.0 zapの特徴 zapは以下のようなアプローチで高速化していると言っています。 Reflectionを使わない アロケーションしないJSONエンコーダを使用 可能な限りシリアル化のオーバーヘッドとアロケーションを避ける そして、独自のベンチマークによると、他の構造化ロギングライブラリだけでなく、標準ライブラリよりも高速に動作するそうです。 確かにReadMeのパフォーマンスを見ると圧倒的に高速で低アロケーションを実現しています
Goのnet/httpパッケージはとてもよくできており、Webサーバーを動かすのに必要になる「httpコネクションを確立してリクエストを読んでルーティングして……」という手続き的な処理を気にせずとも誰でも簡単にWebサーバーを立てられるようになっています。 ですが、そのnet/httpが代わりにやってくれている「裏側の処理」の部分が気になる、何やっているんだろう?と不思議に思っている方はいませんか? この本では、実際に筆者がnet/httpパッケージのソースコードを読み込んだうえで、「GoのWebサーバーがどのような仕組みで起動・動いているのか」というところについて、図を使いながら解説しています。
Go 言語での便利な Tips を紹介していきます。 「GO111MODULE=on」を設定しよう! 最近、いろんなサードパーティパッケージが Go モジュールサポートへの修正が進んでいます。 その中で、GO111MODULE=auto のデフォルト値のままだと go get に失敗するものが目立つようになりました。Go1.16 からは「GO111MODULE=on」がデフォルト値になる予定なので、それまでは各自「GO111MODULE=on」を設定しちゃいましょう! ドキュメント通り「go get」してもうまくインストールできない場合は「GO111MODULE=on」を指定してリトライしてみてください。 ちなみに OS に関係なく環境変数を書き換える便利なコマンドがあります。
はじめに 今年に入ってから仕事でGolang書いてるのでスケジューラあたりについて調べた。ググってもあんまり資料が多くなかったんでまとめる。ソースコードを参照する時はGo 1.9.3を見た。わかりやすさを重視してあえて雑に説明しているところがあるけどご了承ください。 多分間違ってるところあるんで詳しい人は優しく教えてください。 goroutineあたりの基本的な話 goroutineはグリーンスレッド、つまりOSのスレッドは直接使ってない。なので、goroutineを作ることはネイティブスレッドを作る処理よりもはるかにコストが安い。このgoroutineを複数作るとランタイムが勝手にマルチスレッドで実行する。詳細は後述。 また、メインルーチンもgoroutineとして管理される。 スケジューリングの登場人物 重要な登場人物はM, G, Pの3人。 M(Machine) OSのスレッドに対応
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか?」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
❯ tree -L 1 --dirsfirst . ├── dialects ├── License ├── README.md ├── association.go ├── association_test.go ├── callback.go ├── callback_create.go ├── callback_delete.go ├── callback_query.go ├── callback_query_preload.go ├── callback_row_query.go ├── callback_save.go ├── callback_system_test.go ├── callback_update.go ├── callbacks_test.go ├── create_test.go ├── customize_column_test.go ├── delete
概要 動機 goroutineを使ってパフォーマンスを改善する際に、どれくらの数で並行処理すればいいのか分かりませんでした。そこで、そもそもどのような仕組みなのか調べ、どのような性質の仕事が改善されるのか計測して、適切な数を決めるための観点を整理しました。 要約 goroutineはカーネルスレッドとM:Nの関係になっています。そしてカーネルスレッドごとにgoroutineのキューがあり、Goのスケジューラが順次実行していきます。 IO-Boundな処理は、netpollerが別のカーネルスレッドで非同期でシステムコールを実行するので他のgoroutineをブロックしないようになっています。 goroutineの使用時には以下の観点を留意する必要が計測から分かりました。 goroutineを使う場合はコンテキストスイッチのコストとトレードオフになる CPU-Boundなgoroutineは
今回は、Go言語の並行・並列処理のかなめともいえるgoroutine(ゴルーチン)周りを掘り下げていきます。 goroutineは、前回の記事で軽く触れたように、軽量スレッドと呼ばれるものです。 そこで、まずはこの軽量スレッドと通常のOSのスレッドがどう違うのかを説明します。 そのうえで、goroutineの低レベルな機能を扱うためのruntimeパッケージ、 goroutineのデータ競合を発見するRace Detecter、 さらに高度な非同期処理を書くときに必要になるsyncパッケージおよびsync/atomicパッケージの使い方を紹介します。 スレッドとgoroutineの違い スレッドとは、プログラムを実行するための「もの」であり、OSによって手配されます。 プログラムから見たスレッドは、「メモリにロードされたプログラムの現在の実行状態を持つ仮想CPU」です。この仮想CPUのそれ
概要 タイトルの通り、他言語から入門した人が最低限気にするべき、ネーミングルールをまとめました。 対象読者 Goの基本構文を理解している人を対象読者としています。 この記事で説明すること、説明しないこと 説明すること Goのファイル名、変数名などの名前付けに関するルールや慣例などを説明します。 説明しないこと 名前付け以外で気をつけるべきGoの書き方[1] がいくつかあります。 しかし、それらに関してはこの記事では説明しません。 筆者のバックグラウンド プログラマ歴はもうすぐ8年程で、Goの他には以下のような言語の経験があります。 JavaScript TypeScript PHP Ruby Java Scala Goは少し前に書いて、一時期書かない時期が続いていましたが、最近また書いています。 トータルするとGoの経験は1年半程度です。 意識すべき名前付けルール package名 利用し
はじめまして homie株式会社のエンジニア池見です。 先日、Goのホットリロードライブラリをrealizeからairに移行したので、移行した理由やairについて調べたことを記載します。 realizeからairに移行した理由 airのメリット airの導入方法 1. airのインストール 2. airの設定ファイル(.air.toml)作成 1. cmd 2. bin 3. full_bin 4. tmp_dir 5. exclude_dir 6. delay アプリケーションの起動 まとめ realizeからairに移行した理由 今までの開発において、ホットリロードライブラリにはrealizeを使っていました。 しかし、メンテナンスが止まっており、issues/253のようなエラーでハマることがありました。 他のライブラリを調べたところ、airというライブラリが現在も開発されており、s
まとめ スライス は 配列 のラッパーのようなもの。 スライス への操作をおこなうと、内部ではいい感じで 配列を操作してくれる。 スライス はその 配列 を参照する。 スライス という名前には 「配列の断片を使う」というニュアンスがあるように感じられる。 この動作を便宜的に「要素数を気にしないタイプの配列」として扱えるイメージ。 Gopher の間では「スライスだけで良いじゃん」という説もあるようだ。 検証 1. 配列をスライスする 配列から一部の要素だけをスライスしてみる。 (スライスっていう名前通りの使い方) array := [3]string {"Alice", "Bob", "Carol"} slice := array[:2]
Goのエラーハンドリングが採ったスタイル 多値返し 直積(関数の返値とエラーを両方返す) try-finallyをdeferという機構でカバー panicはプロセスを落とすためのもの Goはこの戦略でエラーハンドリングを行うとしましたので、「多値はなぜタプルじゃないんだ?」、「直和(返値orエラー)で十分じゃ?」「panic-recoverでtry-catchできそう?」などいう様な他の処理系の風習を持ち込むことは意味がありません。そしてそれらの提案の多くはすでに検討されリジェクトされてきた経緯があります。 「try組み込み関数」プロポーザルなんかも検討されマージ直前くらいまで進んだこともありますが、「Goのエラーハンドリング」にとって一長一短がありました。その欠点課題は解決できずに最終的にリジェクトされました。 「多値返し」は実にCPUフレンドリーな機構で、C言語の関数呼び出し規約にちょ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く