AppleとARM、64ビットARM向けコンパイラ開発リソースをLLVMに投入 43
ストーリー by hylom
標準コンパイラの地位を着々と 部門より
標準コンパイラの地位を着々と 部門より
あるAnonymous Coward 曰く、
Appleが64ビットARM向けのLLVMバックエンドをオープンソース化したそうだ。また、ARM社も64ビットARM向けには自社開発のコンパイラではなくLLVMを推奨する方向らしい（ARM 64bit でLLVMは見逃せない、Phoronix）。
すでにLLVMには64ビットARM向けバックエンド（aarch64）があるが、今後はAppleｇはオープンソース化したLLVMバックエンド（arm64）をベースに統合作業を進めるという。
結局のところ (スコア:3, 興味深い)
リンゴに目をつけられたJavaはその未来をパクられ、残りカスとして
消え去る運命という事か・・・
Re: (スコア:0, フレームのもと)
まるで、Apple製品以外ではデスクトップやモバイルで、
普及しているかのような物言いですね。
javaは、dalvikのように、ガワだけ残して中身総とっかえでもしないと
(クライアント用途としては)使い物にならない欠陥品だった、
というのが歴史の出した結論です。
言い換えると、クライアントサイドでは、レスポンスの良さが何にも勝る。
中間コード使う処理系は、
MSのように、OSに統合してJIT負荷を下げるしか道がなかった。
Re:結局のところ (スコア:1, 参考になる)
意味不明。
DalvikはJava勢からの影響を避けるために
意図的にJava非互換にしてるようなものであって、
あなたの考えているようなものではまったくないですよ。
また、Dalvikも中間コードを生成します。
でないとARMやx86で互換性のあるアプリがビルドできません
（NDKはまた別）。
とりあえず素人丸出しのアンチJavaなApple信者さんとしか見えませんので
勉強して出直してきてください。
Re: (スコア:0)
>また、Dalvikも中間コードを生成します。
>でないとARMやx86で互換性のあるアプリがビルドできません
そうだよ。だから、
>中間コード使う処理系は、
>MSのように、OSに統合してJIT負荷を下げるしか道がなかった。
を実践したわけでしょ。
javaがjavaである限りクライアント用途としては失敗作。
C#はMS-OSと密結合することでWindows クライアントアプリ用途として成功し、
dalvikはAndroid OSと密結合することでAndroidアプリ用途として成功した。
密結合することを拒むjavaは(クライアント用途として)死んだ。
>とりあえず素人丸出しのアンチJavaなApple信者さんとしか見えませんので
>勉強して出直してきてください。
アンチとかファンとかの色眼鏡で世の中見てると本質見失うよ。
Re: (スコア:0)
「現状のJava VMが各OSの機能を活用しきっていない」という話ならまだ分かるんですが、それがなんで「OSと密結合云々」という話にすり替わるんだか……。
別にDalvikってOSと密結合してないでしょう。でなけりゃIn-The-Boxなんて実現できるわけがない。
Re: (スコア:0)
これが「フレームの元」なら分かるけど「荒らし」なのか…
#2586827とは別人だよ。まあACで言っても仕方ないけど。
Re: (スコア:0)
＞レスポンスの良さが何にも勝る。
何の目的でクライアント用途に使いたいのか、はっきりしないでjavaの名前を出すって、設計としてダサくない？
というか、あなたの作るシステムではそういうことをやるんでしょうね。
＃で、お客が要求したからとか、己の能力不足を糊塗する逃げをうつ類のオチか。
Re: (スコア:0)
>何の目的でクライアント用途に使いたいのか、はっきりしないでjavaの名前を出すって、設計としてダサくない？
何を読んでjavaの名前出すと思ったの？
出すわけないでしょ。そんな死に言語。
レスポンスよりもスループットが効くサーバー用途でしょ。javaは。
あと、監視用途ね。起動したら最低でも週単位で落とせないアプリ。
Apple製品が出てくる分野でjavaとかアホの極み。
Re: (スコア:0)
バイトコードは表現力が微妙、今のJITならコードそのものの方が動的最適化が効きやすい。
clang/LLVMも威勢の良いこと言った割に。GCCと大差ないのは、中間言語で構文解析と最適化が分離されているから。
Re: (スコア:0)
> バイトコードは表現力が微妙、今のJITならコードそのものの方が動的最適化が効きやすい。
いやさすがにそんなわけない。
シェルスクリプトが世界最速の実行環境ですか？んなわけないでしょ。
なんか変なアンチJavaが粘着してるっぽくて気持ち悪いですが勉強して出直すかどっか行くかしてください。
Re: (スコア:0)
勉強して出直せ、って言う言葉。論の正しさではなく。哀れなやつ
Re: (スコア:0)
論の正しさではないものを勉強して出直せとかもう完全に神学者の説教だな
Re: (スコア:0)
javaよりJavaScriptの方が速い
http://nothingcosmos.blog52.fc2.com/blog-entry-155.html [fc2.com]
関連ストーリー (スコア:1)
Appleはオープンソースコミュニティを支援していない？
http://opensource.srad.jp/story/14/04/15/1048211/Apple%E3%81%AF%E3%82%... [srad.jp]
Re:関連ストーリー (スコア:5, 参考になる)
ライセンスの都合で Apple は GPLなソフトウェアには貢献してませんね
Apple が、GCCではなく、LLVMに力をいれてるのも
GCCがGPLで、LLVMが非GPL(BSD風のOSI認証ライセンス)だから、という話です
LLVMとそのフロントエンドの clang だけを見れば
Apple はコミュニティにものすごく貢献しています
Re:関連ストーリー (スコア:1)
>ライセンスの都合で Apple は GPLなソフトウェアには貢献してませんね
CUPS
Re: (スコア:0)
WebKit
ちょっと何言いたいのか分からん記事だな (スコア:0)
Appleは以前からLLVMバックエンドとしてarm64というのをやってたんだったらタイトルもおかしい気がする。
ARMが64bitでは自社ツール捨ててLLVMに注力し、aarch64とarm64のふたつあったバックエンドはひとつに統合されるってのはニュースなんだろうが、aarch64とarm64のふたつの実装が存在した経緯も解説してくれないとわけわからん。
Re: (スコア:0)
なんだか不思議な日本語になってますね。各文章は意味が通っているし、文章同士も関係ありそうなのに、全体としてみると何が言いたいのかわからない…。
Re: (スコア:0)
どっかで読んだんだが、arm64をベースにaarch64のコードをマージして、出来上がったものをaarch64にするらしい。
Re: (スコア:0)
どっかでって言うかタレコミのリンク先にまんま書いてありますよ。
いつになったら速くなってくれんだろうね。 (スコア:0)
>Cortex-A53で計測されたものですが、現時点ではgcc4.9が勝っているのが興味深いです。
(http://d.hatena.ne.jp/embedded/20140416/p1 [hatena.ne.jp])
組込向けじゃぁ、それではまずいだろ。遅いってことは、電池の減りが早いってことだから。
IA (Intel Architecture) 向けでも LLVM は遅いよね。いつになったら速くなってくれんだろう。
Re:いつになったら速くなってくれんだろうね。 (スコア:2)
これってコンパイラの最適化が向上すれば既存のiOS機器でも速度向上する余地があるってことですよね。
期待してます。
Re:いつになったら速くなってくれんだろうね。 (スコア:1)
組み込み向けじゃ, むしろgccでは速度以前にライセンスの問題で俎上にのることさえできないことも多いのでは?
Re:いつになったら速くなってくれんだろうね。 (スコア:1)
いや、別に。組み込み向けにgccは多いですよ。特にLLVM登場以前は、gccが主流でしたし。
Re:いつになったら速くなってくれんだろうね。 (スコア:1)
ただし、そのころは GPL2 だった。
Re: (スコア:0)
そゆこと
GPLv3が原因の1つでしょ ARM が LLVMに行くのは
Re: (スコア:0)
GPLv3がGCCを組み込みに使う上でなんか問題になる状況ってあんの?
Re: (スコア:0)
GPLv3のライブラリ，ソフトウェアを組み込んだときに問題になるのであって，
ビルドツールとして使ってるなら問題ないですよね・・・
Re: (スコア:0)
GPLv2の場合は、ライブラリ自体の改変があったら、ライブラリ自体のソースを公開する必要
はあるけれども、リンクしたプログラム自体のソースは公開不要で、
GPLv3の場合は、ライブラリをリンクしたら、リンクしたものは派生物として扱うから、
ライブラリソースだけじゃなく、ライブラリをリンクしているプログラムのソース
も公開しないといけないんだっけ。
Re: (スコア:0)
組込みのツールチェインだとlibcなんてパッケージされてないし、スタートアップルーチンも独自だしね。
Re: (スコア:0)
それはLGPLとGPLの違いや
自社製のコンパイラ作らないCPUメーカってどうなのよ。 (スコア:0)
ファブレスでアーキテクチャの設計しかしないのに、そのCPUのためのコンパイラすら他に任せるって。
Re: (スコア:0)
どうでもないです
頼めばコンパイラ作って得くれる専業メーカーがあるから何の問題もありません
ぶっ飛んだような特殊なアーキテクチャのプロセッサでもなければ自社開発に拘る技術的な必然性は無いです
もちろん良いツールを自社開発出来れば商売上の大きなメリットになりますが、内製するか外にまかせるかの選択はメーカーのポリシーによりけり、ケースバイケースでしょうね
少なくともARMに関してはみんなが神輿を担いでくれる存在にのし上がっているので、どうやっても悪いようにはならないでしょ
Re:自社製のコンパイラ作らないCPUメーカってどうなのよ。 (スコア:1)
元コメのACではありません。
＞ 少なくとも ・・・ 途中略 ・・・どうやっても悪いようにはならいでしょ。
直近は、その通りだと思うのですが、64bit化して、Intel と正面からぶつかろうとしている時に、既に持っているコンパイラ技術すら手放そうというのは、どうなんでしょうか？もちろん ARM内部の判断は判りませんが、周囲（エコシステムというか利害関係者というか）はどう見るのでしょうか？
親コメさんや、私は、なんだかなあと思ってしまうのですが、外部のリソースを積極的に使うメリットと、コアに近い技術を手放すデメリットとと、業界の中心に近い処におられると思われる方々はどうなんでしょう？
Re: (スコア:0)
ARMってAppleの子会社じゃないんだっけ？今は…
Appleｇ (スコア:0)
Appleｇって、何？
みんなスルースキル上がり過ぎじゃないか・・・？