Question

这里我有Java和C代码尝试使用CAS进行原子增量操作。
将长变量从0增加到500,000,000。
C：所用时间：7300毫秒
Java：拍摄时间：2083毫秒
任何人都可以仔细检查这些结果吗？因为我简直无法相信他们。
感谢

Java代码：

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

public class SmallerCASTest {

    public static void main(String[] args){
        final long MAX = 500l * 1000l * 1000l;
        final AtomicLong counter = new AtomicLong(0);

        long start = System.nanoTime();
        while (true) {
            if (counter.incrementAndGet() >= MAX) {
                break;
            }
        }

        long casTime = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start);
        System.out.println("Time Taken=" + casTime + "ms");
    }

}

C代码：

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define NITER 500000000


int main (){
   long val = 0;     
   clock_t starttime = clock ();
    while (val < NITER){
      while (1){
        long current = val;
        long next = current+1;
        if ( __sync_bool_compare_and_swap (&val, current, next))
            break;
      }
     } 
   clock_t castime = (clock()-starttime)/ (CLOCKS_PER_SEC / 1000);
   printf ("Time taken : %d ",castime);
}

run.sh

#!/bin/bash

gcc -O3 test.c -o test.o
echo -e "\nC"
./test.o
javac SmallerCASTest.java
echo -e "\nJava"
java SmallerCASTest

其他细节：

System : Linux XXXXXXXXX #1 SMP Thu Mar 22 08:00:08 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

gcc --version:
 gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)

java -version: 
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

Answer 1

您正在比较苹果和橙子，我相信您的预期。 java版本是真正的CAS，如果C版本使用我在java synchronized表单中调用的内容，则会在失败时重试。

有关详细信息，请参阅this question。

请参阅this answer该问题以支持叙述A full memory barrier is created when this function is invoked，即在java术语中，这是synchronized来电。

尝试使用_compare_and_swap的方式与AtomicLong使用其等价的方法相同，即旋转函数，直到值更改为您想要的值。

<强>加了：

我找不到与Java AtomicLong等效的确定C ++，但这并不意味着没有一个。从本质上讲，任何时候任何线程都可以更改AtomicLong，只有其中一个成功。但是，更改将是一致的，即更改将是一个或另一个线程更改的结果，它不会是两者的组合。如果线程A尝试将值更改为0xffff0000（或等效的64位数），而线程B尝试更改为0x0000ffff（同上），则结果将两个值，更具体地说，它将< strong>不是0x00000000或0xffffffff（除非当然涉及第三个线程）。

基本上，AtomicLong除此之外完全没有同步。

Answer 2

编辑事实上，正如你所指出的，java似乎使用CAS操作实现incrementAndGet。

我的测试似乎表明C和Java版本具有大致相同的性能（这是有道理的，因为耗时的部分是原子而不是java或C编译器设法做的其余部分的优化）。 / p>

所以在我的机器（Xeon X3450）上，java版本需要大约4700毫秒，C版本大约4600毫秒，使用__sync_add_and_fetch（）大约3800毫秒的C版本（建议可以在这里改进java而不是实现所有的在CAS之上的原子操作。）

java版本是


java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.4) (6b24-1.11.4-1ubuntu0.10.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

GCC是4.4.3，x86_64。

操作系统是Ubuntu 10.04 x86_64。

所以我只能得出结论，在你的测试中看起来有点可疑。

Answer 3

因为Java很棒吗？

java版本每个循环需要4ns。那是对的。无竞争CAS实际上是CPU本地操作，它应该非常快。（编辑：可能不是4ns快！）

Java通过积极的运行时优化实现了这种速度，代码被内联并成为几个机器指令，即尽可能快地在汇编中手动编码。

如果gcc版本无法内联函数调用，那么每个循环的开销很大。

Java CAS操作的执行速度比C等效的快，为什么？

3 个答案: