Сбивающая с толку разница в производительности между процессорами Intel

Я нахожусь в процессе реализации различных алгоритмов на процессорах и графических процессорах. Что меня поразило странным, так это то, что очень примитивный пример (последовательно — он же 1 поток — создание гистограммы массива с 100 * 1024 * 1024 элементами) занимает на 200% - 300% больше времени на процессоре сервера (который, по общему признанию, немного ниже по тактовой частоте). и на одно поколение старше), чем на ЦП рабочей станции. Обе машины используют память DDR3, двухканальную память 16 ГБ на рабочей станции (FSB:DRAM 1:6) и четырехканальную память 512 ГБ на сервере (FSB:DRAM 1:12), обе работают с тактовой частотой DRAM 800 МГц.

На моей рабочей станции расчет гистограммы занимает ‹100 мс (в среднем 90 мс), тогда как на сервере он занимает в среднем 300 мс, а в спорадических случаях это занимает всего около 150 мс. .

Я использую одну и ту же сборку на обеих машинах (любой процессор, предпочитаю 32-битную версию).

Другой вопрос, почему чистая 64-битная сборка медленнее на обеих машинах как минимум на 25%?

public static void Main(string[] args) {
    // the array size. say its 100 * 1024 ^ 2, aka 100 Megapixels
    const int Size = 100 * 1024 * 1024;

    // define a buffer to hold the random data
    var buffer = new byte[Size];

    // fill the buffer with random bytes
    var rndXorshift = new RndXorshift();
    rndXorshift.NextBytes(buffer);

    // start a stopwatch to time the histogram creation
    var stopWatch = new Stopwatch();
    stopWatch.Start();

    // declare a variable for the histogram
    var histo = new uint[256];

    // for every element of the array ...
    for (int i = 0; i < Size; i++) {
        // increment the histogram at the position
        // of the current array value
        histo[buffer[i]]++;
    }

    // get the histogram count. must be equal
    // to the total elements of the array
    long histoCount = 0;

    for (int i = 0; i < 256; i++) {
        histoCount += histo[i];
    }

    // stop the stopwatch
    stopWatch.Stop();
    var et1 = stopWatch.ElapsedMilliseconds;

    // output the results
    Console.WriteLine("Histogram Sum: {0}", histoCount);
    Console.WriteLine("Elapsed Time1: {0}ms", et1);
    Console.ReadLine();
}

ЦП сервера: ЦП сервера

ЦП рабочей станции: ЦП рабочей станции


person lightxx    schedule 10.07.2014    source источник
comment
При такой тривиальной петле коэффициент перебора МГц весьма актуален (и TurboBoost сильно повлияет на результаты). Однако обратите внимание, что ваш буфер действительно мал. При большем размере данных размер кэша также будет определять результат. Наконец... не забывайте, что бенчмарк на (рабочем) сервере довольно случайный. Вкратце: этот тест совершенно бесполезен, если это не именно тот код, который вам нужно измерить, если это просто тест, то он бессмысленен.   -  person Adriano Repetti    schedule 10.07.2014
comment
OK. даже после изменения плана питания на высокую производительность сервер работает на 33% медленнее. Я думаю, это разница в тактовой частоте и архитектуре...   -  person lightxx    schedule 10.07.2014
comment
@AdrianoRepetti Это не так уж и бесполезно. Фактически рассматриваемые алгоритмы намного сложнее, я только что придумал самый упрощенный пример из реальной жизни (вычисление гистограммы), который только мог придумать. Кроме того, под сервером я подразумеваю 19-ю единицу, которая простаивает в моей лаборатории ... так что это не так уж случайно ... Кстати, я никогда раньше не слышал этого слова :D   -  person lightxx    schedule 10.07.2014
comment
Я имею в виду: производительность определяется многими многими факторами. Общий GHz, скорость памяти, архитектура процессора, набор инструкций, размер и скорость кэша, а также количество ядер/ЦП. Если вы измеряете что-то, что не является вашим кодом (если только он не настроен так, чтобы точно соответствовать ему), то результаты не обязательно будут отражать то, что вы получите с настоящим кодом. Вот почему стандартные бенчмарки довольно четко сформулированы (а у нас разные бенчмарки). Рассчитайте эту гистограмму с 256 элементами, затем повторите попытку с 1 000 000 элементов. Теперь сделайте его параллельным. Теперь немного усложним вычисления...   -  person Adriano Repetti    schedule 10.07.2014
comment
... вы получите совсем другие результаты. Также в .NET у нас есть JIT, и он может использовать расширенные наборы инструкций, если они доступны. Перейдите на 32-битную или 64-битную версию, и вы также получите совершенно другую реализацию JIT. ИМО слишком много факторов, чтобы проецировать их в другом контексте (от поддельного кода к реальному коду). Что касается серверов, я имею в виду, что если это сервер, вероятно, у него есть свои собственные задачи для выполнения, поэтому производительность будет меняться (даже больше) со временем из-за этого.   -  person Adriano Repetti    schedule 10.07.2014
comment
большое спасибо за развернутый ответ!!!   -  person lightxx    schedule 10.07.2014


Ответы (1)


Тактовая частота процессора сервера показывает 1177 МГц, а рабочая станция имеет тактовую частоту 3691 МГц. Это объяснило бы разницу.

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

person Dariusz    schedule 10.07.2014
comment
вот это странно... и ты прав. это почти полностью объяснило бы разницу... странно... - person lightxx; 10.07.2014
comment
Моей первой мыслью был режим энергосбережения: с сервером Dell мы смогли удвоить производительность приложения Java, которое вело себя хаотично. Вот и пришло время поковыряться в настройках биоса. - person Andreas; 10.07.2014
comment
МГц являются фактором (здесь) из-за тривиальной петли и небольшого размера данных (всего 256 единиц). Увеличение скорости и размера буферного кеша также повлияет на результаты (сильно). Наконец, также важна модель процессора из-за i7 TurboBoost. - person Adriano Repetti; 10.07.2014
comment
глупые окна для использования сбалансированного плана питания на серверах по умолчанию. тупые админы, что не поменяли. глупый я не видел его. - person lightxx; 10.07.2014
comment
@lightxx рад помочь :) - person Dariusz; 10.07.2014
comment
Я на самом деле удивлен, что это будет зависеть от частоты ядра, основным узким местом здесь должен быть последовательный доступ к buffer (гистограмма, скорее всего, полностью кэшируется) - это чистый тест пропускной способности памяти, и серверы обычно имеют преимущество. . Может быть, 2 дополнительных поколения в архитектуре процессора принесут какую-то пользу (возможно, из-за предварительной выборки HW?) - person Leeor; 11.07.2014