Здравствуйте, rm2, Вы писали:

rm2>Я про "простаивает" в контексте времени жизни процессора. задача загрузки данных из памяти — это примерно пускай 100 тактов ядра процессора, который ничего не делает. Конвеер простаивает, вычислительные устройства простаивают, нагрева нет, но в целом — процесс компиляции, исполнения программы — идет, и в диспетчере задач цифра загрузки — 100%. И в задачах компиляции очень много таких ситуаций.

Думаю что нет, эти простои крайне низки ибо огромный кеш (когда-то в компах даже на Pentium было памяти как сейчас кеш у процессора...), там весь компилятор в него помещается и текущие компилируемые данные. Если идет все в очень много потоков, то естественно есть потоки которые ждут данные, но в это время там выполняются другие потоки. Переключения и т.д. это конечно не оптимально, но так работают процессоры.

Вообще можно все и измерить... Т.е. написать программу которая делает целочисленные вычисления (скорее такое уже и есть и в количестве — просто нужен хороший измеритель не FLOPS, а IOPS — чтобы также долго работал и грел процессор, просто аналог linpack но для целочисленной арифметики) — т.е. задействует все кроме плавающей запятой. И сравнить с потреблением при компиляции. Компиляция естественно будет чуть меньше потреблять — там всетаки ветвления. Зато будет ясна картина столько потребляет целоцисленная арифметика, сколько с плавающей запятой и сколько компиляция. Это и будет количество задействования транзисторов процессора. "Эффективность" тут не подходит, так как в linpack эффективность близка к 100%. А при компиляциях и ошибочно предсказанных ветвлениях в сложных задачах процессор скорее неэффективно действует, выполняя не то что надо.

Здравствуйте, rm2, Вы писали:

rm2>Я про "простаивает" в контексте времени жизни процессора. задача загрузки данных из памяти — это примерно пускай 100 тактов ядра процессора, который ничего не делает. Конвеер простаивает, вычислительные устройства простаивают, нагрева нет, но в целом — процесс компиляции, исполнения программы — идет, и в диспетчере задач цифра загрузки — 100%. И в задачах компиляции очень много таких ситуаций.

Думаю что нет, эти простои крайне низки ибо огромный кеш (когда-то в компах даже на Pentium было памяти как сейчас кеш у процессора...), там весь компилятор в него помещается и текущие компилируемые данные. Если идет все в очень много потоков, то естественно есть потоки которые ждут данные, но в это время там выполняются другие потоки. Переключения и т.д. это конечно не оптимально, но так работают процессоры.

Вообще можно все и измерить... Т.е. написать программу которая делает целочисленные вычисления (скорее такое уже и есть и в количестве — просто нужен хороший измеритель не FLOPS, а IOPS — чтобы также долго работал и грел процессор, просто аналог linpack но для целочисленной арифметики) — т.е. задействует все кроме плавающей запятой. И сравнить с потреблением при компиляции. Компиляция естественно будет чуть меньше потреблять — там всетаки ветвления. Зато будет ясна картина столько потребляет целочисленная арифметика, сколько с плавающей запятой и сколько компиляция. Это и будет количество задействования транзисторов процессора. "Эффективность" тут не подходит, так как в linpack эффективность близка к 100%. А при компиляциях и ошибочно предсказанных ветвлениях в сложных задачах процессор скорее неэффективно действует, выполняя не то что надо но работает на 100% загрузки.