アンテナ RSS OPML

すべて | グループ指定なし | Seasar

おとなりアンテナ | おすすめページ

  1. 2025/05/13 19:55:17 きしだのはてな含むアンテナおとなりページ

    2025-05-12
    古いコードを捨てて1から書き直したからこそ続いているソフトウェア
    Joel on SoftwareにNetScapeを例に、古いプログラムを捨てて1から書き直したくなるのは戦略ミスだって書いてあるけど、あのとき書き直してなかったら続いてないんではって思ったので、1から書き直して続いてるソフトウェアを挙げてみる。
    Firefox
    NetScapeからMozillaに移行するときに、新バージョンのリリースがなくなって、そこで致命的にシェアを落としたというのは確かにそうだと思う。
    けど、そこで書き換えていなかったら、2005年のAJAXから始まるWebアプリの高度化についていけなかったと思う。
    あそこで書き換えたからこそ、いまこの記事をFirefox上で書けてるんじゃなかろうか。
    Windows
    Windowsは、MS DOS上で動いていた3.1に継ぎ足すような形で32bit対応してWindows 95など続いていたけど、やはり無理が出ていて、ビジネス用にWindows NTを1から作り直していました。
    そして一般向けにもNTを使おうと計画してたけど開発が遅れてWindows 98をアップデートしたWindows MEが出たりして、それでもWindows XPからはNTベースになって今も続いています。
    macOS
    MacのOSは、古いMac OSを捨ててmacOS(当時はMac OS X)に置き換えられました。開発は遅れて、いつまでもリリースされなかったのを覚えてます。当初、次期OSとしてはCoplandの開発が進んでいましたが、いつまでもリリースされなかったのはコレ。結局Coplandはキャンセルされて、NeXTを買収し、OPENSTEPをベースにMac OS Xが開発されたのでした。(その意味では1から開発されたわけではなかったので失敗例かもしれない)
    それでUNIXベースになったからこそエンジニアの支持を得ているし、またそこでアーキテクチャが整理されたからiPhoneなどへの端末展開ができたんじゃないかと思います。
    はてなブログ
    いまこの記事が置かれてる はてなブログも古いコードを捨てて書き直されたサービスですね。
    はてなダイアリーから はてなブログへの移行期に、おそらくなんらかのビジネスチャンスを失ったとは思うけど、それでも、あのときに刷新してなかったら、gooブログなどサービス終了するブログたちに名前を連ねてたかもしれない。
    失敗例
    業務システムは定期的に更新されてるけど、最近は失敗が目立つようになってますね。今までも失敗はあったけど、影響がでかくなってるような。
    新システムに移行したらプリンが出荷できなくなったグリコ基幹システム。
    グリコ純利益43%減 24年12月期決算、基幹システム障害で「プッチンプリン」など出荷停止 - 日本経済新聞
    システム更新しようとしてたら隠れ仕様がたくさん出て来て訴訟問題になってるNHK受信料システム。
    IBM Japan Newsroom - お知らせ
    今、JavaはCで書かれているのだけど、JavaをJavaで書くというのは夢で、JavaバイトコードをネイティブコンパイルするコンパイラをJavaで書こうという話がありました。
    で、Cで書かれた今のC2コンパイラのメンテが難しすぎるので置き換えようということでJavaで書かれたGraalコンパイラが開発されたのだけど、C2を置き換えるには至りませんでしたね。
    とはいえ消えたわけじゃなく、GraalはGraalVMでネイティブコンパイルに使われていて、また標準化の流れも来ているけど。
    JEP 317: Experimental Java-Based JIT Compiler
    自社開発プロダクトは、移行失敗したら静かに消えていくので目立ちにくいんだろう。なんかあった気がするけど。
    まとめ
    Joel on Softwareには、移行のための3年というのはインターネットの世界では非常に長いと書かれていたけど、それから20年たって動きも落ち着いて、3年はそう長くないようにも見える。
    AIに関わらないプロダクトだと、3年のギャップはそこまで問題にならないんでは。逆にAIに関するプロダクトは3ヵ月の遅れが致命的になってる。
    ただ、見返してみると、FirefoxもWindowsもmacOSも、20世紀のコードを21世紀に入って捨てたもので、それ以降は安定して書き換えるという話になってないですね。
    はてなブログも、2012年くらいに稼働してると思うけど、それ以降はコードベースが古いという話になっていないです。
    企業システムも、メインフレームからオープンシステム、自前サーバーからクラウドのようなアーキテクチャ変更がモチベーションにあるように思います。
    インターネットの世界も落ち着いて、16bitから32bit、クラウドやスマホのような実行基盤の変更も起きないように見えるので、今後は新しい実行環境で動かすために1から書き直すということは減っていきそう。
    創業期につくったシステムが成長が一段落したときにユースケースが変わっているので作り変える、といったことはあるのかもしれないけど。
    例えばPerlで書かれている はてなブログをPerl以外で書き直すということは なさそうで、新しい機能をいれるときにマイクロサービスとして切り出して別言語で実装というふうになると思う。既存部分を置き換えるにしても、同様にマイクロサービスとして切り出して置き換えていく形になりそう。
    まあ、なんらか1から書き直す必然性は残るだろうけど、それは単にコードがダサいからとかではなく、今後の発展につながる形である必要があると思う。
    Joel on Software
    作者:ジョエル・スポルスキ
    オーム社
    Amazon
    nowokay 2025-05-12 22:40 読者になる
    もっと読む
    コメントを書く
    2025-05-11
    CPUが得意なことをCPUにまかせて少ないVRAMでも大きめのLLMを速く動かす
    Redditに「VRAM足りないとき一部のレイヤーをCPUに任せるんではなく、レイヤー全部をGPUに載せてレイヤー内部のFFNだけCPUに持っていったら速くなった、なんでこれが標準じゃないんだ」というのがあったので、おうちのRTX 4060 Ti 16GBで試してみたら微妙に速くなりました。
    https://www.reddit.com/r/LocalLLaMA/comments/1ki7tg7/dont_offload_gguf_layers_offload_tensors_200_gen/
    Qwen3 30B A3Bで試してみる
    こういった指定がOllamaやLM Studioではできないので、今回はKoboldCPPというので試してます。
    https://github.com/LostRuins/koboldcpp
    KoboldCPPでは実用が厳しいので、llama.cppで試すほうがよさそう。
    とりあえず、LM StudioでQwen3 30B A3Bのq3_k_xlを動かしたときは15.58tok/sec
    48中38レイヤーをGPUに割り当てています。
    ということで、koboldcppの実行。ダウンロードした実行ファイルに--overridetensorsと--modelと--gpulayersを指定して起動します。
    koboldcpp.exe --overridetensors "blk\.([0-9]*[05])\.ffn_.*_exps\.=CPU" --model "D:\dev\gguf\unsloth\Qwen3-30B-A3B-GGUF\Qwen3-30B-A3B-UD-Q3_K_XL.gguf" --gpulayers 48
    --overridetensors "blk\.([0-9]*[05])\.ffn_.*_exps\.=CPU"という指定が肝ですね。
    0と5で終わるffn内の層がCPUに乗ります。
    今回はRedditに書いてあった指定を使っているのだけど、層の名前を確認したいときは正規表現で.*を指定すれば全部CPUに乗るので確認できそう。
    http://localhost:5001にアクセスして「bertとgptの違いは」と聞いてみます。
    17.55tok/sec!12%速くなりましたね。
    メモリ消費はこのくらい。
    落としたときに2.2GB使っていたので、11.4GBほど消費してます。これはLM Studioで36レイヤー読み込んだときと同じ。
    Llama4 ScoutのQ2_KをLM Studioで16レイヤーをGPUにオフロードした場合とKoboldCPPで--overridetensors "blk\.([0-9]*[0124578])\.ffn_.*_exps\.=CPU"としてFFNだけ2/3ほどCPUに残した場合では、4.1tok/secだったのが4.9tok/secと20%速くなりました。
    ただ、思ったより効果がでてないのは、うちのCPUがちょっと弱いからではないかと。強いCPUならもっと効果が出ると思います。
    Qwen3 32Bで試したら性能向上できなかったけど、CPUが強ければそれなりに効果が出そう。
    何をやっているのか
    では何をやっているのか見るためにLLMの基本構造を確認してみましょう。
    いまのLLMはトランスフォーマという構造をベースにして、だいたいこんな感じになってる。位置エンコーディング(Posional Encoding)からFeed Forwardまでで一層で、 それがQwen 30B A3Bなら48層、Qwen 32Bなら64層という風になってる。
    で、LM Studioをはじめ、LLMの実行系の設定では、層単位でGPUにどれだけ乗せるか、逆にCPUにどれだけ残すかというのを設定するようになってる。
    でも、層全体で決めるんじゃなくて、層のなかの役割によってCPUでも効率化できるか、GPUじゃないとだめかって決まるんで、CPUでも効率化できるところはCPUに残して、GPUのメリットあるところはなるべくGPUに乗せたほうがいいんでは、って話ですね。
    なぜそれがいいのか
    じゃあなぜそれがいいのか、って見るのには、実際のコード見るのがいいと思います。
    ということで、llama2.cをJavaで書き直したやつをベースに。
    https://gist.github.com/kishida/05656bfcbe840f269784f7dbbee5928e
    LLMの処理を見るのはforwardメソッド。
    https://gist.github.com/kishida/05656bfcbe840f269784f7dbbee5928e#file-llama-java-L300
    まず後段になるFeedForwardを見てみます。今回CPUに乗せようというのはこの部分です。
    rmsnorm(s.xb, x, w.rms_ffn_weight[l], dim); // Now for FFN in PyTorch we have: self.w2(F.silu(self.w1(x)) * self.w3(x)) // first calculate self.w1(x) and self.w3(x) matmul(s.hb, s.xb, w.w1[l], dim, hidden_dim);
    matmul(s.hb2, s.xb, w.w3[l], dim, hidden_dim); // SwiGLU non-linearity for (int i = 0; i < hidden_dim; i++) { // 省略 } // final matmul to get the output of the ffn matmul(s.xb, s.hb, w.w2[l], hidden_dim, dim);
    SwiGLUのところは省略してますが1重ループです。rmsnormも1重ループになってます。1重ループは基本的に時間がかからないので、高速化の必要性も薄いです。
    あとはmatmulです。FFNの処理時間はmatmul部分にかかります。
    そのmatmulはこんな感じ。
    static void matmul(float[] xout, float[] x, FloatBuffer ws, int n, int d) {
    MemorySegment w = MemorySegment.ofBuffer(ws);
    IntStream.range(0, d).parallel().forEach(i -> {
    FloatVector val = FloatVector.zero(SPECIES); for (int j = 0; j < n; j+=SIMD_SIZE) {
    FloatVector a = FloatVector.fromMemorySegment(
    SPECIES, w, (i * n + j + SIMD_SIZE) * FLOAT_SIZE, ByteOrder.LITTLE_ENDIAN);
    FloatVector b = FloatVector.fromArray(SPECIES, x, j + 0*SIMD_SIZE);
    val = a.fma(b, val);
    }
    xout[i] = val.reduceLanes(VectorOperators.ADD);
    });
    }
    細かいところは置いておいて、IntStreamでparallelとしてマルチスレッド化してるところと、その中にループがあってFloatVectorを使ってAVXなどSIMD命令を使うようにしてることだけ見てください。
    つまり、スレッドを動かすコア数がそれなりにあってAVXのように1命令で複数のデータを処理できれば、CPUでも速く処理ができます。
    一方でマルチヘッドアテンションはこんな感じですね。
    // multihead attention. iterate over all heads final var fl = l;
    IntStream.range(0, p.n_heads).parallel().forEach(h -> { int qpos = h * head_size; int kvpos = h / kv_mul * head_size; float[] att = s.att[h]; for (int t = 0; t <= pos; t++) { float score = 0;
    FloatVector val = FloatVector.zero(SPECIES); for (int i = 0; i < head_size; i+=SIMD_SIZE) {
    FloatVector a = FloatVector.fromArray(SPECIES, s.q, qpos + i);
    FloatVector b = FloatVector.fromArray(SPECIES, s.key_cache[fl][t], kvpos + i);
    val = a.fma(b, val);
    }
    score = val.reduceLanes(VectorOperators.ADD);
    score /= head_aqrt; // save the score to the attention buffer att[t] = score;
    }
    ・・・
    IntStreamのparallelでマルチスレッド化して、内部にFloatVectorを使ったループがあるのはmatmulと似てるのだけど、FloatVectorを使ったループがループで囲まれて、全体で3重ループになってます。
    そして、真ん中のループは特にハードウェアでの高速化がされてないです。CPUだとこれを高速化する仕組みがない。
    Intel AMXとかあるけど4世代Xeonにようやく搭載されたところで、普及してない。使えるとLLMが速くなるようです。
    インテルの AI 対応 AMX CPU アクセラレータのテスト結果について | Google Cloud 公式ブログ
    一方でGPUだと3重ループを速くすることができます。
    GPU処理の共通フレームワークであるOpenCLの説明に次のように書いてます。
    解きたい問題には全て、直線状やキューブ状や平面状のようにある程度の次元性が存在している。 OpenCLでは最大3次元までを指定してカーネルを展開する。
    ここで、サッと3重ループをGPUで効率よく処理したソースが出せるといいんだけど、ディープラーニングをGPU使って速くしようとした処理では、ちゃんと3重ループの処理が書けてなくて高速化できてなかった。
    https://github.com/kishida/neuralnet/blob/use_jocl/src/main/resources/kernels/convolution_forward.cl#L15
    次のようにiのループとjのループもGPUの並列化に任せるようにすると速くなるはず。
    int fxy = get_global_id(0);
    int i = get_global_id(1);
    int j = get_global_id(2);
    [増補改訂]GPUを支える技術 ――超並列ハードウェアの快進撃[技術基礎] (WEB+DB PRESS plus)
    作者:Hisa Ando
    技術評論社
    Amazon
    nowokay 2025-05-11 23:31 読者になる
    もっと読む
    コメントを書く
    古いコードを捨てて1から書き直したからこそ続いているソフトウェア
    CPUが得意なことをCPUにまかせて少ないVRAMでも大きめのLLMを速く動かす

  2. 2024/12/25 02:18:44 初夏のはぶにっき含むアンテナおとなりページ

    ブログを開設した年のグループに入りましょう
    はてなブログには、同じ話題でつながる「グループ」があります。まずはブログを開設した年のグループに入りましょう。同時期に始めたブログとつながることができます。
    「2025年開設ブログ」のグループ

  3. 2024/03/27 23:24:08 taediumの日記含むアンテナおとなりページ

    taediumの日記
    読者になる

  4. 2024/03/25 20:22:54 たかのり日記 |S2とかAxis2とか|含むアンテナおとなりページ

    現場のためのソフトウェア開発プロセス - たかのり日記
    読者になる

  5. 2024/03/25 13:39:34 設計と実装の狭間で。含むアンテナおとなりページ

    設計と実装の狭間で。
    読者になる

  6. 2023/12/23 04:56:38 .Interface含むアンテナおとなりページ

    Rustでブロッキングキューを実装する

  7. 2023/02/15 22:51:45 t-wadaの日記含むアンテナおとなりページ

    ▼ ▶
    2013
    2013 / 12
    ▼ ▶
    2012
    2012 / 12
    ▼ ▶
    2011
    2011 / 12
    2011 / 8
    2011 / 7
    2011 / 6
    2011 / 3
    2011 / 1
    ▼ ▶
    2010
    2010 / 8
    2010 / 7
    2010 / 6
    2010 / 5
    2010 / 3
    2010 / 2
    ▼ ▶
    2009
    2009 / 12
    2009 / 9
    2009 / 7
    2009 / 6
    2009 / 4
    2009 / 3
    2009 / 2
    ▼ ▶
    2008
    2008 / 12
    2008 / 10
    2008 / 8
    2008 / 4
    2008 / 3
    2008 / 2
    2008 / 1
    ▼ ▶
    2007
    2007 / 12
    2007 / 11
    2007 / 10
    2007 / 7
    2007 / 6
    2007 / 5
    2007 / 4
    2007 / 3
    2007 / 2
    2007 / 1
    ▼ ▶
    2006
    2006 / 12
    2006 / 11
    2006 / 10
    2006 / 9
    2006 / 8
    2006 / 7
    2006 / 6
    2006 / 5
    2006 / 4
    2006 / 3
    2006 / 2
    2006 / 1
    ▼ ▶
    2005
    2005 / 12
    2005 / 11
    2005 / 10
    2005 / 9
    2005 / 8
    2005 / 7
    2005 / 6
    2005 / 5
    2005 / 4
    2005 / 3
    2005 / 2
    2005 / 1
    ▼ ▶
    2004
    2004 / 12
    2004 / 11
    2004 / 10
    2004 / 9
    2004 / 8
    2004 / 7

  8. 2021/10/21 14:07:57 James Gosling: on the Java Road含むアンテナおとなりページ

    Error 404--Not Found
    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
    10.4.5 404 Not Found
    The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
    If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

  9. 2021/10/21 11:30:34 日々是新 Akihito Fujii’s Weblog含むアンテナおとなりページ

    Error 404--Not Found
    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
    10.4.5 404 Not Found
    The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
    If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

  10. 2021/07/13 15:35:25 まさたか日記含むアンテナおとなりページ

    月の生活 | よなよなエール公式ウェブサイト「よなよなの里」

  11. 2021/07/13 14:57:04 おおたに6号機の日々含むアンテナおとなりページ

    読者になる

  12. 2021/02/02 03:51:19 IT-Walker on hatena含むアンテナおとなりページ

    FAQ / お問い合わせ窓口

  13. 2020/06/03 12:02:28 よねのはてな含むアンテナおとなりページ

    海外POSシステム開発エンジニア募集 by 株式会社Abby
    現在、大規模チェーンレストラン向けのレストラン店舗運営システムを開発しています。展開先はアメリカ、オーストラリア、台湾、マレーシア、...
    www.wantedly.com
    Unityでスマホ、Switchのゲーム開発をしたいエンジニアを募集! by 株式会社Abby
    今回は、・Unityを使用したNintendo Switch向けのゲーム開発・Unityを使用したスマートフォン向けのゲーム開発...
    www.wantedly.com

  14. 2016/09/20 11:33:26 ひがやすを blog含むアンテナおとなりページ

    2016-09-20
    Seasar Conference Final
    今週の土曜、9/24にSeasar Conference Finalを行います。
    10年前に始まったSeasar Conferenceもいよいよ今度でFinalです。
    お申し込みはこちら。
    http://seasar.connpass.com/event/38679/
    Seasar Projectの面白かったところって、開発方法論が盛り上がったところだと思うんですよ。
    マーチンファウラーをはじめとして、著名な人たちのほとんどが「ドメインモデル推し」の中、僕は、「ステートレスなサービス + DTO推し」だったからね。S2Daoは、このために作ったようなものです。
    あの開発方法論の議論に、かなりの人が参加したり、自分で考えたりしたでしょう。それが、面白かったところです。みんなが自分の事として考えたから。そんな難しい話ではないし、自分のプロジェクトに即いかせる話だしね。
    オブジェクト指向ナンチャラとかDDDとか、素晴らしいものなんだけど、自分のプロジェクトで生かそうとするとそう簡単にはいかないからね。
    Seasar2の開発が終了した事で、Seasar Projectに関わった多くの人たちの多くの時間が無駄にされたと、思っている人もいるようだけど、僕はそうは思わない。Seasar Projectに関わった事で、プログラマとしての能力や知名度をあげた人とって多い訳だから、それを否定する必要はないと思っています。
    今度のSeasar Conferenceでは、「Seasar Projectのふりかえり」と「SXSW攻略法」の二つの話をします。
    「Seasar Projectのふりかえり」では、昔話をしてもしょうがないので、いくつかのプロジェクトを「なぜ始めたのか」「うまくいったところとでその理由」「失敗したところとその理由」を話す事で、これから、新しくプロジェクトを立ち上げる人向けに、少しでも役に立つ話が出来ればと思います。
    「SXSW攻略法」では、2016年のSXSWで、RealeaseItというアワードでファイナリストに残る事が出来たので、ファイナリストに残るためのこつ、そしてアワードをとれなかった理由。また、SXSWでは、ブースも出したので、ブースを出すときのポイントを話したいと思います。
    Seasar Conference Finalお申し込みはこちらです。
    http://seasar.connpass.com/event/38679/

  15. 2015/02/25 23:26:35 Java News (Javaに関する最新ニュース)含むアンテナおとなりページ

    ■015.004.008
    [ EVENT ] 4月8日 Java Day Tokyo 2015 開催!
    http://www.oracle.co.jp/jdt2015/
    [ BROWSER ] Firefoxのページめくりを加速さ-http://journal.mycom.co.jp/news/2010/02/02/007/index.html

  16. 2011/01/14 01:46:19 ユメのチカラ含むアンテナおとなりページ

    アーカイブ
    2009年3月
    2008年12月
    2008年11月
    2008年10月
    2008年9月
    連載を終了したブログ
    コアテクの路地
    路地裏 ソース解読研究所
    みたのブログ
    拓かれた世界に向かって
    ペンギン飼育係が見た
    ユメのチカラ
    独立行政法人情報処理推進機構へ出向になりました。
    3月1日付けで独立行政法人情報処理推進機構(IPA)へ出向になりました。オープンソフトウェア・センター研究員を拝命し、本日より同機構へ出勤しています。ミラクル・リナックス時代は大変お世話になり厚く御礼を申し上げます。IPAでも変らづご厚情お願いいたします。略儀ながらおしらせまで。
    さて、ミラクル・リナックスからの出向ではありますが、オープンソースソフトウェアや勉強会あるいは若手人材育成(セキュリティ&プログラミングキャンプ、U-20プログラミングコンテスト)などなどにつきましては、今迄どおり、ゆるゆると推進していきたいと思います。皆様のご協力をよろしくお願いいたします。
    そして、カーネル読書会も従前どおりやりますので、そちらの方もよろしくお願いいたします。
    本日は久々にスーツ&ネクタイ、コスプレでした。(がはは)

  17. 2010/01/29 06:49:16 新・たけぞう瀕死の日記含むアンテナおとなりページ

    Forbidden
    You don’t have permission to access /~asaki/p_diary/diary.cgi on this server.

  18. 2009/11/21 02:27:08 オレンジニュース含むアンテナおとなりページ

    ■ Google、「Chromium OS」を公開
    http://www.publickey.jp/blog/09/chrome_os.html
    ■ シャットダウンも日本語入力もできない?
    http://blog.livedoor.jp/dankogai/archives/51325262.html
    ■ Chronium OSのコンパイル手順
    http://d.hatena.ne.jp/showyou/20091120/1258687525
    ■ IBM developerWorks:Scitter(ScalaのTwitterクライアントライブラリ)を使ってTwitterを更新する
    http://www.ibm.com/developerworks/jp/java/library/j-scala10209.html
    ■ IBM developerWorks:Web アプリケーションのセキュリティー: 脆弱性をテストする(WebScarab、Paros Proxyの紹介)
    http://www.ibm.com/developerworks/jp/web/library/wa-appsecurity/
    ■ IE用のJavaScriptパフォーマンス分析ツール「dynaTrace AJAX Edition」
    http://journal.mycom.co.jp/news/2009/11/20/017/index.html
    ■ YouTube:Lisp for High-Performance Transaction Processing
    http://www.youtube.com/watch?v=xquJvmHF3S8-■ ブラウザ上で世界中のAM・FMラジオ、ネットラジオが無料で聴けるサイト「Streema」