Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
The Leading Platform for Development Acceleration Deliver faster dev cycles and time‑to‑market, with more compute power and less cost on‑prem and in the cloud. Get StartedWatch a Demo Development never stopsIncredibuild enables every machine to use hundreds of cores to accelerate time-consuming software development by using idle CPUs in network or bursting to the cloud. Use the full potential of y
はじめに 今回は、メモリアロケーションに関して、Java・C#などプログラミング言語やUnity・UDKなどのゲームエンジンにおいてはメモリの事なんて全然気にしなくていい時代になっている(!?)中、ゲーム開発におけるメモリアロケーションについて、えーでるわいすで現在使われているゲームエンジンでの実装も踏まえて一回まとめてみようかと。。。 発端は、@aizen76さんの「カスタムメモリマネージャと高速なメモリアロケータについて」というスライドを偶然見つけたのがきっかけで、自分は今まで深く理解せず何となくでやってきてしまっていた気がしたのでちょっとまとめて見ようと思い立った感じです。 対象 C++初級者~中級者ぐらい ※ ガベコレだのスマートポインタだのmallocの実装によるマルチスレッド環境下での速度がどうとかその辺の話は止まらなくなるので我慢します( ´∀`) メモリアロケーションって何
なんだってー!!!!(;゚д゚) (゚д゚;(゚д゚;) いや、過言かもしれませんが、C++の存在がdlmallocを書く切っ掛けになったのは確かです。 dlmallocは現在はLinuxなどのデフォルトのmalloc実装ではありませんが、 dlmallocは本当に優れたアルゴリズムを持っています。 まずは「はじめに」の日本語訳を引用として載せておきます。(この記事自体は非常に古いもので現在のmallocの実装の詳細を反映してはいませんが、今なお使うに値するアロケータだと俺は信じますし、使っています) http://g.oswego.edu/dl/html/malloc.html はじめに メモリアロケータはソフトウェア工学のインフラにおける興味深いケーススタディを形成します。 私はそれを1987年に書き始めて以来、維持と発展に努めてきました。(これは多くのボランティアの方々の助けがあって
dlmalloc, tcmalloc, jemallocについて,以下の各記事を読めば各mallocのアルゴリズムはわかるはず. dlmalloc Linuxの一部やAndroidのDalvik VMで利用されている.シンプルながらうまく考えられている. チャンク(連続空き領域1つ)の境界と構造体の境界が違う所が罠. http://g.oswego.edu/dl/html/malloc.html http://mkosaki.blog46.fc2.com/blog-entry-241.html にわかりやすい講演資料が,と思ったら動画がprivateになってる… tcmalloc thread-caching malloc. Googleで利用されている. スレッドがキャッシュ持つのでfreeしてもメモリ利用量が減らない!のが罠. http://goog-perftools.sourcef
Golang勉強会 in Kagawa http://gdgshikoku.connpass.com/event/26262/
そこそこの大きさのソフトウェアを作った場合、メモリリークが問題になることがよくあります。(初期にメモリ管理についてしっかり設計し、エンジニアの合意を取れば、テストフェーズでメモリリークを気にすることはなくなるのかもしれませんが、残念ながらそのような素晴らしいプロジェクトを見たことがありません。) 普通の環境 (i386, amd64, ppc32, ppc64) ではValgrindを使ってメモリリークを検出するのが定石ですが、Valgrindが動かない環境ではどうしよう、という悩みがあります。 とりあえず、「glibcをdynamic linkして動作するアプリケーション」という仮定で、メモリリークの検出方法を考えました。この仮定はそんなに非現実的ではないはずです。 方針としては、愚直ですが、 malloc/freeをすべて記録し、対応するfreeが存在しないmallocを検出するとなり
penryn マシンでは oprofile が動作しないので、少し古めのマシンになってしまうが、Xeon 2.80GHz (L2 cache 1MB) を用いて測定してみた。 HugeTLB ファイルシステムへ全米で用いる 1GB のメモリに割り当てる際には、素早く終了する場合と、そうでない場合がある。特に、メモリ割り当てによりシステムが不安定になってしまうこともあるため、注意が必要であるといえる。 結果として、HugeTLB を用いると「ダイクストラ法を走らせるルーチン dijkstra_with_bucket()」でのTLB ミスが無くなった。その分、「クイックソートルーチン quicksort_by_tail() 」で TLB ミスが増えている。ページサイズが 2MB になったために、細かい単位で操作するクイックソートでは TLB ミスが多発してしまうのであろうか。 CPU : Xe
Linux x64環境において、ELF実行ファイル、共有ライブラリ、スタック領域、ヒープ領域のアドレスがどのように決まるのかについてのメモ。 環境 Ubuntu 12.04 LTS 64bit版 $ uname -a Linux vm-ubuntu64 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.4 LTS Release: 12.04 Codename: precise $ gcc --version gcc (Ubuntu/Linaro 4
最近のFedoraにはアプリケーションを自動的にHugetlbで動かしてスピードアップしてくれる、libhugetlbfsというパッケージがある。 という極秘情報をKAMEさんから入手して特派員は調査に向かった!! うーん、おいらが作ってたライブラリとそっくり! ・mallocの乗っ取りはglibc mallocの__morecoreシンボルを乗っ取っている。 ・mallocの乗っ取りはコンパイル済みのアプリにも有効 ・text/data/bssの乗っ取りはld という名前の独自スクリプトを用意して、リンカオプションに --hugetlbfs-link= という文字列が現れたら、libhugetlbfsが用意した独自リンカスクリプトを引数文字列に追加して本物のldをinvokeしている ・つまりtext/data/bssのhugetlbfs化は再コンパイルが必要 ・このリンカスクリプトでは
以前、 スワップがなく、かつ、overcommit が効かないので、いろいろ動かない。 apache 2 系の worker mpm とか標準設定だと起動時に 500MB 確保するので当然起動すらしない。 もう LD_PRELOAD で malloc を MAP_SHARED な mmap(2) にマップする共有ライブラリ作ろうかなぁ。なんという劣化再発明。 OpenVZ 系の VM の二重苦 - kazuhoのメモ置き場 と書いたわけですが、これを実現する morememory.so という共有ライブラリを作った (/platform/linux/morememory – CodeRepos::Share – Trac)。LD_PRELOAD なので、以下のような感じで、既存のプログラムを再コンパイルせずに使える。 % gcc -fPIC -Wall -g -O -shared more
5月23日、政府は、最新のIT技術を活用したフィンテックの普及を促すため、新たな目標を掲げる方向で調整に入った。連携する企業が銀行システムに接続可能となる対象先を2020年6月までに「80行以上」とする方針を打ち出す。写真は都内で2015年11月撮影(2017年 ロイター/Yuya Shino) [東京 23日 ロイター] - 政府は、最新のIT技術を活用したフィンテックの普及を促すため、新たな目標を掲げる方向で調整に入った。連携する企業が銀行システムに接続可能となる対象先を2020年6月までに「80行以上」とする方針を打ち出す。キャッシュレスでの決済比率を倍増させる目標も示し、官民一体で金融サービスの国際競争力を高めたい考え。
非常に興味深いお話でした。 古本を入手して読んでいるところですが、他の話も興味深く、人情味ある筆致が魅力的です。 絶版なのがもったいないですね…。 ※「お忍び」は違和感がある、というご指摘を複数受けたことを踏まえて、タイトルを若干変更致しました(文字数は変更なし)。 続きを読む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く