C++相談室 part150
■ このスレッドは過去ログ倉庫に格納されています
>>510
江添亮のブログで関連する提案や議論が取り上げられているので順番に読んでみたらいいと思う。
https://cpplover.blogspot.com/search?q=char8_t
具体的にこれが理由と言えるひとつの理由があるわけではないけど、
やってみたらやっぱ要るわ……という雰囲気っぽいかな。
要するに文字列をナメてたんだろう。 charにutf8突っ込むだけでunicode対応できるとか考えるやつがようやく淘汰されてきてありがたい そもそも「Microsoftを利する提案」てなんだよ
C++は別にアンチMSじゃないだろ std::size(u8"あいうえお" - 1)みたいな感じですかね。 std::u8stringとかC++は規格に出すのが遅い >>514
W3CもアンチMicrosoftではないのだけど、会員がIT業界の人たちなので、結局のところ、如何にしてMicrosoftを落とすか討論する場所になってました。 >>508
どう利するわけ？
windowsの中はutf8じゃないよ >>519
>>508がアンチMicrosoftなだけじゃないかな enum class とか、MS起源の機能なんていくらでもあるんだけどな >>504
そのあたりも増加原因になるのはわかる
でもどちらにしろlibgccのリンクとは無関係では？ >>512
下のみたいなノイズだらけのクソブログを挙げるな
もっとマシなのあるだろ そうかな
utf8をコア仕様にいれたら「文字とは何かを理解する」ってのは
ちょっと同意できないな constexprがあるので、エンコーディングを型に組み込んでしまっても、困ることは全くない。
C++のお作法になじんでいれば、お得な事しかない。 UTF8ベースにしたらどうやって1文字ずつ処理するの？めんどくさい？ >>512
下のサイト的に言えば、誰もが
固定長に数値が収まるという夢を見た愚か者たち
なので、必要悪な気はするな >>531
code point単位なら結局utf32にして数える(部分的に可能)
面倒なのはgrapheme clusterから上
もう土方レベルが扱える代物じゃないね 内部では utf-32 ベースで処理して、出口入り口で utf-8 に／から変換するものだと思いますが… >>528
リッチーならともかくカーニハンは見てる可能性 >>535
色んな文字コード (符号化) を扱うときは出入口で変換する方法は妥当な選択だと思うけど、
UTF-32 を中心に据えるのが良いかは一概に言えるものでもないでしょ。
たとえば Windows API がいう Unicode は UTF-16 なわけだし、
外部とのデータのやりとりで内部用の符号に変換する処理が入るのは仕方がないにしても
API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
UTF-16 に統一した方全体としては楽じゃない？
サロゲートペアの扱いが面倒くせぇとかいうのと天秤にかけたとしても
Windows では UTF-16 から離れられない。
結局のところ実行環境とかフレームワークとかの都合に縛られるから
(内部用の符号として UTF-32 が優秀なことは承知しているが)
そのへんの規約とか習慣に従うしかしゃーない。 出入り口から内部処理まで出来る限りutf-8で統一して処理するのが
トラブルが少なくて済む(個人の感想です) それは文字列としてだけ扱って文字単位(code point単位)の操作しないときでしょ
あるいは小難しいところは全部ライブラリに投げてるとかね >>539
＞たとえば Windows API がいう Unicode は UTF-16 なわけだし、（略）
＞API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
＞UTF-16 に統一した方全体としては楽じゃない？
Windows では UTF-16 を使うといっても、実際に変換しなければならないのは、ファイル名・パス名を扱うときだけですし、
UTF-16 も可変長の部分があって扱いにくいので、私なら UTF-32 で楽したいと考えますね UTF-32でも結合文字と異体字セレクタはある
結局ライブラリに投げるでしょ、ならどれでも同じじゃね？ マルチプラットフォームのアプリじゃ内部はUTF-8にする場合が多いけどな
なぜならUTF-8にはバイト順問題がないから
どのみち一文字表すのに複数のコードポイントが必要なんだからUTF-8、16、32のどれを使っても言語処理の手間は同じだ
「イングランドの旗」絵文字なんてコードポイントで7要素も必要なんだぜ マルチコアの高速化と同様に
32bitのCPUで16bitを扱うと2倍速
64bitのCPUで16bitを扱うと4倍速
みたいにならないんですか？ 32ビットと64ビットで二倍の時間になるのではなく、たいてい4倍になりますよ。 文字列関連の処理はだいたいメモリアクセスかIOがボトルネックなので、単純にサイズが 増えればその分遅くなるよ >>546
simd使えばそれに近づくだろうけど
そうでなければシリアルに計算されるだけなのでほぼ変わらない
大量のデータを処理する場合はメモリ効率の点で速くなるかもしれない
しかしintへの拡大変換が入るので演算自体は遅くなる方向
まぁ自分でベンチとってアセンブラ眺めてみたらいい
かなり環境依存・実装依存なんだから人にきいてもあんまり意味ない
4倍になる人とかいるらしいしw SIMDなら32bit CPUとか64bit CPUとか関係ないし >>556
そのベンチどっかに貼ってみて
wandboxとか 64bitを使っても、大部分のソフトウェアは速くも良くもならない事が知られている。
16bitから32bitの時には急激に多くのメモリが使えるようになって劇的にソフトウェア
が作り易くなったのと対照的。
メモリ容量に関してはたいていのアプリでは32bitでも既に十分。
速度に関してはそもそもCPUが扱えるデータビット数を多くしても滅多に速くならない。
速くなるのはグラフィックで単純なBitBLTを行うような場合のみ。
縮尺や回転が入るだけで64BITの効果は通常、生かせなくなる。 >>554
RGBA計算も、(SIMDを使わずに)単純にデータバスが64BITになっただけでは速く出来ない。
なぜなら、R,G,B,Aはそれぞれ1バイトだから1バイトずつの計算するしかないため。
SIMDを使う場合は、CPUの種類によっては、SIMD自体のベクトルの要素数が倍になるため、高速化できる可能性はある。
ただしそれは、整数命令が64BIT化されたこととは直接関係ない。
SIMD命令のベクトルの「次元」が上がったかどうかの問題。 >>560
なんでわざわざ関係ないことを書いてわざわざ混乱させようとするかなあ 64ビットの演算1回の時間で、32ビットの演算4回出来るんですよ。 >>547
なりません。
ならないからこそ、GPGPUのようにマルチコア化が進められています。
SIMD命令も扱いにくいので、マルチコア化が適しています。
例えば、3Dのレイトレーシングなどは、SIMD化することはとても難しい
のですが、マルチコア化は比較的容易です。
人工知能のニューラルネットワークの計算はSIMD化し易い部分もあります。
しかし、300コアなどのマルチコアと、8要素のSIMD命令では、
前者に軍配が上がり易く、しかも、コア数が増えてもプログラムの修正が
ほぼ不要なので、マルチコアの方がSIMDより好まれます。
ただし、命令自体の速度がx86系は速いため、どちらが実際に速いかは
単純ではありませんが。 >>562
CPUの一般論としてそんな事実は有りません。
あるなら具体的に書きましょう。 これ最初に気が付いたのは、固定小数点は速いらしいというのを見て、いろいろやってみたら、特に早いことは無くて。
じゃあ何が影響するかというと、単にビット幅だったんですよ。
floatとint32_tは同じ、doubleとint64_tは同じ。
つまり、アキュムレータの性能はあまり関係なくて、バス幅とキャッシュがすべてなんですよ。
じゃあ32ビット2回分が64ビット相当になるかというとそうでもなくて。
たいてい4回分で64ビット相当になるんですね。 >>558
まさか！
2^32 bit 空間が狭すぎる、というのは windows XP の頃から問題になっており、2^64 bit 空間は必然でした
＞メモリ容量に関してはたいていのアプリでは32bitでも既に十分。
個々のアプリ単体ではそうであっても、個々のアプリを複数稼動させる OS では32bit では足りないのでは？
そして 64bit OS に対応した 64bit アプリの存在も必要でしょう あと、僕はベンチマークのカタログとしてVSのテストエクスプローラ使ってますよ。
テストケースを一つずつ呼び出せるので大変便利です。 何をして速くなったと言っているのか不明なのに自分でってw >>570
測るのは自分でやるからベンチのソース見せてよ
比較実験やるにあたって環境も実装も変えたら比較にならないんだしさ
ここで逃げたらかなりださいと思うよ >>573
そっちが出してくださいよ。
アセンブラ見ると速度がわかる奴。 めんどくさいんですよ。
アセンブラ見れば速度がわかると言ってる時点で、僕は得るもの無いじゃないですか。
何か作業を手伝ってくれるならわかりやすく提示しても良いんですが。
作業を手伝ってもらうのに、色々教えないといけないなら、やっぱりめんどくさい。 64bit命令を使うと4倍以上速くなるのは
64bitの乗算くらい
64bit加減算もCPUによっては数倍にはなる
それ以外は特殊な場合のみ intとint64_tで適当なfor分で配列計算やらせてみればわかる。
手元じゃint64_tのが若干遅い >>569
それは当たり前で、マシンには4GB以上のメモリが乗っているので、32BIT
では、OSレベルでは扱いにくい。
多くのプログラマにとって大事なのは、個々のアプリの問題だから、
OSレベルの話は関係ない。、
また、Windows OSがメモリーを食いすぎているという問題もある。 >>580
補足すれば、グラフィック用のRAMは大きくなりがちで、最近のWindowsでは、
1つのWindowに仮想VRAMを割り当てているから、アプリが起動するたびに
グラフィック用になかなか大きなメモリーを消費する。
それと、ブラウザで複数のタブを開いている影響。
あれもグラフィックのレンダリング用に大量のメモリーを食っているのかもしれない。 >>577
他人を説得するつもりがないなら不特定多数が集まる場で自論を展開せず、馬鹿なこと言ってるなフフッて一人悦に入ってればいいんでない？ >>580
今は、見えないものまで含めれば50個のプロセスが動いているなんてことは当たり前になっている。
だから、個々のプロセスが80MBのメモリしか使って無くても、合計すれば4GBになる。
さらにファイルバッファや、OSが高速化のためにさまざまなキャッシュ的なデータを保持している。
しかも、ファイルバッファやキャッシュはいくらあっても不足する時代となった。
ブラウザがページを記録するためのキャッシュも必要だ。
そういう訳で、アプリが80MBしか使って無くても、OS全体では4GBではメモリが不足する。
というわけで、4GBを超えるメモリが必要となっている。
タスクマネージャーで見ていても、個々のアプリは、多くても数百MB程度のものが多い。
ファイル高速検索ツールなんかが、1.6GBも使っていたりするが、それは特殊。
だから「特殊なものを除いては」今のアプリが2GBを超えるメモリーを必要とすることは稀、だと言っている。 32bit Windowsが4GBまでなのはWindowsの仕様であってCPU自体はそんな縛りは無いし >>587
典型的には、32BIT mode でも、PAE サポートによって OS は 4GB を超える
メモリーを扱えるね。 64GBまで使えるようになったのPentium Proからだぜ？ｗ
Klamathより前！！ >>591
いや、彼は正しいことを言っている。
あなたがIntel CPUの仕様を詳しく知らないだけ。
PAEという仕組みなどで32BITモードでも4GBを超える物理メモリーを扱うことができるようになっていた。 QZは女なのだろうか。
ショックかも知れないがはっきり言えば、本質的に物事が正確に理解できていないようだ。 8bit CPUは256Bしか扱えないと思ってる人いる？ 16bitのCPUでも16bitアドレスの最大値である64KBを超えて1MBもアクセスできていたからな。 >>597
16BIT CPU であった 8086は、16bit アドレスを超える範囲は、セグメントレジスタ
と合わせた seg:ofs の形式の far pointer を使わなくてはならならず、
単純に扱えるのは16BITまでで、16BITを超えた範囲では、seg レジスタの値を
足していかないといけなかった。しかも、segがアドレスの上位16BITだったなら
まだしも、16バイト単位のアドレスだったので、segレジスタに入れる値を計算
するのがとても重くなってしまっていた。
ところが、Z80 などの 8BIT CPUは、普通に 16BIT レジスタの
HL や DE, BC, IX, IY をもっており、8086 と比べれば扱いは容易だった。
その意味では、8086は、メモリーアクセスに関してはZ80と同じくらいしか
能力を持っていなかった。
それで8086の16BITモードでは限界が来て32BITモードのOSが待望された。
そしてMacのGUIを真似た機能を持っていたこととも合わせて32BITモードで
動いたWin95となった。
ただし、このような状況は64BIT化に関しては全く無い。 そりゃまあ、64bitCPUがすでにいきわたっていてOS変えるだけで対応できたからね
WINAPIだって16→32のコンパイルはまず動かないけど32→64なら普通は動く
DOS時代のUMBみたいなみみっちい事態にならなくてよかったじゃん 86用コンパイラでnearとfarの他にhugeが有ると知らず、無限ループ作ってOSごと来なくなったあの頃 long longとint64_tの違いってlong longは環境によって64bitじゃなくなるけどint64_tは常に64ってことですか？ |
| 彡⌒ミ
＼ (´･ω･`) またhugeの話してる・・・
(| |)::::
(γ /:::::::
し ＼:::
＼ 32bitの環境で32bitの境界を超えるような64bit値の計算ってどうやって実現してるの？ cpuに命令なければソフト的にやるに決まってんじゃん ちなみに32bitの掛け算の答えに64bit必要ってわかってない人多いよね
同様に64bitなら128bit ■ このスレッドは過去ログ倉庫に格納されています
