JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net (766ﾚｽ)
JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1449440793/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
119: デフォルトの名無しさん [sage] 2016/05/13(金) 00:04:56.39 ID:PxVJ9U+u >>115 > 自分が言った「ちゃんと書く」とは、asm.jsを（部分的に）手書きするということだ。 だからそれは屁理屈なんだよ。 言語の速度比較なら、普通に書いた、つまりそこらへんに転がっている記述同士でやらないと意味無いだろ。 Cでインラインアセンブラを使うのは無し、 JavaScriptなら普通に [], {}を使って書いたものだよ。全面 TypedArray とかは無しだよ。 というか、それならそもそもそういう言語で書けって言われるようじゃ駄目だろ。 言語の比較なら、それぞれの言語の良さを生かした状態で記述してあるものでないと。 君が言っているのは、「チューニングしたときに伸びしろがあるか」ということであって、 言語の速度比較ではないんだよ。 CならSSEやCUDAまで導入できるのだから、それも入れていいかというと違うだろ。 普通に書いて普通にコンパイルできる状態での比較じゃないと意味無いだろ。 そして、そこでいちいちムキになることも無いんだよ。 不満があれば他言語で書けばいいだけ、 その言語を使っているのなら、エコシステム含めてその言語が一番マシだから使っているだけ。 それ以上でもそれ以下でもないだろ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/119
122: デフォルトの名無しさん [sage] 2016/05/13(金) 20:51:55.08 ID:PxVJ9U+u >>114 > Microsoft Windows 98、Windows 2000、および Windows Me には、 > Microsoft JScript および VBScript の 2 つのスクリプト エンジンが用意されており、 > 通常はこのいずれかを使用してスクリプトを記述します。 > Windows Script Host では、このほか、Perl、REXX、Python などのスクリプト エンジンも使用できます。 > https://msdn.microsoft.com/ja-jp/library/cc392505.aspx やべーわ完全に食わず嫌いだったわ。 見た目、.NETと同じく言語非依存のフレームワークを提供しているんだな。 標準入出力＋αで満足するから完全に十分だわ。 というか結果的にMSには先見の明があったな。 以下によると//xでデバッガが起動出来るらしいが接続してくれない。 そっちでは動いている？ > WSHはVisual Studioでデバッグを行うことが可能です。 > Visual StudioはExpressの場合にデバッグが行えないかもしれません。Professional以降が必要かもしれません。 > http://qiita.com/mima_ita/items/127e171db67aaee6ef30 Vista+VSExpressなんだけどね。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/122
124: デフォルトの名無しさん [sage] 2016/05/13(金) 22:06:05.08 ID:PxVJ9U+u >>120 > EWM 否定したいわけではないが、君が言っているような「打ち出の小槌」なんてどこにもないんだよ。 低レベルAPIを規定して高レベルAPIを柔軟に構築というのは確かに出来る。 ただ、その高レベルAPIを「仕様として」リリースしたら、一般的にはもう削除は出来ないんだよ。 だから不要になった場合は、エミュレーションモードとして、動きはするがそれだけのもの（速くはない)として残すことになる。 VGAとかがまさにそう。今時のグラボもVGAは表示できないといけないので、この方法で残している。 ただエミュをするのなら、低レベルAPIによってではなく、実装側で高レベルAPIだけをエミュしたほうが簡単なんだよ。 それを低レベルAPIでエミュしろ、そうじゃないと駄目だ、ということになると、性能が引き出しづらくなる。 だから結局、低レベルAPIで高レベルAPIを構築というのは効率が悪くなる。多分頓挫する。 そのやり方はAPIではなく、ライブラリの粒度でやるべきなんだよ。 ライブラリってのは標準JavaScriptを低レベルAPIとして、中レベルAPIを構築しているわけだから。 例えばAppCache、もういらないとして、ブラウザ側で高レベルAPIだけをエミュするだけならまあ簡単だろう。 他の似た機能があれば、それと中身は差し替えて見た目だけエミュすることも可能だ。 (WebSQL->IndexedDBの場合とか） しかしそれを構築するために使用した低レベルAPI群があるとして、これらも不要になるわけだが、 それらを全部エミュしたままで残せということになると、結局手がつけられず、そのまま残すしかなくなる。 結果、ブラウザ側に「開かずの扉」的コードが累積していき、長期的に進化を妨げることになる。 こうならないためには、「将来的にも」不要にならないAPIだけを規定していくことが肝要。 これは低レベルAPIの方が難しいんだよ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/124
125: デフォルトの名無しさん [sage] 2016/05/13(金) 22:06:20.89 ID:PxVJ9U+u まあいずれにしても、上手く行くかどうかは結果を見ればいい。 俺は上手く行かないと予想している。 ブラウザ側も馬鹿ではないから、俺が言っていることぐらい分かっている。 だからgoogleの「最適化としては行うが、asm.jsにべったりでは無い」というのがかなり妥当。 旗振り側のFireFoxは実装するしかないから、両方の言い分は分かる。 君の見方だけではgoogleが及び腰な理由を説明できないだろ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/125
126: デフォルトの名無しさん [sage] 2016/05/13(金) 22:12:02.90 ID:PxVJ9U+u > どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。 それはCの考え方だ。そして君はC/C++と連携するためにNodeを使っているのだから、君としてはそれで正しい。 ただ、「メモリ」を意識するのはJavaScriptじゃないんだよ。 だから、君はおそらくCの考え方に束縛されている。 というか、それだと君はJavaScriptを使えていない。 君だと、Rubyでは何故ただの数値ですらオブジェクトなのか説明できないだろ？ 例えばサーバーのログを解析するとして、grepで済むならそれでいいけど、 それ以上なら通常はPerl等が用いられる。 もちろんこれをCでやることは出来るけど、普通はやらない。 理由は簡単、Perlの方が楽だからだ。 それをどうしてもCでやれ、Perlはインストールしてねーとなると、ふざけるな！となるだろ。 JavaScriptも同じで、クライアントスクリプトという政治的要因が無ければ、 当たり前だがその言語を使うのが一番楽（適している）ところで使われる。 その状態においては、 > どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。 これが要求されることはほぼ無い。 というか、メモリアクセス速度が要求されるのなら、最初からC/C++で書け、でしかない。 実際にこれで高速化するのなら、本来Cで書けばいいだけのものをJavaScriptで書いてるだけだよ。 👀 Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) http://mevius.5ch.net/test/read.cgi/tech/1449440793/126
127: デフォルトの名無しさん [sage] 2016/05/13(金) 22:12:42.95 ID:PxVJ9U+u PerlやRubyと同様、JavaScriptにもいい点はあって、 それを生かす書き方をしていると、仮にCがブラウザで動いたとしても、Cじゃつれーわ、となる。 君にはそれが無いだろ？それはJavaScriptを使っているだけで、使えていない。 クライアントスクリプトでの高速化は、今の俺の結論としては「後回し」、これに尽きる。 1画面分しかDOM操作はしない。出来れば内部データも用意しない。 これだけで見た目はものすごく速くなる。 クライアントサイドでどうしても演算が必要な場合は、ゲームか非標準の強力な暗号化くらいだよ。 速度が重要なガチゲーやる奴は「サクサク専用アプリ」があれば必ずインストールする。 だから結局用途が無いんだよ。 速いことは重要なのだけど、JavaScriptに求められているのは演算やメモリアクセス速度ではない。 演算が10倍速になるより、DOM操作が2倍速になる方が効く。 asm.js っぽくコーディングするよりも、DOM操作を1つでも減らすようにした方が効く。 だから asm.js は悪くは無いけど、いい筋ではないんだよ。 そして一般のクライアントスクリプトで asm.js 流の書き方をすることも無いよ。 だって読みにくくなるだけで効果ないから。つまり、流行る理由が見当たらない。 君はasm.jsがブラウザに必要とされていると本当に思っているのかい？ asm.jsが実装されるより、ブラウザでのDOM操作速度が2倍になる方が普通はうれしいだろ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/127
128: デフォルトの名無しさん [sage] 2016/05/13(金) 22:40:16.76 ID:PxVJ9U+u >>121 > 仕様の量も段違い とにかくこういうことにしたい奴が多いようだが、これは明らかに違う。 .NETにしてもJavaにしてもクラスライブラリの量は桁違いに多い。 文法的にも覚えることは多いし、記述的にもより細かく指定できる。 JavaScriptは軽くて簡単な言語だよ。元々そう作られたものだし。 （これは悪いことではない） > その１つ１つのバージョンを意識したり指定したりということはできないし > 原則後方互換性を守りながら拡張していくしか無い Javaは知らんが.NETはバージョン管理されていて、 廃止されたメソッド等もある。（完全上位互換ではない） ちゃんとやれば出来ることなんだよ。もちろんその実力が必要だけど。 詳しくは知らないが、DirectXはバージョンが一つ違ったら別物だったらしい。 低レベルAPIだから必然的に実装とリンクしてしまうのでこうなる。 結果的にMSはDirectXを使い捨てし続けることで乗り切っている。 Webもやれば出来るだけだよ。やってないだけ、やる実力も無いだけで。 とはいえ、試行錯誤でいくというのも一つのいい作戦だ。 その場合は、どうしてもゴミが紛れ込んでしまうので、定期的にGCしないといけない。 それが全く出来てないからおかしなことになっている。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/128
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.032s