Go 1.19 Release Notes - The Go Programming Language
Introduction to Go 1.19 The latest Go release, version 1.19, arrives five months after Go 1.18. Most of its changes are in the implementation of the toolchain, runtime, and libraries. As always, the release maintains the Go 1 promise of compatibility. We expect almost all Go programs to continue to compile and run as before. Changes to the language There is only one small change to the language, a
Dumpster diving the Go garbage collector
Principal Engineer @ New Relic, Founding Engineer @ Pixie Labs Go is a garbage collected language. This makes writing Go simpler, because you can spend less time worrying about managing the lifetime of allocated objects. Memory management is definitely easier in Go than it is in, say, C++. But it’s also not an area we as Go developers can totally ignore, either. Understanding how Go allocates and
How We Saved 70K Cores Across 30 Mission-Critical Services (Large-Scale, Semi-Automated Go GC Tuning @Uber)
How We Saved 70K Cores Across 30 Mission-Critical Services (Large-Scale, Semi-Automated Go GC Tuning @Uber) Introduction As part of Uber engineering’s wide efforts to reach profitability, recently our team was focused on reducing cost of compute capacity by improving efficiency. Some of the most impactful work was around GOGC optimization. In this blog we want to share our experience with a highly
GoはいつGCするのか?
TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重
Go コンパイラのコードを読んでみよう - kosui
はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです！ 何よりも感動したことは、 gc そのものが全て Go で書かれていて、
GoのGCを10分で学ぼう - Qiita
はじめに GoのGC(Garbage Collection)を調べる中で学んだことをなるべく分かりやすく簡潔にまとめたものです。 GCのアルゴリズムやメモリ割り当てについてまとめています。 記事内で使われている「オブジェクト」という用語はGoにおいては適切でないかもしれませんが、説明のしやすさから使用しています。 概要を把握しやすいように単純化しているため細部は正確でない部分があります。 GC基本 用語集 前提となる用語です。 ルート ルートとは、オブジェクトが到達可能か（生存しているか）を判定するための始点です。 プログラミング言語にもよりますが、基本的にメモリのスタック領域がルートになります。 フラグメンテーション フラグメンテーションとは、使用可能なメモリが断片化し途切れ途切れになっている状態です。 フラグメンテーションになってしまうと、総量的にはメモリが空いていてもアプリケーション
GHC/RTSのGCについて - Qiita
Haskellで効率の良いコードを書くためにはいかに不要なサンクを潰すか、ということが重要だと言われています。しかし、そもそもなぜサンクが増えると効率が悪くなるのでしょうか。 Haskellのメモリ確保は高速 まず、Haskellにおいてメモリの確保はどの程度コストがかかるものなのでしょうか。次のプログラムを使って確かめてみましょう。 {-# LANGUAGE BangPatterns #-} {-# OPTIONS_GHC "-ddump-simpl" #-} module Main2 where bench :: Int -> (a -> a) -> a -> a bench n f i = go n i where go 0 !i = i go k !i = go (k-1) (f i) {-# NOINLINE bench #-} main :: IO () main = prin
GoCon に参加して本当に良かった話 - アルパカ三銃士
今回 CFP を提出して選ばれ、念願だった GoCon へ参加することができた。 そして、本当に良い体験をしたため忘れないうちに記録する。 この記事を読んでて GoCon に参加しようか迷っている人がいれば勇気を出して是非参加して欲しいと思っている。 こういう自分の好きな言語やサービスのコミュニティが開催する大きなイベントは、みんな自分と同じ共通の趣味を持っている人達だから、絶対に楽しい会話ができるため、沢山の人に話しかけてみるといいと思った。 なお登壇した内容の記事は以下のリンクで。 codehex.hateblo.jp トークについて どれもとても面白い内容のトークだったが、中でも kaneshin0120 さんの「How to write go code」を聞いて「こういう風なトークの形も在るんだ」と感慨深いものがあった。 内容は基本的にライブブラウジングで、Go 初心者がどのページ
Profiling Go ⋆ integralist
integralist Compassionate Listener. Polyglot. Author. Husband. Father. He/Him. Memory Management Types of Profiling Tools Matrix Analysis Steps Base Example ReadMemStats Pprof Trace Conclusion Note: I highly recommend also reading this official diagnostics documentation. Memory Management Before we dive into the techniques and tools available for profiling Go applications, we should first understa
Go言語のリアルタイムGC 理論と実践 | POSTD
(編注：誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「本当にGoを使えば実現できるのか？ もしできるならどうやって？」 このブログ記事ではGoのガベージコレクタを、どのように機能し（トリコロールアルゴリズム）、なぜ機能し（こんなに短いGCによる一時停止時間の実現）、そして何よりも、それが機能するのかどうか（GCによる
GolangのGCを追う
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された．この変更について「ちゃんと」理解するため，アルゴリズムレベルでGoのGCについて追ってみた． まずGoのGCの現状をパフォーマンス（レイテンシ）の観点からまとめる．次に具体的なアルゴリズムについて，そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する． GoのGCの今 最初にGoのGCの最近の流れ（2016年5月まで）をまとめる． Go1.4までは単純なStop The World（STW）GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された．導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった．Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた． 以下は公開されているベンチマーク．まずはGo1.5を見る． Gophe
Goのガーベジコレクタを視覚化するツール | POSTD
（環境変数GODEBUGは、 ランタイム パッケージで提供されています） この環境変数を指定してプログラムを起動すると、標準出力に以下の追加出力が出力されます（少し簡略化されています）。 % env GODEBUG=gctrace=1 godoc -http=:6060 ... gc76(1): 2+1+1390+1 us, 1 -> 3 MB, 16397 (1015746-999349) objects, 1436/1/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields gc77(1): 2+0+1582+1 us, 2 -> 4 MB, 14623 (1016248-1001625) objects, 1436/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields scvg0: inuse:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://go-talks.appspot.com/github.com/davecheney/high-performance-go-workshop/high-performance-go-workshop.slide
GoogleのGoが高速化