下位互換性
これが、既存の言語/ライブラリ/ ISA / etcで動作を維持する最大の理由です。
Javaからフロートを取り出したらどうなるかを考えてください。Libgdx(および他の数千のライブラリとプログラム)は機能しません。すべてを更新するには多くの労力が必要になります。多くのプロジェクトではおそらく何年もかかるでしょう(後方互換性を破るPython 2からPython 3への移行を見てください)。そして、すべてが更新されるわけではなく、メンテナーがそれらを放棄したために、おそらく更新するよりも手間がかかるため、またはソフトウェアが想定されていたものを達成することができなくなったために、いくつかのものが永遠に壊れますする。
性能
64ビットの倍精度はメモリの2倍の時間がかかり、ほとんどの場合32ビットの浮動小数点よりも処理速度が遅くなります(非常にまれな例外は、32ビットの浮動小数点機能がほとんどまたはまったく使用されないため、最適化するための努力が行われない場合です) 。特殊なハードウェア用に開発しているのでない限り、近い将来これを経験することはありません。)
特に重要なのは、Libgdxはゲームライブラリです。ゲームは、ほとんどのソフトウェアよりもパフォーマンスに敏感になる傾向があります。また、ゲーム用グラフィックスカード(FireProやQuadroではなく、AMD RadeonやNVIDIA Geforce)は、64ビットの浮動小数点パフォーマンスが非常に弱い傾向があります。Anandtechの厚意により、倍精度のパフォーマンスと、一部のAMDおよびNVIDIAのトップゲーミングカードの単精度のパフォーマンスを比較する方法は次のとおりです(2016年初頭)
AMD
Card R9 Fury X R9 Fury R9 290X R9 290
FP64 1/16 1/16 1/8 1/8
NVIDIA
Card GTX Titan X GTX 980 Ti GTX 980 GTX 780 Ti
FP64 1/32 1/32 1/32 1/24
R9 FuryおよびGTX 900シリーズはR9 200およびGTX 700シリーズよりも新しいため、64ビット浮動小数点の相対的なパフォーマンスは低下していることに注意してください。十分に遡ると、R9 200シリーズのような1/8の比率のGTX 580が見つかります。
パフォーマンスの1/32は、時間の制約が厳しく、大きなdoubleを使用してもあまり利益が得られない場合に支払う大きなペナルティです。