Блок алгоритм измерения частоты ЦП

Intel CPUs после Базовой поддержки Duo два Определенных для модели регистра под названием IA32_MPERF и IA32_APERF.
MPERF считает на максимальной частоте поддержки ЦП, в то время как APERF рассчитывает в фактической частоте тока.

фактической частотой дают:

можно считать их с этим потоком

; read MPERF
mov ecx, 0xe7
rdmsr
mov mperf_var_lo, eax
mov mperf_var_hi, edx

; read APERF
mov ecx, 0xe8
rdmsr
mov aperf_var_lo, eax
mov aperf_var_hi, edx

, но отметить, что rdmsr является привилегированной командой и может работать только в кольце 0.

я не знаю, обеспечивает ли ОС интерфейс для чтения их, хотя их основное использование для управления питанием, таким образом, это не могло бы обеспечить такой интерфейс.

Я собираюсь дата сам с различными деталями в этом ответе, но какого черта...

я должен был заняться этой проблемой несколько лет назад на ПК на базе Windows, таким образом, я имел дело с серийными процессорами Intel x86 как 486, Pentium и так далее. Стандартный алгоритм в той ситуации должен был сделать длинный ряд инструкций по Делению, потому что это - обычно большинство зависящих от ЦП единственных инструкций в наборе Intel. Таким образом, упреждающая выборка памяти и другие архитектурные проблемы существенно не влияют на время выполнения инструкции - очередь упреждающей выборки всегда полна, и сама инструкция не касается никакой другой памяти.

Вы были бы время это с помощью часов с самым высоким разрешением, к которым Вы могли получить доступ в среде, в которой Вы работаете. (В моем случае я выполнял близкое время начальной загрузки на совместимом ПК, таким образом, я непосредственно программировал микросхемы таймера на материнской плате. Не рекомендуемый в реальной ОС, обычно существует некоторый соответствующий API для вызова в эти дни).

основной проблемой, с которой необходимо иметь дело, являются различные типы ЦП. В то время был Intel, AMD и некоторые меньшие поставщики как Cyrix, делающая x86 процессоры. Каждая модель имела свои собственные рабочие характеристики в отношении той инструкции DIV. Моя функция синхронизации блока просто возвратила бы много тактов, взятых определенным постоянным числом инструкций DIV, сделанных в жестком цикле.

Поэтому то, что я сделал, должно было собрать некоторые синхронизации (необработанные возвращаемые значения от той функции) от фактических ПК, выполняющих каждую модель процессора, которую я хотел ко времени, и запишите тех, которые в электронной таблице против известной скорости процессора и типа процессора. У меня на самом деле был инструмент командной строки, который был просто тонкой оболочкой вокруг моей функции синхронизации, и я возьму диск в компьютерные магазины и получу синхронизации от моделей дисплея! (Я работал на очень небольшую компанию в то время).

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

Здесь был прием: Я всегда ненавидел, когда Вы выполните утилиту, и она объявила бы, что Ваш ЦП составлял 99,8 МГц или что бы то ни было. Очевидно это были 100 МГц и в измерении была только небольшая ошибка округления. В моей электронной таблице я записал действительные скорости, которые были проданы каждым поставщиком процессора. Затем я использовал бы график фактических синхронизаций оценить спроектированные синхронизации для любой известной скорости. Но я создал бы таблицу точек вдоль строки, где синхронизации должны вокруг к следующей скорости.

, Другими словами, если бы 100 галочек, чтобы сделать все это повторение, делящееся, означало, 500 МГц, и 200 галочек означали 250 МГц, то я создал бы таблицу, которая сказала, что что-либо ниже 150 составляло 500 МГц, и что-либо выше этого составляло 250 МГц. (Принимающий их были эти только две скорости, доступные от того производителя чипов). Это было хорошо, потому что, даже если бы некоторая нечетная часть программного обеспечения на ПК отбрасывала мои синхронизации, конечный результат часто все еще был бы мертв на.

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

хорошо, я вернусь к прогонянию детей от моего газона теперь.

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

частоты ЦП являются также переменными на основе предлагаемой загрузки и/или температуры. То, что ЦП в настоящее время достигает 800 МГц, не означает, что он будет всегда достигать 800 МГц, он мог бы отрегулировать или вниз по мере необходимости.

, Если действительно необходимо знать тактовую частоту, она должна быть передана в в качестве параметра. EEPROM на плате предоставил бы основную частоту, и если бы часы могут варьироваться, необходимо было бы смочь считать регистры состояния электропитания центральных процессоров (или выполнить вызов ОС) для обнаружения частоты в тот момент.

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

"lmbench" предоставляет алгоритм частоты CPU, портативный для другой архитектуры.

Это выполняет некоторые различные циклы, и тактовая частота процессора является наибольшим общим делителем частот выполнения различных циклов.

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

http://www.bitmover.com/lmbench/

Я не уверен, почему Вам нужен блок для этого. Если Вы находитесь на машине, которая имеет/proc файловую систему, то выполнение:

> cat /proc/cpuinfo

мог бы дать Вам, в чем Вы нуждаетесь.

Быстрый Google на AMD и Intel показывает, что CPUID должен предоставить Вам доступ к макс. частоте ЦП.

One way on x86 Intel CPU's since Pentium would be to use two samplings of the RDTSC instruction with a delay loop of known wall time, eg:

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>

uint64_t rdtsc(void) {
    uint64_t result;
    __asm__ __volatile__ ("rdtsc" : "=A" (result));
    return result;
}

int main(void) {
    uint64_t ts0, ts1;    
    ts0 = rdtsc();
    sleep(1);
    ts1 = rdtsc();    
    printf("clock frequency = %llu\n", ts1 - ts0);
    return 0;
}

(on 32-bit platforms with GCC)

RDTSC is available in ring 3 if the TSC flag in CR4 is set, which is common but not guaranteed. One shortcoming of this method is that it is vulnerable to frequency scaling changes affecting the result if they happen inside the delay. To mitigate that you could execute code that keeps the CPU busy and constantly poll the system time to see if your delay period has expired, to keep the CPU in the highest frequency state available.