Стоимость блокировки в .NET vs Java

Я играл с Disruptor framework и его порт для платформы .NET и нашел интересный случай. Может быть, я полностью пропущу что-то, поэтому я ищу помощь всемогущего сообщества.

        long iterations = 500*1000*1000;
        long testValue = 1;

        //.NET 4.0. Release build. Mean time - 26 secs;
        object lockObject = new object();
        Stopwatch sw = Stopwatch.StartNew();
        for (int i = 0; i < iterations; i++)
        {
            lock (lockObject)
            {
                testValue++;    
            }
        }
        sw.Stop();

        //Java 6.25. Default JVM params. Mean time - 17 secs.
        Object lock = new Object();
        long start = System.currentTimeMillis();
        for (int i = 0; i < iterations; i++)
        {
                synchronized (lock)
                {
                    testValue++;
                }
        }
        long stop = System.currentTimeMillis();

Кажется, что приобретение блокировки в сценарии с потоком signle в .NET стоит всего на 50% больше, чем на Java. Сначала я подозрительно относился к таймерам, но несколько раз я запускал один и тот же тест с результатами только упомянутых выше средних значений. Тогда я был подозрителен к синхронизированному блоку кода, но он делает не более, чем просто команды monitorenter/monitorexit байт кода - то же самое, что и ключевое слово lock в .NET. Любые другие идеи, почему использование блокировки так дорого в .NET и Java?

Ответ 1

Да, похоже, что использование незатронутой блокировки в .NET более дорогое, чем в Java. (Результаты на моем нетбуке немного более драматичны.)

Существуют различные аспекты производительности, которые будут быстрее на одной платформе, чем другие, иногда до такой степени. HotSpot JIT и .NET JIT довольно радикально различаются по-разному - не в последнюю очередь потому, что .NET JIT работает только один раз на IL, тогда как HotSpot может оптимизировать все больше и больше, поскольку конкретный фрагмент кода запускается все чаще.

Важный вопрос: действительно ли это важно. Если ваше приложение для реальной жизни тратит на это действительно незаслуженную блокировку 500 миллионов раз каждую минуту, это, вероятно, важно - и вы, вероятно, должны немного изменить свое приложение. Если ваше приложение для реальной жизни действительно выполняет реальную работу внутри замка (или между приобретениями блокировки), то это вряд ли станет настоящим узким местом.

Недавно я обнаружил две .NET gotchas (часть первая; часть вторая), с которым мне приходится работать, когда я пишу "библиотеку системного уровня", и они существенно повлияли бы на то, что приложение много раз анализировало дату и время, - но этот вид микро- Оптимизация редко стоит того, чтобы делать.

Ответ 2

Первое, что нужно помнить о микро-тестах, - это то, что Java особенно хорошо разбирается и устраняет код, который ничего не делает. Я обнаружил, что снова и снова Java делает бессмысленный код быстрее, чем любой другой язык.;)

Если Java удивительно быстро по сравнению с другим языком, первый вопрос должен быть; Использует ли код что-нибудь отдаленно полезное? (или даже выглядеть так, как это может быть полезно)

Java имеет тенденцию к циклическому развертыванию больше, чем раньше. Он также может сочетать замки. Поскольку ваш тест не оспаривается и что-то делает, ваш код похож на что-то вроде.

for (int i = 0; i < iterations; i+=8) {
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
    synchronized (lock) {
        testValue++;
    }
}

который становится

for (int i = 0; i < iterations; i+=8) {
    synchronized (lock) {
        testValue++;
        testValue++;
        testValue++;
        testValue++;
        testValue++;
        testValue++;
        testValue++;
        testValue++;
    }
}

поскольку testValue не используется.

for (int i = 0; i < iterations; i+=8) {
    synchronized (lock) {
    }
}

и, наконец,

{ }

Ответ 3

Является ли переменная 'testValue' локальной для метода? Если это так, возможно, что JRE обнаружил, что блокировка не нужна, поскольку переменная является локальной для одного потока и поэтому не блокирует вообще.

Это объясняется здесь.

Чтобы показать, насколько сложно определить, какие оптимизации JVM решает сделать - и когда он решает это сделать - изучите эти результаты от запуска вашего кода три раза подряд:

public static void main(String[] args) {
  System.out.println("Java version: " + System.getProperty("java.version"));
  System.out.println("First call : " + doIt(500 * 1000 * 1000, 1)); // 14 secs
  System.out.println("Second call: " + doIt(500 * 1000 * 1000, 1)); // 1 sec
  System.out.println("Third call : " + doIt(500 * 1000 * 1000, 1)); // 0.4 secs
}

private static String doIt(final long iterations, long testValue) {
    Object lock = new Object();
    long start = System.currentTimeMillis();
    for (int i = 0; i < iterations; i++) {
        synchronized (lock) {
            testValue++;
        }
    }
    long stop = System.currentTimeMillis();
    return (stop - start) + " ms, result = " + testValue;
}

Эти результаты так трудно объяснить, я думаю, что только инженер JVM может помочь пролить свет.

Ответ 4

Помните, что оба они очень быстры; мы говорим о 50 циклах процессора для блокировки-чтения-записи-разблокировки здесь.

В Java я сравнивал его с симулированным имплантом в незащищенном случае

volatile int waitingList=0;

    AtomicInteger x = new AtomicInteger(0);
    for (int i = 0; i < iterations; i++)
    {
        while( ! x.compareAndSet(0, 1) )
            ;

        testValue++;

        if(waitingList!=0)
            ;
        x.set(0);
    }

Это голое моделирование кости немного быстрее, чем версия synchronized, занятое время - 15/17.

Это показывает, что в вашем тестовом примере Java не делал сумасшедших оптимизаций, он честно сделал lock-read-update-unlock для каждой итерации. Тем не менее, имплантируйте Java так же быстро, как и голой кости; он не может быть быстрее.

Хотя С# impl также близок к минимуму, он, по-видимому, делает одну или две вещи больше, чем Java. Я не знаком с С#, но это, вероятно, указывает на некоторую разницу в семантике, поэтому С# должен сделать что-то дополнительное.

Ответ 5

Когда я исследовал затраты на блокировку/синхронизацию несколько лет назад в Java, я столкнулся с большим вопросом, как блокировка влияет на всю производительность, а также для других потоков, обращающихся к любой памяти. На что может повлиять кеш процессора, особенно на многопроцессорном компьютере, и зависит от того, как конкретная архитектура процессора обрабатывает синхронизацию кеша. Я считаю, что общая производительность не влияет на современную архитектуру единого процессора, но я не уверен.

В любом случае, если у вас есть сомнения, особенно когда многопроцессорные компьютеры могут использоваться для размещения программного обеспечения, возможно, стоит поставить блокировку на более высокий уровень в течение нескольких операций.

Ответ 6

Java JIT оптимизирует синхронизацию, поскольку объект блокировки является локальным потоком (т.е. он ограничен стеком потоков и никогда не используется совместно) и, следовательно, никогда не может быть синхронизирован с другого потока. Я не уверен, что .NET JIT сделает это.

См. эту очень информативную статью, особенно часть, посвященную проблеме блокировки.