26日の米株式相場は反落し、ダウ工業株30種平均は前日比469ドル(1.0%)安の4万5960ドルで引けた。米国とイランの停戦交渉に関する不透明感が相場を冷やした。未成年のSNS依存を巡る米国の裁判で賠償命令が前日に下ったメタは8%安に急落。ナスダック総合株価指数は2025年10月の最高値から1割強下げて「調整相場」入りした。中東での戦況やトランプ米大統領のSNS投稿に応じて前提が日々覆され、
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
The State of Java: Trends And Data For One of the World’s Most Popular Programming Languagesの意訳記事です。 現代のソフトウェア産業は広大で、プログラミング言語の選択肢には事欠かきません。しかし、Javaエコシステムのような単一の技術スタックであっても、その市場について有益な結論を出すのは難しいことがあります。Javaは信じられないほどの成功を収めており、ほぼすべての主要な産業や経済部門で利用されていますが、このことがJavaエコシステムの状態について一つの断定的な視点を持つことを困難にしている部分もあります。 しかし、だからといって、世界の状況を評価できないわけではありません。 毎日、何千万ものJava仮想マシン(JVM)がNew Relicとデータを共有しています。このレポートを作成するにあたり
Rubyコミッター・笹田耕一に世代別インクリメンタルGCを発想したプロセスを聞いてみた Rubyのフルタイムコミッターである笹田耕一さんに、Rubyの処理性能を向上させるいくつかのブレイクスルーをどのように解決し、どのような困難があったのかを聞きました。 直感的な文法や生産性の高さから、世界中の人々に愛されるオブジェクト指向スクリプト言語Ruby。その黎明期から現在に至るまで、大きな変化を遂げてきた要素があります。“処理速度”です。数々の最適化が行われた結果、Rubyの処理性能はかつてとは比べものにならないほど向上しました。 その改善を支えたのは、世界中のRubyコミッターたち。中でも、性能向上において多くの成果を残してきたのが、クックパッド株式会社でフルタイムRubyコミッターとして働く笹田耕一(ささだ・こういち/ @koichisasada )さんです。本稿では、彼がいかなる設計方針に
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
一般的によく知られている SHA-256 や MD5 などのハッシュ関数は非常に単純な設計となっており、非力なパソコンや組み込み機器、スマフォなどでも高速に計算できます。 しかしながらその一方で、ハッシュ関数を手当たり次第に計算し、もとの入力値を復元するいわゆる「ブルートフォース攻撃」が容易であるというデメリットがあります。 特にこのような SHA-256 や MD5 といったハッシュ関数は、GPU を用いるか、もしくは専用のハードウェア (FPGA もしくは ASIC) を製作することで非常に高い効率で計算(攻撃)ができてしまうことが知られています。 そのため、GPU ないし専用ハードウェアを用いたとしても、攻撃効率の改善が難しくなるような新たなハッシュ関数がいくつか提案されています。 その中で比較的古く (2012年ごろ) に開発され、他のハッシュ関数にも影響を与えている「scrypt
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
ほとんどの開発者は、自動のガベージコレクション(GC)を当たり前のように使っています。これは、私たちの仕事を容易にするために言語ランタイムが提供する素晴らしい機能の1つです。 しかし、最新のガベージコレクタの中をのぞいてみれば、実際の仕組みは非常に理解しづらいことが分かります。実装の詳細が無数にあるため、それが何をしようとしているのか、また、それがとんでもなく間違った事態を引き起こしかねないことについて十分理解していない限り、すっかり混乱してしまうでしょう。 そこで、5種類のガベージコレクションアルゴリズムを持つおもちゃを作ってみました。小さいアニメーションはランタイムの動作から作成しました。もっと大きいアニメーションとそれを作成するコードは github.com/kenfox/gc-viz で見ることができます。単純なアニメーションによってこうした重要なアルゴリズムを明らかにできることは
Firefox web browser - Faster, more secure & customizable Firefoxユーザの最大の関心ごとのひとつが、Firefoxの消費するメモリ量の多さにある。メモリの消費という面で言えば、マルチプロセスアーキテクチャを採用しているChromeの方が消費量が多いと言われているが、Chromeではタブがプロセスに対応しているため、タブを閉じる(つまりプロセスを終了する)と、そのタブに関連して確保されていたメモリがちゃんと開放される。このため長時間使い続けても問題視されることが少ない。これに対してFirefoxが消費するメモリ量は使い続けるごとに増え、そしてタブを閉じても減らないことが多い。長時間Firefoxを使い続けると重くなると言われる原因はこれだ。しかし、この状況はFirefox 7から大きく好転することになりそうだ。 どのような改善が実
ちょっとOverlayfsの実装、読んでみました(A brief report of overlayfs source code reading)
iPhone開発で、メモリ管理の基礎を社員に伝えることが増えてきたので、エントリとして書こう。 Objective-C基礎 メモリ管理の前にObjCの基礎として、メソッド呼び出しの話。 クラスのインスタンスaがmethodAをコールするときは、 [a methodA] と書く。このとき、aがnilだったときは、エラーではなく、コールされない。methodAに戻り値があるときは、それは、0やnilやNOが返る。ObjCでは、 void dealloc { if(a!=nil){ [a release]; } [super dealloc]; } は、気持ち悪いので、nilチェックはやめましょう。 なお、ObjCでは、動的にメソッドを差し替えることができ、コールの度にメソッドが存在しているかも確認しています。そのため、LL言語(ライトウェイト言語、スクリプト)のように柔軟な記述が可能です。そし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く