金融系メインフレームはなぜCOBOLをつかうのか (original) (raw)

くまぎ @kumagi

「COBOLじゃないとお金の計算は狂うからCOBOLにしか金融系は任せれない」というの、例えばPythonで金融の計算をすると具体的にどういう狂い方するんでしょう?

Miura Hideki @miura1729

@kumagi 1円以下を扱うと、普通は浮動小数点数になるからそこで誤差が生じるけど、COBOLは10進演算で行うことと言語仕様で決まっているから大丈夫という話だと思います。固定小数点とかでライブラリ書けばいいんでしょうが、それも手間だし。

くまぎ @kumagi

@miura1729 Python含む他の言語には信頼できる固定小数点ライブラリが無いと言う事ですかね?

SODA Noriyuki @n_soda

@kumagi @miura1729 やればできるけど、COBOLみたいに言語のデフォルトになってるのに比べて記述が面倒くさいし遅いって話です。汎用機とかエンタープライズ向けサーバCPUには10進演算命令もあって、COBOLコンパイラならそういう命令を使ってくれるんじゃないかな。

Miura Hideki @miura1729

@kumagi すみません、間違えました。10進演算ライブラリです。遅くていいならできるでしょうが、COBOLみたいに専用命令用意して徹底的に高速化したものはなかなか無いんじゃないのではないでしょうか?

Miura Hideki @miura1729

@n_soda @kumagi ですね。10進演算命令はマイコンにもありますね。6809にはDAAという命令があります。86系にもありそうな気がしますが、良くわからないです。

SODA Noriyuki @n_soda

@kumagi @miura1729 例: POWER6 geocities.jp/andosprocinfo/…SPARC64 X geocities.jp/andosprocinfo/…

Takafumi Ikeda @ikeike443

@n_soda @kumagi @miura1729 僕もこの程度の理解ですね。

SODA Noriyuki @n_soda

@miura1729 @kumagi マイコン系やx86の場合はBCD命令群ですね。x86 の例: en.wikipedia.org/wiki/Intel_BCD… エンタープライズ向けCPUが持つ命令は、BCDより遥かに頑張ってる感じなんだと思います。

数ヶ月間貧乏だけど心は萌え @kokorohamoe

@n_soda @kumagi @miura1729 いやBCDライブラリもありますし数百万桁のPIEの演算とかもCでやるわけで 数百万桁の精度のPIEが計算できるのになんだろうな。 早い遅いはCPUの速さもあるのでなんとも あたりまえですが高精度の科学技術計算もしてますので

数ヶ月間貧乏だけど心は萌え @kokorohamoe

@n_soda @kumagi @miura1729 というか 演算精度が要求されるときにCPU組み込みのdoubleは まず使いません。 そもそも 0.01あたりですでにご差が出るので

Miura Hideki @miura1729

@n_soda @kumagi なるほど、任意桁数をサポートしているとかでしょうか。今はネットとかでお金の動きが激しいし、ドル円レートとか必ず小数点数以下の精度が必要になるので昔よりもっとこの手の計算が重要なんでしょうね。

SODA Noriyuki @n_soda

@kokorohamoe @kumagi @miura1729 geocities.jp/andosprocinfo/… に書いてあるようなハードウェアアシストは、x86にはなかったと思います。(それとも最近はあるの?

SODA Noriyuki @n_soda

@miura1729 @kumagi こういうCPUが生き残ってるのは、銀行とかそういうところなので、そっちのニーズに合わせた機能があるんでしょうね。

くまぎ @kumagi

@n_soda @kokorohamoe @miura1729 スピードが必要なのってシングルスレッドで朝までにバッチが突き抜けないように書く必要があるからじゃないかと思ってるのですが、並列化みたいな非決定的な演算は信用できないからとかでしょうか。それとも本質的に並列化不可能?

Miura Hideki @miura1729

@n_soda @kumagi こういう話は地味だけどお金になるから表に出ないところですごく極めているんでしょうね。個人的には関わりたくないところですが。

SODA Noriyuki @n_soda

@kumagi @kokorohamoe @miura1729 大量にあるレガシーなアプリを、再コンパイルだけで速くしたいからでしょう。たぶんあまりに一杯あって、いろんなしがらみの塊なので、書き換え自体が困難かと。

SODA Noriyuki @n_soda

@miura1729 @kumagi デスヨネー>関わりたくない。ほんのちょっと変更しただけでも、尋常じゃないテスト工程の作業量とか要求されそうです。

くまぎ @kumagi

@n_soda @kokorohamoe @miura1729 技術的負債でいつか死ぬか、途方もないコストを払ってスクラッチするかという話ですか…。関わりたくないですね…。

Miura Hideki @miura1729

@n_soda @kumagi 変更するコード行数と提出する書類の枚数が大体同じとかそんな感じでしょうかね。変更文字数と書類の枚数が大体同じだったりして (震え声

Miura Hideki @miura1729

@kokorohamoe @n_soda @kumagi FORTRAN使いのナンバークランチャー達は誤差が出るのが前提で不思議な職人技で誤差を抑え込んでいる(または誤差の上限を把握している)というイメージがあるのですが、そうでもないものなのでしょうか?

SODA Noriyuki @n_soda

@miura1729 @kokorohamoe @kumagi その認識で合ってます。 amazon.co.jp/dp/4320013433/ とかに、わりとまとまっていたと思います>職人芸。(斜め読みしかしてません…

中村 実 @nminoru_jp

@n_soda IA-32時代には二進化十進数補正命令がありましたよ。AMD64がlong modeを導入した時に無効にしましたが。

Miura Hideki @miura1729

@n_soda @kokorohamoe @kumagi 良書っぽいですね。紹介ありがとうございます。ご存じだとは思いますが、個人的にはこれですかね docs.oracle.com/cd/E19957-01/8…

中村 実 @nminoru_jp

@n_soda ただある時期のIntel CPUにはこの命令の一部にエラッタが出て、しかもマイナーな命令だったためかリコールされることもなく、市場に間違った結果を返すx86 CPUが溢れて、この命令使ったソフトが作れなくなったとか。datasheetarchive.com/files/intel/de…

1 2 次へ