2006-03-18

_ An Open Source Tax Credit

オープンソースに寄与した人は税制上の優遇措置(控除)が受けられるようにしようという話。 前にも似たようなのを見た気もしますが。

ヨーロッパだと開発者の多くは学生(=無収入)なので、 どの程度の意味があるかは謎ですけど、 あったらいいですねえ。 この記事はUS向けですが、 フランスとか日本でもこういう動きがあっていいと思います。

_ スクリプト言語はコンパイラ言語より遅いのか?!

とある学生と話していて感じたこと。 彼はC、C++、Java等の経験しか今までありませんでした。 最近Pythonをかじり始めましたが、 彼は「Pythonはスクリプト言語だから遅い」と主張しました。 私は猛然と否を唱えました。

そもそもどっかの誰かが主張していることを自分で確認しないで信じている時点でアレなんですけど、 あまりに見方が単純過ぎるというのが私の観点。

私の主張を要約すると、

  • コンパイラは所詮線形にしか高速化しない(ベクトル化してくれるとか、そういうのは置いといて)。
  • いくら言語の平均的実効速度が高速でも、アルゴリズムが間抜けだと、スクリプト言語で賢く書いた方が速い(これは簡単に証明できる)。
  • 概してコンパイラ言語(特にC)は機能が貧弱なので、まともなプログラムの規模になると、非常に開発効率が悪い。
  • 開発効率は実行効率に間接的に影響を及ぼす。プログラムを改善するスピードが異なるならば、当然開発効率の優れた言語の方が速いプログラムを生み出しやすい。
  • 現実問題、この世界の移り変わりは非常に速いのだから、開発時間がそもそも短い。
  • よって、開発効率の良いスクリプト言語の方がコンパイラ言語より実行速度においても優れている可能性は決して無視できない。

理論的に速いからといって、現実にも速いとは限らないんですよね。 書きにくい言語できれいなプログラムは簡単にはできないですから。

まあ、それは別にしても、Pythonには pypy なんて試みもありますし、 将来本当にスクリプト言語の方が決定的に速いという状況が生まれる可能性も否定できないと考えています。

追記: shiroさんのコメント について。 おっしゃることは全くその通りです。 議論した相手が相手だったので、 言葉の定義は適当です。 ここでは一般的に「そういう言語だと捉えられているもの」ぐらいに考えていただいた方が良いです。 もう少し厳密にするならば、動的言語、静的言語といった呼称の方が似合っているかもしれません。

境界の曖昧さは私は以前から認識しています(というか、境界の明確な言葉の定義の方が稀じゃないかな)。 実際Cで書いたからといって、 全てコンパイル時に決定されるわけではありませんし。 単純なプログラムでさえ今日では動的リンクなど、インタープリタ的動作が介在しますし、 結局多くのインタープリタはCで書かれています。 JavaやPythonのようにJITをサポートしている言語もあれば、 CommonLispやHaskellのように両対応している言語も存在します。 結局はどこまで動的にやるのかという問題でしょう。

psycoやpypyのように、とりあえずインタープリットしていって、 (やる価値のありそうなところを)実行時情報に基づいて複数バージョンをコンパイルしていくというアプローチは面白いと感じています。 ただ、GCCなんかは最近プロファイルによる最適化や関数を跨いだ最適化なんかをサポートしているので、 コンパイルに膨大な時間を費しても文句を言われない言語の方がより強力な最適化を施しやすく、 そう簡単には勝てないだろうなと思います。

まあ、いずれにしても「開発効率こそが重要である(場面も多々ある)」という私の主張には影響しないんですけどね。

本日のツッコミ(全13件) [ツッコミを入れる]
_ shiro (2006-03-19 06:25)

「スクリプト言語」と「コンパイル言語」の境界は無くなってゆくんではないか、と予想。その場でコンパイルすればいいだけですから。<br><br>Lispならとうの昔に境界は無いわけですけど。

_ shiro (2006-03-19 22:21)

あー、私も賛成という立場で、おくじさんの尻馬にのってちょっと語っただけですんで。<br><br>「開発効率が実行効率に影響を及ぼす」というのは現場で何度も経験しています。このことはもっと強調されて良いと思いますね。

_ okuji (2006-03-20 00:47)

私もshiroさんに反対しているわけじゃないんで。何というか、世の中ではスクリプト言語の方が開発効率が高いという考え方が普及してきた一方で、実行効率は別物という信念に支配されている印象を受けるんですよね。結局は本物のアプリケーションの性能を見せつけることでしか克服できないんでしょうけど。

_ takano32 (2006-03-20 03:31)

いきなり議論の質を落としてしまいそうで恐縮ですが,プログラムの性質によっては,スクリプト言語であるか,ということよりもGCの効率が実行効率に大きく影響していると思います.<br>その点,Pythonはうまく処理しているようで,ゲームなどのリアルタイム性が必要なものにも多く使われているみたいですね.

_ あらいしゅんいち (2006-03-26 22:36)

アプリケーションによるので一概に議論するのは難しいですね。大量のメモリアクセスを行うリアルタイムソフトウェアは未だにC++ with アセンブラを使うこともあります。<br><br>重要なのはインタプリタ(VM含む)対コンパイラということではなく、その言語がなんのためにデザインされているかということだとおもいます。<br><br>Cはアセンブラのように直接に機械リソースを扱うものなので、プロが使えば速くなるのは当然ともいえます。しかし学生の書いたCのコードを使う気にはなれませんし。<br><br>逆に言うと、アセンブラレベルでの高速化とかは恐ろしいほど効いてくることがあるので、アルゴリズムを工夫するよりも開発効率が良い場合もありえます。<br><br>やはり使い分け重要です。

_ shiro (2006-03-27 04:35)

あらいさん:「アセンブラレベルでの高速化とかは恐ろしいほど効いてくることがあるので、アルゴリズムを工夫するよりも開発効率が良い場合もありえます。」<br><br>考えていることが違うかもしれませんが、「恐ろしいほど」というのはどのくらいでしょうか。私の経験だと、アルゴリズムによる高速化というのは10^2〜10^3以上のオーダーで効いてくることがあるのに対し、アセンブラレベルでの高速化は10^1以下のオーダーであることが多いです。ストリーム命令を利用できたり、inner loopでのキャッシュラインの最適化が出来れば数十倍くらいはいけるのかなという気もしますが、まだそこまで追求したことはありません。<br><br>あとLispで書いていても、最適化してゆくときは普通にdisassembleして吐き出されるアセンブラコードを睨みながら開発します。ですので言語よりは環境かなという気もします。

_ okuji (2006-03-30 01:25)

経験的にはグラフィックス関係とかだと、部分的にアセンブラで書くと異常に効果があったりしますね。アセンブラとまで行かなくても、メモリ使用量の多いプログラムだと、低レベルな言語の方がキャッシュ最適化をやりやすい分、相当速度を稼げるのはあらいさんのおっしゃる通りです。<br><br>しかし結局みなさんの言っていることが本質的には同じなので、少々拍子抜けしましたよ。もうちょっと「コンパイラ型の方が速いに決まっている!」みたいな反論を期待してたんですけど。将来がどうなるかは私にはよく分かりませんが、「スクリプト + JIT + カリカリにチューニングしたい部分だけ低レベル言語でモジュール書き直し」みたいなので落ち着いていくんじゃないですかねー。

_ あらいしゅんいち (2006-04-07 18:23)

shiroさんこんにちは。もちろんアルゴリズムを改善するのはアセンブラによる最適化より強力ですが、なかなか難しく、いつでも誰にでもできるものでもないとおもいます。わたしは数学がよわいので、どうも苦手です。<br>アセンブラによる最適化はたいしたことないと思われがちですが、信号処理のような大量のデータを扱う分野では数十倍〜数百倍程度の高速化は可能であるとおもっています。

_ とおりすがり (2006-10-11 23:37)

>そもそもどっかの誰かが主張していることを自分で確認しないで<br>>信じている時点でアレなんですけど、あまりに見方が単純過ぎ<br>>るというのが私の観点。<br><br>あなたも同じことを言ってますよ。

_ とおりすがり (2006-10-12 00:08)

JAVAで最上のアルゴリズムで組んだ場合と、Pythonでの最上のアルゴリズムで組んだ場合の実行速度は比較されましたか?<br><br>また、コンパイル言語でも扱える技術者が多ければ、それだけサンプルコードや信頼性のあるフリーのライブラリが多く公開されていますので、それらを利用することにより開発効率は格段と良くなります。慣れの問題であったりもします。<br><br>スクリプト言語だからとか、コンパイル言語だからとかは開発効率には関係ありません。もっと外的条件により左右されます。<br>比較するするには条件が少なすぎます。時と場合によりけりです。<br><br><br>ちなみに、一般企業では、信頼性と、技術者数(代要員の有無)、将来性、生産性、実績、などのバランスを考えて言語などを決定します。

_ 通りすがり (2007-04-26 21:42)

既にだいぶ時間が経っていますが。<br><br>実行速度の違いを比較したいのか、開発効率を比較したいのか、<br>話がまざっている気がします。<br>前者の場合には、コンパイラとインタプリタの比較をしたいのか、<br>言語間で実行環境の比較をしたいのか、も。<br><br># 仮にコンパイラとインタプリタの比較をしたい場合には、<br># 同じ言語で書いた同じプログラムをコンパイルした場合と<br># インタプリタで実行した場合で比較しなければ無意味でしょう。<br><br>> いくら言語の平均的実効速度が高速でも、アルゴリズムが間抜けだと、<br>> スクリプト言語で賢く書いた方が速い(これは簡単に証明できる)。<br><br>アルゴリズムが違う時点で、言語間の比較にも<br>コンパイルの有無による比較にもならないので、ナンセンスです。<br>(少なくとも「Pythonは遅い」という主張に対する答えとしては)<br><br>仮に同じアルゴリズムで書けないなら、<br>言語を使いこなせていないだけでしょう。

_ ん? (2007-04-26 23:07)

求められる機能に対して開発時間が非常に少ない、と言う前提のもとでは、python,rubyのようにとにかく動くものを早く形にできる言語の方が、その後の性能改善の期間も取れるので、結果的に性能が出せる場合もあるのでは?、という話だと思います。<br>C,アセンブラで十分に設計、実装、評価のできる期間、予算、人材があるのであれば、コンパイル言語の方が早いのは当然だと思います。

_ 高野光弘(takano32)君の32nd Diaryについて (2008-08-22 03:40)

takano32,TAKANO Mitsuhiroこと高野光弘(26歳、日立製作所エンタープライズサーバ事業部、日本UNIXユーザ会、日本Rubyの会)が、自身の『32nd diary』で公然と日立の機密を漏示し、障害者差別発言、さらに殺人予告までしています。 <br> <br>2007-08-22 14:24:35 ついに職場で人が倒れた。担架で運ばれていった。みな、ほんとうに死んだ魚を見ているようだった。管理者は苦笑している。 <br>2007-10-26 09:18:30 たまに社内のファイルサーバが重くなりすぎる。社内Winnyネットワークでも作りゃいいんだよ!! <br>2007-11-13 09:45:20 そういや、配属元の上司はほんとにバカでISO9001で不要な文書をポリシー化しているだけなのに、それをISO9001のせいにしていた。しかも、ISMSとか話題にしたら「なにそれ?うちの会社は情報漏えい気をつけてるから大丈夫」だってさ。死んだほうがいいよ。ほんと。 <br>2007-12-06 06:57:37 起きている。今日の目覚めは最低だ。いつ会社にエンジニアとして殺されるのか、そして、いつその波によって殺されるということがありうるのか。他人が聞いたら信じられないような話だろうがボクは恐怖している。 <br>2007-12-14 17:29:51 社内システムが無駄に Ajax するようになった。作れない Permalink があることに気づけよ! <br>2007-12-19 16:40:32 この会社の拡販の部署はクソ。身をもって知った。客層広げることをまったく考えてないんだな。 <br>2007-12-28 09:26:38 社内システムクソうんこ。 Ajax とか生半可にかじりはじめて、 Query を Cookie で渡すような仕組みになっている。検索条件を指定済みのブックマークとか作れねえじゃんかよ。うんこ改悪すんな。うんこ。 <br>2008-01-11 07:45:05 社内でPathtraq使いたいが、真面目に情報漏洩の可能性があるので困る。とりあえず、思いとどまっておこう。 <br>2008-01-22 06:29:23 昨日の課長は「デモ環境作成にあたり、ついでにバグ出しもできる」という考えにもあきれたが、机をバシバシ叩きながら話すという威圧的な行動に閉口だったなぁ・・・合理的かつ理論的に会話する人間が少ない。 <br>2008-01-28 13:45:00 内部で rlog がこけてる、とか思ったら、 author が数字なんですけど・・・これじゃ名前として認識されないだろ・・・この会社バカだなぁ・・・ほんとに。 <br>2008-01-30 23:56:19 今日の仕事は非常識な言動の上司に腹が立った。「自分で考えないならそこらへんのお姉ちゃん雇った方がいいじゃん」とかいうわけよ。なんだこいつ、と、放置決め込んだんだが、オレに分かんないことを質問してくるわけよ。なんなの、こいつは。こいつの代わりにお姉ちゃん雇いたいわ。マジで。 <br>2008-01-31 08:58:22 ちなみに、朝言ってたクソは異動になる。ブラフばっかでむかついてたんで清々する。しかし、ダメなやつの巣窟だなぁ・・・ほんとに進路を間違ったわ・・・ <br>2008-02-18 12:28:46 今の会社うんこすぎる。社会人として以前に人としてブラフはきまくり&いうこと聞かないやつたたいたら俺が社会人としてどうなのよ?と疑われた。なんつーヒエラルキー重視の北朝鮮。ほかの企業経験してないだろ? <br>2008-02-19 19:15:02 ってか、課長居眠りこきすぎだっつーの・・・・なのこのムカムカは。 <br>2008-05-26 20:00:58 自分のやりたいことを就業時間中にやると給料泥棒とかうんぬん言われた。技術泥棒のくせになに言ってんだよ。どんどん機会が奪われていく。胸糞が悪い。 <br>2008-05-27 22:36:35 きゅうりょうどろぼうはきょうもよるおそくまでおしごとしてこれからかえるのでした。心バキバキ川田くん。 <br>2008-05-28 04:23:33 三時間で目が覚めた。自分にとってはクビが飛ぶくらいなんでもねぇ、一言入れれば明日にでも雇ってくれるところは複数あるもんね、と思っていたが、心のそこがバキバキなんだめう。人事は恐ろしい。ちょっと寝なおす。 <br>2008-05-28 08:20:01 社内から技術者以外に見られるとうざいと思って access deny にしていたが、開放した。一度、一騎打ちしようと思う。たぶん、そのひとりが変な考え持ってるので。←誹謗中傷ではない <br>2008-05-29 09:11:59 何度言ってもわかんねーようだなぁ。オレなんかが個人で発信する情報よりウィニー(笑)で漏洩する情報を先にどうにかするのがさきなんじゃないの? <br>2008-05-30 07:17:00 しっかし、会社はやり方にいらつく。誰からの制裁かわかんない。てめぇのメールアドレスでスプーフィングして、全社員にメール送るスクリプトでも組んでやろうか、という気分。まぁ、マジにやるつもりはないけど、あんまなめてるとやりかねませんよ、と。   2008-05-31 22:33:30 んで、キチガイがいる *.tokyo.ocn.ne.jp を解禁したいのだが、いつぐらいにしたらいいのか迷う。あのキチガイはもう他のところにポインタ向いたかね? <br>2008-6-14 予告 心バキバキ川田くんを殺します。 <br>2008-6-15 日本の警察をみた。いつも行動力がないと言われている日本の警察ですが、今日は変な行動力をみた。 理不尽で半端な行動力なので、もう少しガイドラインを固めないとダメだと思った(現場の人は悪くないので、上がきちんとしろ、という意味)。 予告.in 予告.out 事情を話し、くだんの書き込み元IPアドレスなどを回答した。 <br> <br>理不尽なのは、「殺します」、「死んだほうがいいよ」、「クソ」、「うんこ」、「バカ」、「キチガイ」という発言の方なのではないでしょうか? <br> <br>高野光弘君の発言をどうお考えでしょうか?

[]

トップ «前の日記(2006-02-28) 最新 次の日記(2006-04-01)»