我所做的Java和C++性能测试
今天闲得无聊，突发奇想，做了一个Java和C++的性能对比测试。
?
1 测试方法
? 很简单的，就是分别让Java程序和C++程序做很多次的整数和浮点数运算，然后测量测试代码段的运行时间。C++代码中使用Windows函数QueryPerformanceCounter() 获取CPU的高精度计数值，测试开始前后分别获取一次计数值，使用Windows函数QueryPerformanceFrequency()获取运行频率，前后的计数差值除以频率就得到了运行时间。为了使时间测量基准一致，在Java程序中通过JNI去调用这两个Windows函数，测量Java程序的运行时间。
? 下面分别给出代码。
?
2 C++测试代码
?
?
?3 Java测试代码
3.1 测试代码
?
?
?3.2 实现时间测量的代码
?
As for articles on Java's floating point arithmetic, I guess you're referring to something like this: How Java's Floating-Point Hurts Everyone Everywhere. That's from more than a decade ago, and the statements in it don't hold anymore now.
That reference is really a wild guess. NO, it's not.
http://blogs.oracle.com/jag/entry/transcendental_meditation
a simple google on "java sin cos slow" can generate a lot of interesting entries, especially in the game arena, so it should be classified as "well known".
While I am saying java sin() is slower than C version, I am not saying in general java is slow, did I?
In fact, if you can make java sin() as closely fast as C, I would take it. I did quite some coding on how to make those special functions as fast as possible, such as gamma and log gamma. It's just hard. It's so hard that sometimes people accept the inaccuracy as the cost.
I've done a lot performance tunings as well, and have seen so many cases for premature optimization. The most common case is that people don't understand the problem itself and still try to optimize/profile it.
As for articles on Java's floating point arithmetic, I guess you're referring to something like this: How Java's Floating-Point Hurts Everyone Everywhere. That's from more than a decade ago, and the statements in it don't hold anymore now.
That reference is really a wild guess. NO, it's not.
http://blogs.oracle.com/jag/entry/transcendental_meditation
a simple google on "java sin cos slow" can generate a lot of interesting entries, especially in the game arena, so it should be classified as "well known".
While I am saying java sin() is slower than C version, I am not saying in general java is slow, did I?
In fact, if you can make java sin() as closely fast as C, I would take it. I did quite some coding on how to make those special functions as fast as possible, such as gamma and log gamma. It's just hard. It's so hard that sometimes people accept the inaccuracy as the cost.
I've done a lot performance tunings as well, and have seen so many cases for premature optimization. The most common case is that people don't understand the problem itself and still try to optimize/profile it.
James Gosling的文章大意就是为了在平台的浮点处理器中保持[-pi/4, pi/4]范围外数值可以获得符合jvm规范精度要求的计算结果，java先进行了精度处理，再使用fsin指令。所以比cpp更精确，但也要慢一些。
这话题已经从cpp和java性能对比转移到cpp和java的sin()实现对比上了。我相信广大同学还是比较想听听跳出楼主这段测试程序之外的，对cpp和java的性能评价。挖了个坑，请撒迦同学一跳。奸笑ing……
Yeah, you can search Google and get a lot of nonsense as well, that's not convincing enough. All we need is solid evidence, which is easier to get by reading source code and running "macro benchmarks" instead of searching Google.
The post you quoted from James Gosling was telling you how sin() and cos() are implemented in HotSpot. But that's their way of doing it, for a tradeoff between performance and Java conformance.
Pick a "sin() in C" implementation that satisfies you, and replace the sin() implementation in HotSpot, and there you've got what you want.
sin() and cos() are intrinsic functions in HotSpot; calling them wouldn't incur any JNI invocation overhead -- JNI would be too slow for this kind of stuff.
If you'd like to give a shot at this, a few of the places to look for would be:
hotspot/src/share/vm/classfile/vmSymbols.hpp
如果把java代码优化一下下，速度会提升会超出你的预料。不同的JVM运算速度的差别很大。