2009-05-27 11 views
4

Delphi 2009ではsqrtがまだ遅いですか?Delphi 2009ではsqrtがまだ遅いですか?

古いトリック(ルックアップテーブル、およその関数)は依然として有用ですか?

+0

私はDelphiを推測していますか?言語を –

+0

にしてください "...まだ...":どのバージョンのDelphiと比較していますか? –

+0

実際、私はcについて話していました。 答えはおもしろいので、私は別のCバージョンを投稿します – Mykelyk

答えて

5

実際に大きな数字の小さなセットを扱う場合、ルックアップテーブルは常により高速になります。あなたが小さな数字の大きなセットを扱っている場合は、遅いルーチンでさえ、大きなテーブルを維持したほうが速いかもしれません。

私は(SQRTが配置されている)はSystem.pasで見て、Fastcodeプロジェクトからライセンスを受けてブロックの数がマークされている一方で、SQRTではありません。実際には、アセンブリコールをFSQRTにするだけなので、ほとんど変更されていない可能性があります。だから、ある時点で比較的遅い場合は、まだまだ遅いです(あなたのCPUは今より高速で最適化されていますが...)

あなたの使い方とテストを見てみることをお勧めします。

+1

FWIW、Fastcodeには私が見つけることができるSQRTバージョンがありません。 –

+0

私は、FSQRTまたはルックアップテーブルを使用することよりも最適化があるとは考えていません。 –

+0

私の用法は物理シミュレーションゲームです – Mykelyk

3

多くの月前にソートベクトルとの距離を計算したアプリがありました。 un-sqrt-edの値で並べ替えることは同じだったので、私はそれをすべてスキップしました。距離^ 2でソートして時間を節約しました。

+1

はい、私はこの種のことを何度もやりました。非常に頻繁に距離の代わりに距離^ 2で作業することができます。 –

+1

。ドットプロダクトを比較することは、マグニチュードを比較することと同様に優れています。 (悲しいことに、比率では機能しません) – zyndor

1

私の答えは、最も簡単な方法を最初に適用し、後で最適化することです。それが最初の場所ですごく速くなる必要がないときに操作を速くすることは愚かなようです。

私の答えは効率に関するものであり、あなたの質問の歴史的側面ではないからです。

+0

基本的に、これはまったく答えではありません。 – Argalatyr

+0

彼の質問には2つの部分があります.1つは効率に関するもので、もう1つは機能の歴史的性質に関するものです。彼は明らかに既存の実装を最適化するつもりはないので、パフォーマンスを許容できるかどうかを最初に試してみてはどうでしょうか。 – Soviut

関連する問題