А есть ли способ измерить потребление электричества какой-нибудь функцией?
Я тут сейчас гуглил новости про то, что датацентры города обогревают — вот, задумался: может уже пора делать профилировщики энергопотребления? Иногда нужно не быстрее: выбор среди алгоритмов может быть не по принципу кто быстрее и/или меньше памяти сожрёт, а по жоритости — скорость может быть во всех случаях приемлимой. Это особенно актуально для носимых гаджетов и ноутбуков.
Это также может быть актуально для датацентров. В конце-концов, это может быть актуально для дома, когда нужно обеспечить поток тёплого воздуха из корпуса (чтоб владелец компа замёрзшие пальцы отогрел). Кстати, я когда-то так делал — запускал furmak чтобы руки погреть.
Собственно сабж: для интеловского или амдешного железа есть способ замерить потреблённое электричество?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>А есть ли способ измерить потребление электричества какой-нибудь функцией?
Ф>Я тут сейчас гуглил новости про то, что датацентры города обогревают — вот, задумался: может уже пора делать профилировщики энергопотребления? Иногда нужно не быстрее: выбор среди алгоритмов может быть не по принципу кто быстрее и/или меньше памяти сожрёт, а по жоритости — скорость может быть во всех случаях приемлимой.
А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности?
Если один алгоритм выполняется, допустим, за O(logN), а другой за O(N^2), то кто из них больше раскочегарит процессор?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Философ, Вы писали:
Ф>Собственно сабж: для интеловского или амдешного железа есть способ замерить потреблённое электричество?
Да. Ставишь своему коду с этой функцией реалтаймовый приоритет (останавливаешь всё остальное) и подключаешь ваттметр к компу и получаешь результат.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности? SVZ>Если один алгоритм выполняется, допустим, за O(logN), а другой за O(N^2), то кто из них больше раскочегарит процессор?
Я думаю, что всё может быть несколько сложнее:
1) Разные операции требуют разного кол-ва энергии. Например, думаю очевидно, что операции с плавающей точкой сильно более жористые чем целочисленные.
2) Операции с памятью могут сильно напрягать кэш, который сам по себе неплохой обогреватель. Может быть энергетически выгоднее каждый раз рассчитывать какое-либо значение, чем регулярно перезагружать/инвалидировать кэш-линейки для его поиска в памяти.
3) Все современные процессоры суперскалярные — параллельно исполняют инструкции, исполняют код спекулятивно, и предсказывают переходы. Т.е. кол-во ветвлений может напрямую и нелинейно влиять на жористость. Т.е. сделать что-либо медленнее, по минимому напрягая BTB/BTU, может оказаться энергетически выгоднее чем делать за минимальное время.
4) Есть также догадки по поводу использования синхронизации: синхронизировать крупные куски или отказаться от синхронизации может быть энергетически более выгодно, нежели синхронизировать маленькие участки, оптимизируя тем самым скорость параллельных вычислений. Тот же вопрос по поводу инструкций типа PAUSE....
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности? SVZ>Если один алгоритм выполняется, допустим, за O(logN), а другой за O(N^2), то кто из них больше раскочегарит процессор?
Если снизить частоту увеличив количество ядер, то можно получить бОльшую производительность при меньшем нагреве. Но не все алгоритмы хорошо работают в многопотоке.
Про алгоритмическую сложность понятно, но ведь она будет зависеть не от того что написал программист на высоком уровне абстракций, а от машинных команд.
Разные наборы машинных команд имеют разное энергопотребление. Просто если труд программистов на оптимизацию дороже оборудования никто заморачиваться не будет.
Может только какие-нибудь гуглы у которых количество этих серверов с пятью нулями.
Здравствуйте, Vzhyk2, Вы писали:
V>Здравствуйте, Философ, Вы писали:
Ф>>Собственно сабж: для интеловского или амдешного железа есть способ замерить потреблённое электричество? V>Да. Ставишь своему коду с этой функцией реалтаймовый приоритет (останавливаешь всё остальное) и подключаешь ваттметр к компу и получаешь результат.
Это могло бы сработать, если бы не прерывания таймера и небольшое разрешение ваттметра. Да и прочие аппаратные прерывания сильно портят перспективы.
А потом, представь себе бенчмаркинг для вычислений длинной в минуту:
10 лезем к ваттметру, записываем значение
20 запускаем код руками, ждём остановки
30 call 10
40 вычисляем
Абуреешь — надо что-нибудь более удобное.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
SVZ>>А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности? SVZ>>Если один алгоритм выполняется, допустим, за O(logN), а другой за O(N^2), то кто из них больше раскочегарит процессор?
Ф>Я думаю, что всё может быть несколько сложнее: Ф>1) Разные операции требуют разного кол-ва энергии. Например, думаю очевидно, что операции с плавающей точкой сильно более жористые чем целочисленные. Ф>2) Операции с памятью могут сильно напрягать кэш, который сам по себе неплохой обогреватель. Может быть энергетически выгоднее каждый раз рассчитывать какое-либо значение, чем регулярно перезагружать/инвалидировать кэш-линейки для его поиска в памяти.
Хочешь убрать кеш? Боюсь время отклика софта будет таким, что пользователи взвоют.
К тому же всегда стремились уменьшить частоту обновления кеша. А для этого данные желательно укладывать плотно, чтобы минимизировать промахи.
Т.е. опять речь идёт о повышении эффективности и алгоритма, и структур данных.
Ф>3) Все современные процессоры суперскалярные — параллельно исполняют инструкции, исполняют код спекулятивно, и предсказывают переходы. Т.е. кол-во ветвлений может напрямую и нелинейно влиять на жористость. Т.е. сделать что-либо медленнее, по минимому напрягая BTB/BTU, может оказаться энергетически выгоднее чем делать за минимальное время. Ф>4) Есть также догадки по поводу использования синхронизации: синхронизировать крупные куски или отказаться от синхронизации может быть энергетически более выгодно, нежели синхронизировать маленькие участки, оптимизируя тем самым скорость параллельных вычислений. Тот же вопрос по поводу инструкций типа PAUSE....
Что-то мне подсказывает, что ты говоришь о размазывании потребления во времени, а не сокращении оного. Ну т.е. число операций значимо не уменьшится, просто процессор будет больше спать. Но суммарно на решение времени потратит то же количество энергии, что и в "турбо" режиме.
Сэкономить энергию можно за счет перехода с JS на Си Вот тут да, количество операций процессора на вычисление будет значительно меньше
Но боюсь, программистское сообщество не оценит
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, velkin, Вы писали:
SVZ>>А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности? SVZ>>Если один алгоритм выполняется, допустим, за O(logN), а другой за O(N^2), то кто из них больше раскочегарит процессор?
V>Если снизить частоту увеличив количество ядер, то можно получить бОльшую производительность при меньшем нагреве. Но не все алгоритмы хорошо работают в многопотоке.
При условии, что алгоритм в принципе параллелится. Собсно, современные процессоры АРМы и Интеловские идут в указанном тобой направлении — делают несколько производительных ядер и несколько малахольных.
Для мобильных приложений, где большинство задач сводится к перекладыванию байтов по памяти, такое хорошо работает. А для числодробилок получается проседание.
V>Про алгоритмическую сложность понятно, но ведь она будет зависеть не от того что написал программист на высоком уровне абстракций, а от машинных команд.
Опыт показывает, что повысить производительность алгоритмически гораздо эффективнее, чем оптимизацией тактов.
V>Разные наборы машинных команд имеют разное энергопотребление. Просто если труд программистов на оптимизацию дороже оборудования никто заморачиваться не будет.
Это можно было бы решить ключами компилятора. Всё равно в машкодах сейчас пишут считанные единицы.
V>Может только какие-нибудь гуглы у которых количество этих серверов с пятью нулями.
Эти вряд ли будут заморачиваться.
Сужу по очень богатым конкурентам — всем покласть на производительность.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Философ, Вы писали:
Ф>А есть ли способ измерить потребление электричества какой-нибудь функцией? Ф>Собственно сабж: для интеловского или амдешного железа есть способ замерить потреблённое электричество?
Здравствуйте, Философ, Вы писали:
Ф>Это могло бы сработать, если бы не прерывания таймера и небольшое разрешение ваттметра. Да и прочие аппаратные прерывания сильно портят перспективы.
Поставь ОС, что будет делать только то, что ты сказал, а не всякую хрень.
Ф>А потом, представь себе бенчмаркинг для вычислений длинной в минуту: Ф>10 лезем к ваттметру, записываем значение Ф>20 запускаем код руками, ждём остановки Ф>30 call 10 Ф>40 вычисляем Ф>Абуреешь — надо что-нибудь более удобное.
Я понял, эта задачка для тебя не подъемна. Но ты можешь попросить чатгопоту или дипсика объяснить тебе для твоего уровня мышления.
Здравствуйте, Философ, Вы писали:
Ф>Это могло бы сработать, если бы не прерывания таймера и небольшое разрешение ваттметра. Да и прочие аппаратные прерывания сильно портят перспективы. Ф>А потом, представь себе бенчмаркинг для вычислений длинной в минуту: Ф>10 лезем к ваттметру, записываем значение Ф>20 запускаем код руками, ждём остановки Ф>30 call 10 Ф>40 вычисляем
Всё автоматизируется, вплоть до нажатий на клавиши эмулятором клавиатуры на какой-нибудь STM32. На нём можно и ватт-метр сделать, и на кнопку старт нажать, и сигнал с ком порта об окончании вычислении поймать.
Здравствуйте, Философ, Вы писали:
Ф>Я тут сейчас гуглил новости про то, что датацентры города обогревают — вот, задумался: может уже пора делать профилировщики энергопотребления? Иногда нужно не быстрее: выбор среди алгоритмов может быть не по принципу кто быстрее и/или меньше памяти сожрёт, а по жоритости — скорость может быть во всех случаях приемлимой. Это особенно актуально для носимых гаджетов и ноутбуков.
Ф>Это также может быть актуально для датацентров. В конце-концов, это может быть актуально для дома, когда нужно обеспечить поток тёплого воздуха из корпуса (чтоб владелец компа замёрзшие пальцы отогрел). Кстати, я когда-то так делал — запускал furmak чтобы руки погреть.
По-моему IBM этим начал заниматься ещё в 90х, был у них показатель в духе тфлопс/ватт.
Здравствуйте, Философ, Вы писали:
Ф>А есть ли способ измерить потребление электричества какой-нибудь функцией?
Ф>Я тут сейчас гуглил новости про то, что датацентры города обогревают — вот, задумался: может уже пора делать профилировщики энергопотребления? Иногда нужно не быстрее: выбор среди алгоритмов может быть не по принципу кто быстрее и/или меньше памяти сожрёт, а по жоритости — скорость может быть во всех случаях приемлимой. Это особенно актуально для носимых гаджетов и ноутбуков.
Ф>Это также может быть актуально для датацентров. В конце-концов, это может быть актуально для дома, когда нужно обеспечить поток тёплого воздуха из корпуса (чтоб владелец компа замёрзшие пальцы отогрел). Кстати, я когда-то так делал — запускал furmak чтобы руки погреть.
Ф>Собственно сабж: для интеловского или амдешного железа есть способ замерить потреблённое электричество?
Думаю что в современных условиях больше жрут электричество фреймворки а не отдельные алгоритмы.
А также синтаксический сахар и непонимание разработчиками то го что "под капотом" этих фреймворков.
Здравствуйте, rm2, Вы писали:
SVZ>>А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности?
rm2>Нет. потребление зависит от степени загруженности исполняемых устройств в процессоре.
А степень загруженности от чего зависит?
Скажем, если вместо 1000 вызовов fmul будет 1000^2 вызовов, загруженность увеличится?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А разве энерго-ужористость не прямо пропорциональна алгоритмической сложности? SVZ>Если один алгоритм выполняется, допустим, за O(logN), а другой за O(N^2), то кто из них больше раскочегарит процессор?
Это довольно приблизительная оценка. Есть же там всякий параллелизм, работа с памятью, процент попадания/промхов в кеш, затраты на декодирование виртуальных адресов, сложные и никому непонятные алгоритмы, управляющие тактовой частотой процессорных ядер,...
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Сэкономить энергию можно за счет перехода с JS на Си Вот тут да, количество операций процессора на вычисление будет значительно меньше SVZ>Но боюсь, программистское сообщество не оценит
Есть мнение, что выигрыш будет раза в два. Не в 10.
SVZ>А степень загруженности от чего зависит? SVZ>Скажем, если вместо 1000 вызовов fmul будет 1000^2 вызовов, загруженность увеличится?
степень загруженности зависит от того, насколько поступающие инструкции можно выполнять независимо (параллельно) друг от друга, и попали ли данные по этим инструкциям в кеш.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Хочешь убрать кеш? Боюсь время отклика софта...
Не, совсем убирать кэш — лишее, можно не убирать кэш, да и невозможно это. Можно строить алгоритм так, чтобы он по-минимому затрагивал кэш-линейки (даже ценой лишних вычислений).
Кроме того, далеко не всегда время отклика имеет значение: есть риалтаймовые операции, а есть операции, не требующие риалтайма. Например, показать, что кнопка нажалась, нужно сразу — риалтайм, а вот выдавать результат можно и не в риалтайме. Более того, сотни фоновых служб вообще не требуют внимания пользователя — там всё равно минуту CPU они сожрут или сто, результат пользователь наверняка увидит минимум завтра, а может, и вообще не увидит.
SVZ>К тому же всегда стремились уменьшить частоту обновления кеша. А для этого данные желательно укладывать плотно, чтобы минимизировать промахи.
Категорически неверно, наоборот: данные редко укладываются плотно — их выравнивают по границам DWORD и QWORD. Мотивация тут простая: современные процессоры работают с памятью блоками фиксированного размера, поэтому если данные выровнены по границам этих блоков, процессору требуется всего одно обращение к памяти для чтения или записи. Если данные не выровнены, процессору может потребоваться два или более обращения, что увеличивает накладные расходы. Кроме того, SIMD-инструкции (например, SSE, AVX) часто требуют, чтобы данные были выровнены по определенным границам (например, 16 байт для SSE, 32 байта для AVX).
Выравнивание данных уменьшает промахи кэша: кэш-память работает с блоками данных (кэш-линиями), обычно размером 64 байта. Выровненные данные с меньшей вероятностью пересекают границы кэш-линий, что уменьшает количество кэш-промахов и вероятность вытеснения данных из кэша. Однако если данные не выровнены, они могут пересекать границы кэш-линий, и процессору потребуется загрузить или обновить две кэш-линии вместо одной.
Например, если операция записывает элемент данных размером QWORD, и он не выровнен, то одна часть данных может оказаться в одной кэш-линии, а другая — в следующей. Это приведёт к тому, что процессору потребуется пометить две кэш-линии как DIRTY вместо одной, что увеличивает накладные расходы.
Кроме того, современные кэши используют ассоциативную организацию. Если данные не выровнены, они могут попадать в разные наборы кэша, что увеличивает вероятность кэш-конфликтов. Выравнивание данных помогает минимизировать такие конфликты.
Ф>>4)...поводу использования синхронизации...инструкций типа PAUSE....
SVZ>Что-то мне подсказывает, что ты говоришь о размазывании потребления во времени, а не сокращении оного. Ну т.е. число операций значимо не уменьшится, просто процессор будет больше спать. Но суммарно на решение времени потратит то же количество энергии, что и в "турбо" режиме.
Нет, например в случае инструкции PAUSE внутри цикла с высокой вероятностью произойдёт снижение частоты ядра и с меньшей вероятностью переход в более глубокий C-state. В связи с тем, что асимптотика тепловыделения на средних частотах кубическая, а на высоких экспоненциальная, то само по себе использование PAUSE имеет смысл — это не размазывание по времени. Размазыванием по времени это было бы, если бы была линейная зависимость.
Всё сказанное выше — личное мнение, если не указано обратное.
