【IT】脆弱性が多いプログラミング言語、第2位はPHP - 第1位は?
■ このスレッドは過去ログ倉庫に格納されています
WhiteSource Softwareは3月19日(米国時間)、「Is One Programming Language More Secure Than The Rest?」において、過去の脆弱性情報を集計し、どのプログラミング言語がより多くの脆弱性とかかわりを持っていたのかについて伝えた。
脆弱性情報が多い順にまとめたプログラミング言語ランキングとしては、以下が報告されている。
C言語 (47%)
PHP (17%)
Java (12%)
JavaScript (11%)
Python (6%)
C++ (6%)
Ruby (5%)
データソースはNVD (National Vulnerability Database)、各種セキュリティアドバイザリ、GitHub、そのほか人気の高いトラッキングシステムなどで集計された脆弱性情報など。対象のプログラミング言語は、過去数年間にオープンソースコミュニティで使われたプログラミング言語の中から特に人気の高いものが選択されている。
記事では、関連する脆弱性が多いからといって必ずしもそのプログラミング言語がセキュリティに対して脆弱ということを意味するわけではないと説明。例えば、C言語のシェアは50%近いが、これは長期にわたって使われていること、インフラストラクチャを構成するソフトウェアに使われており注目度が高いことなども関係しているという。
https://news.mynavi.jp/article/20190326-795188/ PHPとか、よりマクロ的なヤツのほうが
そりゃ誰かのプログラムを呼ぶだけなんだから、
中学生が作ったC言語プログラムよりはマシだろうよ。 露骨にミスリード狙ってるなぁ
本文では言い訳してるが… 年間脆弱性6000件中3000件はPHP関連だけどな 言語に脆弱性があるんじゃなくて、その開発環境やライブラリってことだろうな
ただ一つだけ言えるのはフリーのものは総じて対応が遅いし、アホみたいな問題が発生することが多い まーC以外のプロトコルではほぼkernel作れないから仕方ないね cにphpにjavaか。。
実務でシェアでっかい奴ばっかじゃん といってもC以外の言語を駆動するインタープリタやVMはCで書かれてるわけで。
実行環境や言語仕様の安全性で言えばたぶん Java がベストなんだろうけれど
アプリケーションプログラムの品質で言えばたぶん Java がワーストだろうなぁ。
PHP は文字エンコードの取扱で深刻な脆弱性があったけどもう修正されたのかな？ >>14
ほんとにそう。
シェアが高けりゃ脆弱性の報告も多いのは当たり前で、言語由来の脆弱性があるとかいう資料じゃないのが本当に意味不明。
言語の人気ランキングと何が違うんだ？ そもそもPHPもJavaもCで実装されているのだが。 使われる機会が多い言語は
脆弱性情報も多くなる傾向になるだろうな この手のスクリプト言語ではやっぱPHPがとっつきやすい。
これで十分。 PHP,Java,JavaScript,Python,Ruby では OS やら速度が求められる機能は書けない以上
C/C++ とは守備範囲が違うし
その脆弱性を比較してもあまり意味はない 足したら104％なので、各言語ごとの集計だから
言語の本来なのか、多数波が狙われるのか c言語の脆弱性ってどういう意味なのかさっぱりわからん Cに決まってら と書き込もうとしてら
そのとおりで笑っちゃうな PHPは適当に書けば適当に動いてくれるからな
お手軽でいいんだけど、そのぶん予期しない結果になることもあるから
ある意味怖い言語でもある >>25
当たり前だよな
・シェアが大きい
・OSやデバイスドライバなど脆弱性が入り込みやすい用途でもちいられる
こんな調査に何の意味があるのかと…
(PL/Iは著しく脆弱性が少ないとか言いたいのかな？) Python (6%)
C++ (6%)
Ruby (5%)
って笑える。ＪＡＶＡやPHP以上に問題あるよ 生PHPのサイトなんて脆弱性だらけだからな
かと言ってフレームワークはロクなもんがない
PHPは滅びたほうが世のため >>25
c言語自体に脆弱性はない気するんだがなー
結局、コンパイラとかosの問題に帰結する気がする マックにはウィルスが少ないので安全、というのと同じ。 C言語を一番長く利用してきたので書きたい事が多くあるんだが眠い。
どんな言語でも弱点はあるけどC言語はすぐ作れるようになるので結果的に脆弱性を生みやすい？ >>10
Cをやってるやつらが脆弱性の塊ってことだろうな。
むりするなよ。できないこともあるから。 Cはバッファオーバーフロー攻撃とか効く言語だ
そしてまあまあ他の言語より書くのに神経を使う部分がコードの本質より別のことに割くから
そして沢山使われてれば攻撃も多いし、苛烈
---
2nd にペチパー無様ｗ
ペチパー ペチパー と煽られるだけはある 良い子のみんな、ゴキブリ韓国人を見てごらん
ちゃんと勉強しないと、ああなっちゃうんだよ
悪い子のみんな、悪いことばかりしていると
ゴキブリ韓国人に生まれ変わるんだよ >>35
gccだと-fstack-protectorと-D_FORTIFY_SOURCE=2フラグを忘れずつければ良いが忘れるのは簡単だ >>29
スクリプト言語の脆弱性は言語のメンテナンスチームの質や設計による
PHPのセキュリティ脆弱性は段違いに酷い
商用向けならセキュリティのコンサルなりに見せないと安心できない javaって制御系では使えませんと明記されていたから
Cで組んだけど。制御系はやばいからjavaあかんって事なんだろうけど。 見出しがおかしいな
言語に脆弱性があるわけじゃないだろう というか、そんなほかの言語ときちんと比較できるほど知っている人っているんかいな？
俺はJAVAしかわからん その言語で作り
その言語の言語処理系でコンパイルしたり、スクリプト実行したり
そういう各種システムの脆弱性情報を集めて
それを言語別に集計しました
みたいな話なんだろうな >>39
GC が動き出すと予期せず動作が遅れることがあるのでリアルタイムの制御には向かない。
セキュリティの問題ではないよ。
そういう分野では GC のない C/C++ しかない。 ちゃんと書けてるつもりでも書けてないんだよ
プログラムなんてだれでも書けるんだというやつは
落とし穴にハマりながら言ってることに気が付いてない 自分は今、ピクセラ社の、 Station TVというのでテレビをPCで見ているが、 Microsoft Visual C++ というのがないと強制終了する。絶対にあかない。
コレはあれこれ 自分自身で試行錯誤して 見つけた。 OSを回復や再インストール後、コレを入れてｋら、このアプリを入れないと、起動しない >>44
システム開発、サービス開発という業務においてプログラミングはそこまで重要じゃないということを知ってる人が案外少ないんだよね。
分からない人から見るとプログラミングできること自体がすごく見える（機械と会話できる）みたいなんだけど、
ライフサイクルや事業計画にアジャストしたプログラミングを書くことが容易ではないのであって、
プログラミングそのものは難しくないということが分かっていない。
ただプログラミングするだけならレベルにもよるけど一ヶ月もあれば誰でも出来ることなのよねｗ
この話は「ただ英語を話せるだけの人」を連れて来ても事業上のメリットはあまり得られないことと近しいと思う。
「英語ペラペラの人を採用しました！」「じゃあ、事業の海外展開も順風満帆だね！」
そんなアホな考えをする人はいないだろって話ｗ >>46
高レイヤーでちょっとスクリプト言語かじった程度の認識だね
動くだけソフトウェアやサービスなら素人がコピペでも作れるよ
そんな自称プログラマが作ったソフトウェアやサービスが山ほどあるね
不特定多数が利用するウェブアプリケーションなんて被害が顕著であちこちで情報流出が絶えない
さらに新しいアプリをそのゴミコードをベースにコピペで作るもんだから脆弱性をバラまいてることに気が付かない
まあ使う人間が限られたソフトウェアやサービスならバグがあろうが脆弱性があろうがかまわんだろうがな Cのライブラリに脆弱性見つかって狙われるのはそれを利用しているサーバ上のphpだったりするよね 韓国人のやり方
●善人面で日本人に接近しろ。
●片言の日本語を一生懸命に喋れば、日本人は善人と信じ込む。
●日本を韓国文化で浸食しろ 。
●日本文化に「韓国発祥だ！」と言いがかりを付けろ。
●韓国の歴史観を否定する者は、土下座するまで恫喝しろ。
●「韓日併合は植民化までの通過点に過ぎない。」と主張しろ。
●日本人に なりすまし、世界中で悪事を働け。
●韓国アプリ「ＬＩＮＥ」で日本人の個人情報を盗み取れ。
●国際ＩＴ企業に潜り込み、内側から支配しろ。
●世界中の韓国系・中国系・ユダヤ系と連携して日本を叩け。
●「日本＝ナチス、韓国人＝迫害されたユダヤ人」と世界中で同一視させろ。
●韓国の失業者を日本へ大量移民させろ。
●移民は最強の侵略兵器。大量に入れて日本を植民化しろ。
●日本の右翼に成りすませ。日本の左翼を援助しろ。
●日本へ陰湿な嫌がらせを繰り返せ。
●危険な毒食品・不良製品を日本へ大量輸出しろ。
●日本の神社に放火しろ。神仏を破壊しろ。御神木を薬物で枯らせ。
●エイズにかかったら、日本へ行け。日本人とヤリまくり、病気をバラ撒け。
●対馬の土地を侵略目的で買い漁れ。
●日本にグローバリズムを植え付けろ。韓民族のナショナリズムは守り抜け。
●日本人に親切にする事は、見返り狙いの「先行投資」である。
●反日はどんな苦痛も和らげる万能薬。 >>46
>ライフサイクルや事業計画にアジャストしたプログラミングを書くことが容易ではないのであって、
事業の内容にもよるがプラットフォームに近いレベルにいくと、三流人材がハリボテを実装してしまうと後続の競合他社が高速に追加機能を実装し
さらに遅延などによってユーザーに見放されるか、サーバー代・消費電力が馬鹿にならなくなって詰むことになる @RKX1209
イノベーションの先生「昔カノープスって会社を作ってグラフィックアクセラレータを開発して
世界トップの売り上げを更新した。当時のNVIDIAと性能差を圧倒的につけられたのはデバイスドライバの質で...
その後上場してグラスバレーに買収されたよ」 僕((すす…
toshi_noP （としの@事務員ドールP）
当時32ビットのリエントラントなデバイスドライバをアセンブラで書ける人って、カノープスとNECに
1名ずつしか居なかった日本。 他はリファレンスのドライバをそのまま添付するしか無くて性能以前だった。 ビル・ゲイツ「優秀なソフトウェア・プログラマーは平均的なプログラマーの10,000倍の価値がある。」
http://tracpath.com/works/story/high_performance_computing_programmer/
「優秀な旋盤工の賃金は平均的な旋盤工の数倍だが、優秀な
ソフトウェア・プログラマーは平均的なプログラマーの10,000倍の価値がある。」 >>46
> ただプログラミングするだけならレベルにもよるけど一ヶ月もあれば誰でも出来ることなのよねｗ
ただ野球するだけならレベルにもよるけど3日もあれば誰でも出来ることなのよねｗ
草野球レベルと、プロ野球レベルを同列に語るバカ。
野球のルール同様、Cなんて言語仕様は簡単だよ。他の言語と違って、本来標準
ライブラリはなくても作れるものだし、車輪の再発明の手間さえ厭わなければ、
必ず標準ライブラリを使う必要もない。 昨今のスクリプト書きのゆとり世代は、「本物のプログラマはPascalを使わない」
(原題:Real Programmers don't write Pascal)とか、知らんのだろうなぁ。 cはマルチスレッドで困る。あと、文字列処理が糞めんどい。 セキュリティのためには型推論＋LLVMでネイティブコンパイルできる系言語が
もっと普及すべきだけど群雄割拠だしそこまで要求されることが少なくてなかなかシェアを取る言語が出てこない >>28 ID:zryLjFFD
>>25
>> 当たり前だよな
>> ・シェアが大きい
>> ・OSやデバイスドライバなど脆弱性が入り込みやすい用途でもちいられる
統計数値の誤用の例
利用頻度の高い言語ほど事故も多くなる。
言語の脆弱性？
脆弱性の事故件数÷利用頻度で比較しないと意味がないのに。。。
特にC言語はマクロアセンブラに1対1に対応可能なんだからC言語の脆弱性
って何なんだろうか？ C言語はバッファーオーバーランが起きやすい言語仕様というところかな…
プログラマーが完璧なら問題が起きないけどそれもあり得ないからな… ・言語そのものに脆弱性がある
・その言語で作られたフレームワークやライブラリに脆弱性がある
・その言語で作られたアプリ、プログラムに脆弱性がある
この３つ分けて考えたほうがいいのでは？ フレオっていうサイト作成ツールがPHP5なんだけど使わない方がいいんかな G7サミット国が母語とした自然言語ですと
論理的なドイツ語は堅固性が高く、情緒的な日本語は脆弱性が高いと思う
いい代えれば、脆弱性の高さが「玉虫色」の解釈を許すということ
文脈次第でどのようにも読解できるということ
日本の腹芸政治家が良く使う言葉そのものですな～ これから進展するAIシステムがもっとも不得意とする世界だろうね
まるで「禅問答」か公案問答集のようなものだ
コマンドがファジー
文脈もファジー
ハイ、ハイパーテキストを瞬時にして解釈できる
最近流行りの「コミュニケーション」能力の最高峰になる >>1
母数でわらんと意味内
ｃは割合的には大したことなさそう 人工言語の進展が、実は・・・自然言語から本来内包していた「巧みさ」を奪ってます
つまり、自動車に頼るがあまり足が萎え弱い人物になるように
電脳に頼り過ぎて、人として高度な交接が不能になるとは何とも嘆かわしい風潮に成るかもｗ 人工言語の議論は、釣り師がどんな装備で目的の魚を釣り上げるか
この議論に近い
所詮、人間が自然言語を模倣して構築した人工言語である以上
常に「自然言語＞＞＞人工言語」となるでしょうね
もし、これが完全に逆になったときが、電脳に人類が完敗する瞬間 Cをディスる Pythonエンジニアっているけど
VBAでドヤ顔してるおっさんと同じ人種 C言語の開発は、ATT社のベル研究所
ここは戦後、トランジスター開発でノーベル物理学賞をゲットしたショックレー一派とか
世界一の物理学関係の有識研究者の巣窟で、通信システムの制御に最適化された言語
AとBがこれ以前に開発され、その完成版としてC言語をこの世に出しました
この言語で、UNIXが構築、したがって通信システムには、こいつが一番しっくり来ます
UNIXをもっと簡便にしたのがLINUX、UNIXカーネル（幹）はソースコードが公開されてるいて
方言だらけで、オープンソースの真骨頂を行ってるOSになる
したがって、この言語の得意とするのは「制御」系 何年経ってもオブジェクト志向がわからんおっさんが通りますよ 言語は、自然も人工もシンプルでオーソドックが一番安定していてレスポンスも速い 中央演算装置に直接対応したアセンブラから入って、次がC言語
これが一番、深いレイヤの理解に繋がると思う スクリプト言語は「脚本」
オブジェクト言語は、その脚本を支える「文脈」 スクリプト言語を駆使したければオブジェクト言語に精通しなければ使い物にはならんと思うが如何？ PHPで、脆弱性を全部潰して実装するの、えらく大変だったなあ
10年前の話だけど PHPもPythonも同じだろ
Cが別格なのはわかるけど… CやPHPみたいに自由度が高い言語は書くやつがヘタクソだといくらでも脆弱になる。使う人の問題だろ。 PHPは簡単に使えるのでレベルが低いエンジニアによるミス
C言語は難しいので使い方がわからないレベルの低いエンジニアによるミス
結局レベルの低いエンジニアのせいやな。 >>79
アセンブラで計算機を
Lispで計算を学ぶのがいいと思う どの言語も同じだろ。結局は予算次第。
カネがないから低能プログラマーを安く使ったり、
脆弱性のチェックをしないで納品する。
そして検収でも気づかないので後々直せと言われたら代金を請求して直す。
その金を最初から出せばいいのにケチるから・・・ 入口はPHPと思う。Wordpressがメジャーなんで、ここからの攻撃が極めて多い。
Cは無数にプログラムが転がってるし。
脆弱性云々以前に作られたプログラムはそんなのお構いなし。
こんなもん、普通に考えて利用機会シェアに比例するに決まってるジャンｗ
言語に脆弱性があるって意味がよく分からない俺
どういう事だってばよ >>88
とはいえ、型の部分でポインタむき出し、自動キャストをしてしまう
C言語は致せりつくせりの高級言語に比べてセキュリティ面で不利
PGのレベルが低くても他言語なら何とかなっていたケースというのはあると思う
C言語は使う範囲を狭めて局所的な速度最適のためだけに使うほうがいい C言語なんてレガシーアプリだけだろ。
今はC++
つか、脆弱性言うんなら、一番危険なのはアセンブラ。 >>96
自動車の中で動いてる数百のコンピュータはほとんどCだぞ 良い子のみんな、ゴキブリ韓国人を見てごらん
ちゃんと勉強しないと、ああなっちゃうんだよ
悪い子のみんな、悪いことばかりしていると
ゴキブリ韓国人に生まれ変わるんだよ 過去の統計だと、こんなもんか
だが、メモリーリークへの安全性が保証されてないこれらの言語など、もはやセキュリティ目線だと論外
go-langかrust使え 言語としての脆弱性ではなく、過去に報告のあった事例の数でのランキングなんだから
より普及していてより古い言語ほどランキング上がるだけじゃん。 >>96
ところがだな、C言語で募集してるゲーム会社があって、
行ってみたらほんとにCで作ってたってのがあってだな。
せめてC++使いましょうよって言ったら「呼び出しにオーバーヘッドがかかるから却下」
って言われたんだと。
そこはMSDOS時代からゲーム作ってる社長が現役プログラマーもやってて
そういう時代の変化についていけない老害が実権握ってるとこはまだまだ多いよ。 システム運用してたら上がってくる脆弱性情報ってほとんどJavaなんだが >>104
C++の呼び出しオーバーヘッドって、何をわかって言ってるんだろうな？
インスタンス生成時のコンストラクタ呼び出しならクラス設計次第だし、ファイルや
ウィンドウのハンドルをメンバ変数として保持している程度なら、コンストラクタでの
初期化コストなんてほぼゼロだし。
局所変数をどこでも自由に宣言できるからと、forループ内でオブジェクトを宣言して、
ループ回るたびにコンストラクタ呼び出しされているとかか？
専門卒の50代現役だけど、ぜひ講釈を聞いてみたい。 >>107
言うとおり。cだろうがc++だろうが本質的には変わらない。cだってforでヒープ確保しまくりならコストかかるし、大したことないが…
それよりシステムコールのほうがよっぽど待たされる。ノンブロッキングで設計とかしてるとね。 こんなん、ニュース価値ないんじゃないの。
１％でも工数の割に期待金額とか高ければ、悪いプログラムもつくれるから でも、現実にRustを使っているからセキュリティがレベルが高い（ｷﾘｯてミドルウェアが出てきているからな
こんなのとか
Firecracker ? サーバーレスコンピューティングのための軽量な仮想化機能
https://aws.amazon.com/jp/blogs/news/firecracker-lightweight-virtualization-for-serverless-computing/
Firecrackerは最小限主義の流儀で造られました。 私たちはオーバーヘッドを減らし安全なマルチテナンシーを可能にするために、
crosvmからスタートし、最小限のデバイスモデルを設定しました。
FirecrackerはRustで書かれており、その最新のプログラミング言語はスレッドの安全性を保証し、
セキュリティの脆弱性を引き起こす可能性があるさまざまなタイプのバッファオーバーランエラーを防止します。 >>111
セキュリティを重視するのか、生産性を重視するのか、確保できる兵隊の数を重視するのか、開発対象によって異なるわな
システムプログラミングならセキュリティでRust、Webアプリなら生産性でjsかPython、受託SIなら兵隊数でJava一択 >>111
まずスレッド安全性を脆弱性と呼ぶのは語弊がある
一般論としてCでもスレッド安全性を追求すれば簡単にできるが、コードできるレベルにないなら標準外のスレッドライブラリーを使えば良い
（pthreadのことではない、ちなみに標準以外のライブラリーはCSの学生には学習範囲を制限・狭めるため薦めない）
いずれにしてもスレッドはローレベルでかなり早くできるので、ライブラリーに投げるのは望ましくない
それとこのマイクロVMはシングルCPUで何個もインスタンスを作ることを想定している
そのためマルチスレッドアプリケーションを動かしてもパフォーマンス向上の余地はおそらくないだろう
KVMをカーネルスペースに使っているからレスポンスが早く、実装面でも軽いのは当たり前として、安全といってる理由のレベルが違う
KVMのエミュレーション脆弱性を分離・仮想化することで、セキュリティレベルが高いと主張しているので、ローレベルの設計によってセキュリティを高めるしかないため、言語がセキュリティを高めているわけではない
PIC/APIC/IOAPIC/PITの機能には無駄なものが多いから、最低限のAPIC機能だけをKVMでサポートするのが早く安全であることは知られており、新しいアプローチではない
（ソースコードはチラ見程度なので、誤解している可能性はある） >>112
>システムプログラミングならセキュリティでRust、Webアプリなら生産性でjsかPython、受託SIなら兵隊数でJava一択
Rustのセキュリティが強いというのは誇張だ
Cならメモリーディテクター・プロファイラー/アナライザーやコンパイラのチェック機能を使えば良いだけだ。Cはハードウェア側の事情で使わないという選択はない
C++にはスマートポインターがあり心配ならばメモリーディテクターを使えば良い
Web周りであればgolangもある
バックエンドは速度が求められるため、（セキュリティは最悪だが）PHPが使われることはある。Pythonはパフォーマンスが必要な用途だと遅すぎる
JSはバックエンドとしては癖が強い
JavaやC#の最近のバージョンであれば安全性やパフォーマンス、ライブラリーの集積があるためWebにも十分に使える >>107
ポリモフィック使ったらメンバ関数呼び出しが関数テーブルの間接参照になってパイプラインストールの元だからな。 誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 67738
https://you-can-program.hatenablog.jp char *s;
scanf("%s",s);
ヨシ >>116
シッタカ乙。組込のワンチップマイコンでもない限り、WindowsやLinux前提の
システムなら、複数プロセス・複数スレッドが同時に多数走っていて、タスク切替
に伴うコンテキストスイッチも常に発生しているので、呼び出す関数内の実処理が
カラッポならいざ知らず、たかだか関数呼び出しがテーブルの間接参照呼び出し
になる程度など、問題にならんわ。 つまり Whitespace や なでしこは堅牢な言語ってことだな >>121
横からだが、ゲームはある意味組み込み系に近いからな
スレッドは時分割なんかじゃなくて、任意のタイミングで自分で切り替えるもの
Windows3.1のスレッドに近い 純粋に書くのはログインだけで
後はDBをjsonでjsとやり取りする時代たぞ。 まあCはしゃーない
殿堂入りだから
でもさあ
C++より多いJavaとPHPは何なの？ >>116
いや、実関数のアドレスが変わらない限りBTBでストールは起きない
煩雑に実関数のアドレスが代わるような場合は同じ事を関数テーブルで実現するにしろ、多段の分岐でするにしろ結局はストールする 自由度の高い言語は、きちんと管理しないと暴走します >>114
メインは設計、つまり言語非依存の部分でセキュリティを確保しているけど、
バッファオーバーランは言語によってセキュリティが向上する部分だろ >>124
今どきのハードウェアでも、ゲームはメーカーとかが用意したAPI経由じゃなくて
直接ハードウェア叩いてるの？ >>131
Unityで>>124みたいな非プリエンティブマルチタスクみたいなことをやっている
もっとマルチスレッドなゲーム開発環境があってもいいと思うけどな >>131
直接叩けたのは PS2 辺りまでだね
ハードウェア仕様変更に対応できなる恐れがあるから後期では禁止か非推奨になってたと思うけど >>56
pascalなんてC言語の前身みたいなもの。
「本物のプログラマならC言語は使わない」と言い換えても差し支えない。
Cを奨める似非プログラマの多いこと多いこと。 >>107
何百何千というオブジェクト(数十種類)に対して毎フレーム Update 関数(仮想関数)呼び出すと地味に処理負荷を食う
仮想関数経由での呼び出しを減らす最適化を行うことも実際にある
1ms 2ms を削りたい場面が出てくるゲームならではの話やね >>135
3Dモデリングのアプリなら判らんでもないが、たかだかゲームごときで何千の
オブジェクトはねぇだろ。 第一、3D描画やテクスチャ処理の大半は、ビデオ
カードに丸投げだろ。 日本のゲームとかほぼ紙芝居だし。 話盛り過ぎ。
1ms単位で削りたいなら、アセンブラで書いたら？(w >>136
上で書いたオブジェクトはいわゆるゲームオブジェクトと呼ばれるもので、ゲーム中にゲーム固有の振る舞いをさせる為に実装するもの(移動、AI、定型的な動き演出など)
描画関連のオブジェクトやリソースは全く別
画面に表示する可能性のある3Dオブジェクトはシーン中に数千から万越えは珍しく無いし、パーティクルだとその数は更に増える
> 1ms単位で削りたいなら、アセンブラで書いたら？(w
SIMD 命令は intrinsics を使うので最適化のためにアセンブラでコードを書くことはまずない
非効率なコードが生成されていないか逆アセンブルされたコードを確認することが稀にあるくらい
FF15みたいな有名タイトルだとこうやって具体的な内容も表に出てるし、かなり細かな最適化をたくさんしている
自分が書いた程度の内容で話を盛ってるとか思われるのは心外だよ
http://jp.gamesindustry.biz/article/1609/16090501/ 仮想関数呼び出しってCで同じことやろうとしたら結局インスタンスごとに分岐や関数ポインタ使うことになって同じ時間かかるだろ？
まあ予測当たるように大まかにソートしておくとかすればいいんだが
仮想関数だろうがやることは変わらない >>131
ハードにもよるけど、例えばDSは、SDKはあったけど、Vブランク割り込みとかは、普通にコールバックで受け取って処理してたね >>132
プリエンティブなスレッドは、バグの再現性の低いバグが出たときに全然追えないからなー
世の中にはコルーチンですらまともに排他制御できない人もいるからね、、、
でも、最近のUnityはやっと高速化にも力を入れはじめて、キャッシュヒットを考慮した作りにしたり、ワーカースレッドに処理を逃がす仕組みを作ったり、精度が低いけど高速な数学関数用意したりして >>138
関数テーブルでやらんでもいいだろと。
条件分岐の羅列でもなんでも >>141
分岐の羅列でも関数テーブルでも分岐予測が外れたらストールするのは同じ
逆に予測が当たるならテーブルの方が命令数減るぶんだけ速くなる。
実データが一種類ならBTBで常に予測が成功するからね 【速報】金券500円分タダでもらえる
https://pbs.twimg.com/media/D2zNwP2UwAARLRa.jpg
①スマホのApp Storeから「タイムバンク」をインストール（iOS、Android両バージョンあります）
②会員登録
③マイページへ移動する。
④招待コード→招待コードを入力する [Rirz Tu]（スペース必要無し）
コードを入力した方に600円もらえます
今なら更に500円ギフト券を貰った残高からただで買えます。
貰ったギフティプレモはAmazonギフト券（チャージタイプ）に交換できます（電子マネー払いにて）
数分で出来るので是非ご利用下さい >>1
Perlは鉄壁のセキュリティ
Perl最強伝説がまた証明された >>142
分岐羅列のほうがキャッシュミスヒット減るだろな。
一連のアドレスにあるから。 >>146
分岐するブロック全体の予測成功確率は何しようが変わらない
CPU上の予測リソースの使い方が変わるだけ
多段になると各分岐命令でストールが起こるため予測失敗時のペナルティが大きくなる 関数型言語のコンパイラ実装者だったら関数を多用した場合のパフォーマンスの出し方色々知ってそう >>1
そもそも、一つの言語でアプリケーションソフトを開発することに無理がある switch文で数値の連続性が高く、分岐先が多い場合コンパイラがテーブル化するのはそっちの方が速いからだよ ■
つまり
１、オブジェクト指向を取り入れて、さらに
２、関数型 取り入れたら、
こういう順番になる。 >>58
マルチスレッドが出来たら世界のエースクラスだな。 人間もC言語やPHPな気風を孵化して止まないモンは誰にも制御不能
つーか、そんな外的インタラプトはすべて排除します
これは、飼い主の尾っぽを振って御仕舞な犬じゃなく
狼、ウルフ言語といいませうか？ 犬リーマンで生を終えて満足できる「桁落ち」には使い熟せないと思う Cを自由自在に転がしてこそヒカル「PHP」
文脈の基礎の無いバーカが弄るな 「脆弱性」を読めないばかりか
間違った読み方をわざわざスタッフに教えていた医者がいた
普通、医者ならほぼ100%読める単語なのだが
なぜだかアンタッチャブルらしくその後も絶賛出世中
その地区の方々は本当にご愁傷様です >>144
ふつーにGPUを使っている例を教えてください！
GDCでもそういった内容の発表は過去に無かったと思います >>130
>バッファオーバーランは言語によってセキュリティが向上する部分だろ
Cコンパイラーがバッファーオーバーフロー・オーバーランのチェックをやってはいけない決まりはない（-fsanitize=undefinedか-fsanitize=signed-integer-overflow,-fsanitize=bounds,fsanitize=object-size,-fsanitize=vla-bound等の個別指定）
コンパイラがチェックをするのは当たり前すぎるが、そうした機能を知らない連中がセキュリティーが大変だと大騒ぎしている
言語の規格がサポートするしないに関わらず、アナライザーやチェッカーを使えば十分に排除できる（又は自前の共通マクロでチェック箇所をラップする）
言語指定のチェッカーはやり過ぎる嫌いがあるし、どうでも良いところに分岐を入れられるとシリアル化されて最適化が犠牲になる
Pythonのように完全に排除してしまうと、余計な命令が増えILP最適化が弱まるためパフォーマンスは悪化する
勝手にパフォーマンスを激減させるような命令を入れられるのは迷惑このうえない。記憶ではRustでもリリースモードでチェックをしないはずだし、チェックも完璧なはずはないので
油断してバグ（セキュリティかパフォーマンス）を入れる可能性はゼロではない
どの言語でもリグレッションテストを可能な限りやるだけなので、意図しない余計なアセンブリ言語がないぶんにおいてCのデバッグ時の簡易さは貴重だ >>161
Rustでは常に境界チェックが行われるそうだ
Rust の Index bounds check の性能影響を調べてみた
http://gifnksm.hatenablog.jp/entry/2016/06/01/010152
Rust の配列 (Vec<T> や [T] など) では、インデックスアクセス時に境界チェック (index bounds check) が常に行われます。
常に行われる、というのはビルドの種類 (リリースビルド・デバッグビルド) に依存しないという意味です。
とにかく安全性を重視する Rust らしい仕様であると言えます。
他のプログラミング言語に目を向けて見ると、常にチェックが行われるシステムプログラミング言語というのも珍しい気がします。
すべてがプログラム作成者の責任になる C では当然何のチェックも行われませんし、
安全なシステムプログラミング言語という意味で Rust と立ち位置が近い D では、
デバッグビルドの場合のみ境界チェックが行われます (リリースビルドでは行われない)。 >>163
ということはSPECTOR系に狙われやすいんだな 境界チェックの正否に関わらずCPUがメモリ先読みしているお陰でパフォーマンス低下が押さえられていたんだな >>163
>常に行われる、というのはビルドの種類 (リリースビルド・デバッグビルド) に依存しないという意味です。
本当にRustが見境なく全てのアクセスで「境界」チェックをしているのなら、有難迷惑と考える方が多いだろう
リリースモード（ビルド）では最適化レベルがopt-level=3かopt-level=2のいずれかのはずで、本来であればそうしたチェックは最適化されないといけない
Rustコンパイラは、境界チェックをO(1)に「最適化」するはずなので、全てに境界チェックをするというのは誤りだろう
--emit asmで見たら最適化でコンパイラが不要と判断したチェックは消されているはずだ。時間があったら試して見てみると良い（LLVM自体の基本機能のはずだ）
>>164 の言うようなSpectreの例はともかく、言語が裏で勝手に色々とやるのはセキュリティーやパフォーマンスのデバッグをする際には邪魔でしかない
https: //people.csail.mit.edu/vlk/spectre11.pdf
Rust doesn't optimize bounds checks that Go 1.11 does
https:// github.com/rust-lang/rust/issues/51709
さらにループが複雑化すると、Rustコンパイラは最適化をしないと考えるべきで、ペナルティを払う必要が出てくる可能性もある
Why is my Rust implementation of InsertionSort slower than my C version?
https:// stackoverflow.com/questions/30965257/why-is-my-rust-implementation-of-insertionsort-slower-than-my-c-version >>166
境界チェックではないが、Rustのオーバーフロー系のチェックは大昔からの問題を蒸し返しているだけで、これを持って最終解決策と主張するのには無理がある
https://github.com/nikomatsakis/rfcs/blob/integer-overflow/text/0000-integer-overflow.md
Rust, at least, does not have to worry about memory safety violations, but it is still possible for overflow to lead to bugs. Moreover,
Rust's safety guarantees do not apply to unsafe code, which carries the same risks as C code when it comes to overflow. Unfortunately,
banning overflow outright is not feasible at this time. Detecting overflow statically is not practical, and detecting it dynamically can be costly.
Therefore, we have to steer a middle ground.
Rustコンパイラがデフォルトでチェックのために分岐命令を追加するのは、パフォーマンス的にはのぞましくなく、誤ったチェックを自動的に入れる可能性も排除できない
例えるならCコンパイラのコンパイルオプション（-fsanitize=undefined）をデフォルトで有効設定にしたビルドを使うだけで狂喜しているだけだ そりゃCだろ、メモリ管理自分でやると簡単にオーバーフローやらかすｗ
数値計算系のFortoranとかは起こしようが無い >>166
Why is my Rust implementation of InsertionSort slower than my C version?
https://stackoverflow.com/questions/30965257/why-is-my-rust-implementation-of-insertionsort-slower-than-my-c-version
Test on C:
ARRAY SIZE: 100000
< counting_sort: 0.003602
< insertion_sort: 8.273647
< heap_sort: 0.017918
Test on Rust:
ARRAY SIZE: 100000
< counting_sort: PT0.039530982S
< insertion_sort: PT276.529915469S
< heap_sort: PT0.117946209S 一般論として、プログラミングにおいてコンパイラに最適化を任せるというのは日常的なことだ
可能な限りコンパイラの最適化を利用するのは良いし、自明で基本的な最適化はコンパイラに任せるべきだ
ただコンパイラやツールにも限界があり、本当にボトルネックがあるなら調査や分析、ボトルネック回避の修正が必要となる
言語の規格レベルでガチガチに制限されると自由度は下がるので、最適化できる箇所・範囲が狭められる
Cで単にチェックをしたいなら、-fstack-protector、-D_FORTIFY_SOURCE=2、-fsanitize=undefined等を指定すれば良い なんかオプションまで語り始める奴ｗｗｗ
こいつ前もこれ系のスレに出没してたやつと一緒だな 意味不明なランキングだな、C言語の脆弱性が多いって
世の中結局C言語で書いてる、Pythonでもなんでも この調査結果で
日本語プログラム言語ひまわりは脆弱性が全く存在しない
とはならんだろ ネットで使われる言語はハッキングの試みが多いから、より脆弱性が発見されやすいんでね？ 多分ここにコメした奴が使ってる言語と作ったソフトに脆弱性が多いと思うわｗ 境界のチェックなんてJavaでやられていることで有名だったと思うのだが…
なんでこうなるかな そもそも、C言語は安全装置をつけないかわりに高速で何でもできるってのが利点だから当然でしょ？
安全装置がついてるけれど遅くてできることも限られる言語と同列にされても
コンピュータ制御で簡単に飛ばせるができることが限られるドローンと、
操縦が超難しいけれど宙返りでもなんでもできるラジコンヘリの違いみたいに >>183
それでもRustは高速さを売りにしているところが違うのだが
どちらかというとC/C++は配管むき出しの工場しか作れない言語
C/C++で住宅をつくると住人がけがをしてしまう >>184
そのRustで高速さを追求したコードはCのSIMDライブラリーを使い、SIMDを使用していない（C言語で）コードしたプログラムのパフォーマンスに匹敵すると主張する連中がいるようだが
明らかにC++に慣れていないプログラマーがコードしたマルチスレッドプログラムに匹敵するパフォーマンスが出たと言われても説得力はない
C++で生ポインターを使うべきでない程度の至極当たり前のことを、できないという奇妙な前提で使いもしない生ポインターの危険性でC++を批判したり、優位点が一々チグハグな印象しかない
「R.E.S.F」「Rust Evangelism Strike Force」（Rust伝道攻撃部隊）に寄せられる最大の批判は、他の言語に対するありもしない批判にかまけて、
肝心の実装をするための時間を無駄にし、シンプルなC/C++ベースのコードのポートだけしかできていない点だ
LLVMはC++でコードされているわけで、危険なC++のコードに依存している段階で問題がある >>170
同じ「C」で始まるけど、コボルは堅固性最高
しかし、C言語は素早く処理できなければ意味のない「通信」に適した人工言語
開放性と柔軟性があるがため、最初に決めるべきものはキッチリ決めとかないと、後はシラネーよ
コボルは、実に調教と馴致が簡単に出来る
C馬さんて、ジャジャ馬、調教がかなり難しい >>184
もしかして、テンプレートとかも知らない、かわいそうな子？ ■ このスレッドは過去ログ倉庫に格納されています
