プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生：DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム
Lispの車窓から見た人工知能 - dely engineering blog
はじめに こんにちは。 機械学習エンジニアの辻です。 本記事はdely Advent Calendar 2018の22日目の記事です。 dely Advent Calendar 2018 - Adventar dely Advent Calendar 2018 - Qiita 昨日は弊社のサーバサイド・エンジニアの山野井が「【Vue.js】算出プロパティの仕組みについて調べてみた」という記事を書きました！ とてもわかり易く解説しているので興味のある方は是非読んでみてください。 tech.dely.jp さて本日は「Lispの車窓から見た人工知能」と題しまして、プログラミング言語Lispから見た人工知能の風景を眺めていきたいと思っています。ぼくはEmacs使いのLisperですが、Lispを書くのは自分用のスクリプトや、Emacs Lispの設定変更といったものだけで、ふだんの機械学習に関す
CPython の GC チューニング - methaneのブログ
ISUCON は Go で参戦しているんだけど、複数のチームが Python で予選通過したらしいので、応援のために Tips を公開していこうと思う。 目次 CPython の GC について 統計情報を出力する 第一世代GCの間隔を調整する Out of Band GC 循環参照を見つけて対処する CPython の GC について CPython のGCは参照カウント＋循環参照コレクタだ。そして参照カウント方式は(幾つかの欠点はあるものの)Webアプリのボトルネックになったりはしにくい。 なのでGCチューニングの基本は次のようになる。 循環参照を避ける 循環参照コレクタの呼び出しタイミングを制御する 循環参照コレクタは、生きているオブジェクトの数がある程度増えると第一世代が実行され、第一世代が一定回数実行されると第二世代が、第二世代が一定回数実行されると第三世代が実行される。 各世代
RubyとPythonの違いからガベージコレクタを理解する - ワザノバ | wazanova.jp
http://patshaughnessy.net/2013/10/24/visualizing-garbage-collection-in-ruby-and-python Pat Shaughnessyが、ブタペストで開催されたRUPY2013でのプレゼンの前半を自らのブログで紹介しています。 ガベージコレクタは、「ゴミを集める」という行為だけでなく、「新しいオブジェクトのためにメモリをあてがう。」「不要なオブジェクトを見つける」「不要なオブジェクトからメモリを取り戻す。」という、人間の心臓が血液を浄化するような働きをしている。 この簡単なコードサンプルを見ると、RubyとPythonの記述はよく似ているが、それぞれの言語の内部でのインプリの仕組みは違う。 1) Rubyのメモリ Rubyは、コードが実行される前に、数千のオブジェクトを先につくり、それをリンクされたfree listに置
__del__, gc, 循環参照, weakref
2010年11月22日公開 Python の __del__ メソッド、ガベージコレクタ、循環参照、そして弱参照についての解説と考察。 参照カウンタ __del__ __del__ の落とし穴 循環参照 __del__ の落とし穴 考察 __del__ を使わない 循環参照を確実に避けることはできる？ 弱参照 weakref モジュールを利用したハック いったいいつ __del__ を使うのか 参考文献 事項 参照カウンタ C/C++ では、malloc を使って確保したメモリや new で作成したオブジェクトについては、必ず対応する free / delete を呼ばなければならない。これを忘れるといつまでも解放されないメモリがプログラムの生存期間中居残ることになる。これをメモリリークと呼ぶ。メモリリークがあると、確保されたままになったメモリが OS や他のプロセスを圧迫して、システム全
PyPy における Python のパフォーマンスチューニング
これは PyPy Advent Calendar の記事です。PyPyのコアディベロッパーである "Maciej Fijalkowski" 氏のブログ "Analysing python's performance under PyPy" の抄訳+αです。 Python の一般的なパフォーマン解析のモデルは、"プロファイラを実行して、ボトルネックを探し出し、それを最適化するか C で書き直す" ことです。しかし PyPy ではこのアプローチだけでは不十分です。なぜなら、 多くの大規模アプリケーションで、プロファイラはフラットです: PyPy のトランスレーションツールチェーン、Twisted、モダンな Web サーバ等が良い例です ボトルネックを発見したとしても、それが特定の関数内でのみ遅いのか、複数の関数が関係しているのか明確になるわけではありません。どうすれば遅くて、どうすれば速くなる
メソッドオブジェクトの不思議とid()の落とし穴 - atsuoishimoto's diary
さて、@aroma_blackさんがこんなスクリプトで悩んでおられたのである。 class C(object): def foo(self): pass c = C() print id(c.foo) == id(c.__class__.foo) print c.foo is c.__class__.foo @aroma_blackさんはメソッドオブジェクトがどこに隠れているのか調べていたようだ。この二つのprint文で出力される結果はおわかりだろうか。 c.foo is c.__class__.foo まず、二番目のprint文から見てみよう。 c.fooは見た通り、Cクラスのインスタンス c からメソッド foo を取得する式である。 >>> c.foo <bound method C.foo of <__main__.C object at 0x02A8B3B0>> c.fooでは、
Pythonの粗大ゴミ - atsuoishimoto's diary
なんかgcネタが続いてしまうが、先日のPython Hack-a-thon で発表した中で、「ジェネレータオブジェクトが解放されない場合がある」というのは、あまり知られていないようだ。Python公式ドキュメントを確認してみると、どうやらこちらにも書かれていない。知らないとハマってしまう場合もあるので、もうちょっと詳しく解説しておこう。 ガベージコレクションで解放されないオブジェクト まず、ちょっと復習しておこう。Pythonのガベージコレクション機構では、__del__() メソッドを持ったオブジェクトで循環参照を作ってしまうと、そのオブジェクトは自動的には解放されなくなってしまう。 例えば、次のように __del__() メソッドを持つクラスを定義する。 class UnCollectable: "__del__()メソッド付きクラス" def __del__(self): print
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.gembook.org/pep442.html