General-purpose Programming Language implemented with Go and LLVM. Presentation at Go Con Spring 2017
General-purpose Programming Language implemented with Go and LLVM. Presentation at Go Con Spring 2017
はじめに LLVMは、コンパイラを作成するための基盤です。2000年にChris Lattnerによって作成され、2003年にリリースされました。それ以来、LLVMリンカ lld やLLVMデバッガ lldb など幅広いツール群を持つ包括的なプロジェクトに発展してきました。 LLVMの秀でた特徴は、一般に LLVM IR と呼ばれる、その中間表現です。LLVMの考え方は、まずこのIRにコンパイルし、次にそのIRを、JITコンパイルする、インタープリタで実行する、または実行しているマシンのネイティブアセンブリにコンパイルするといういうものです。このIRの主なターゲットは、コンパイラです。実際LLVMを使用するコンパイラは、世の中に数多くあります。C言語とC++用はそれぞれclangとclang++、D言語用の ldc2 、Rust、Swiftなどです。 Emscripten のようなプロジェ
この記事は Slack Advent Calendar 2016 - Qiita の3日目の記事です。 昨日は Kinoppyd さんの「今そこにあるSlack」でした。 さて、今回、この記事では golang で Slack bot を実装する方法を紹介しようと思います。 世に蔓延る Slack bot これから bot を世に放とうとしている人は、是非、1日目と2日目の記事を読み、事前知識を頭に叩き込んでおくと良いと思います。 Slackで業務チャンネルの平穏を維持するbot、そして人間のトークンをbotに与える話 - Qiita 今そこにあるSlack 基本的に、自身で作成した bot はもちろん好きになると思いますが、人によっては理解不能な bot や、意味不明な場面で反応したりと、「邪魔だな」と思われてしまうことがあります。そのため、bot を開発する人は「謙虚・尊敬・信頼」(T
先日、Go言語バージョン1.1がリリースされました。安定しているのは勿論、幾つか新機能が追加されましたが、何よりもパフォーマンスチューニングが施された一番嬉しいですね。 Go 1.1 performance improvements | Dave Cheney This is the first in a series of articles analysing the performance improvements in the Go 1.1 relea... http://dave.cheney.net/2013/05/21/go-11-performance-improvements さて今日はVimを使ってGo言語を開発する方法を紹介したいと思います。 VimでGo言語を開発するには、Go言語のリポジトリに含まれる misc/vim にランタイムパスを追加します。以下を vimr
Steve Francia, for the Go team 6 March 2017 Thank you This post summarizes the result of our December 2016 user survey along with our commentary and insights. We are grateful to everyone who provided their feedback through the survey to help shape the future of Go. Programming background Of the 3,595 survey respondents, 89% said they program in Go at work or outside of work, with 39% using Go both
Summary of Go Generics Discussions frozen document Motivation Overview Problems Generic Data Structures Generic Algorithms Functional Code Domain Modeling Language Extensions Alternatives Re-implement the code / copy-paste Use interfaces Use reflect Code generation Generics approaches Built-in generics Type specialization Implicit boxing Package templates Type alias rebinding Mix boxing and specia
元ネタはずいぶんと昔の記事なのだけど。 編集距離 (Levenshtein Distance) - naoyaのはてなダイアリー ■ 編集距離 (Levenshtein Distance) 昨日 最長共通部分列問題 (LCS) について触れました。ついでなので編集距離のアルゴリズムについても整理してみます。 編集距離 (レーベン... http://d.hatena.ne.jp/naoya/20090329/1238307757 思い付きはまったく関係ない所から。 mp3 が数千ファイル入ってるフォルダで何かの手違いで同じ曲が入ってしまう事が結構あって重複取り去る作業してた。ID3が違ってるとMD5も違うのでレーベンシュタインの文字列距離を使ってファイル名が似てるの調べたら422ファイル消せる事が分かった。 — Vim芸人 (@mattn_jp) February 25, 2017 これを
Overview Intro GopherCon 2016 Video Before Starting Find Devices Open Device for Live Capture Write Pcap File Open Pcap File Setting Filters Decoding Packet Layers Creating and Sending Packets More on Creating/Decoding Packets Custom Layers Decoding Packets Faster TCP Stream Reassembly Additional References UPDATE: My book, Security with Go, is now published. If you found this page helpful you sho
Russ Cox, July 2011; updated by Shenghou Ma, May 2013 24 June 2011 At Scala Days 2011, Robert Hundt presented a paper titled Loop Recognition in C++/Java/Go/Scala. The paper implemented a specific loop finding algorithm, such as you might use in a flow analysis pass of a compiler, in C++, Go, Java, Scala, and then used those programs to draw conclusions about typical performance concerns in these
There are plenty of guides for profiling Golang, just writing this here so I can find it again easily ☺ The runtime/pprof package offers lower level control over creating profiles, and the very cool net/http/pprof package registers HTTP end-points for profiling live applications, this is a really slick feature. To simplify things even further Dave Cheney created github.com/davecheney/profile, all
GoCon 2013 Autumn で「Go言語のスタックとヒープ」という発表をしました。 資料はこちら: http://goo.gl/s6at62 スライドだけでは分かりにくい部分もあるので、ブロク記事として以下にも記しておきます。(この記事を読めば、スライドは読まなくてOKなはず) スタックとヒープについて 実行時に動的にメモリを確保する領域として、スタックとヒープがある。 スタックメモリは関数のコールスタックを格納していて、ローカル変数、引数、戻り値もここに置かれる。 スタックのPushとPopは高速なので、オブジェクトをスタックメモリに確保するコストは小さい。ただし関数を抜けてスタックがPopされると解放されるので、関数の寿命を超えてオブジェクトは生存できない。 一方のヒープメモリは、コールスタックとは関係ないので、関数スコープに縛られずにオブジェクトを確保しておける。ただし空き領
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
Introduction Go is a new language. Although it borrows ideas from existing languages, it has unusual properties that make effective Go programs different in character from programs written in its relatives. A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go. On the other hand, thinking about the prob
I'm experiencing a bit of cognitive dissonance between C-style stack-based programming, where automatic variables live on the stack and allocated memory lives on the heap, and Python-style stack-based-programming, where the only thing that lives on the stack are references/pointers to objects on the heap. As far as I can tell, the two following functions give the same output: func myFunction() (*M
最近、Go言語にいろんな意味ではまっているので、調べたメモpart2。 前回のやつは色々と中途半端で間違っていたので、書き直し+go 1.2開発版 (go version devel +f1545db4a9c4)で実験。 最終版ではないので、今後もぼちぼち修正+更新するかもしれません。 Introduction Go言語の特徴として、スタック領域とヒープ領域を区別しないという特徴がある。 そのため、C言語初心者がやるような、こんなプログラムを書いてもよい。 package main import "fmt" func main() { var a1 *int = call1() fmt.Printf("value = %d", *a1) } func call1() *int { var b1 int = 10 return &b1 } とはいえこれは、プログラマが明示的には区別しないとい
Introducing Go-Pipeline The title may be a bit grandiose, but after playing around with a concept of “channel-middleware”, much back and forth, and polishing of the idea, we can now introduce Go-Pipeline as an open-source library. “Great!” I can hear you say, “but what is Go-Pipeline?” Go-Pipeline simply provides some assisting interfaces and helper methods for writing go code that relies heavily
2016-06-12 なぜ書いたか 仕事で複数のサーバで同じ処理を実行して結果を集めたいというニーズがあって、各サーバをgRPCのサーバにするという実装でとりあえず実現していました。でも、出来れば処理を実行するワーカーサーバから制御サーバに接続して繋ぎっぱなしにしておいて、制御サーバからジョブを送り込む方式にしたいなーと思っていて、家で実装を進めていました。 これまでに試したこと gRPCにBidirectional streaming RPCというのがあったので、hnakamur/grpc_notification_experimentで試してみたのですが、複数クライアントがサーバに接続した状態で、サーバからクライアントにジョブを投げても、1つのクライアントでしか処理が実行されないということがわかりました。 次に、ワーカーサーバから制御サーバにTCPのソケットで接続しておいて、制御サーバ
Go For Perl Mongers (or, for Lightweight Language lovers) Daisuke Maki Engineer, LINE Corporation Who Is This Guy? @lestrrat LINE / Japan Perl Association / YAPC::Asia (2008~2013) STF / peco (new!) 2 俺とGo Goしてみて約1年弱 概算10~12万行くらい書いた。lived○○rBl○g の裏方にもこっそりgo入れてる 最初の4万行くらいまでに goの落とし穴にほぼ全て落ちた 自信がある 今日はその落とし穴から学んだ諸々の話 3 対象観客層 もともとPerl/Python/Ruby/PHPあたりから来た人 Goは最低限とりあえずかじった程度はやった人 かじってみたけど「Go、便利そうだけどなん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く