Комментарии 7
Хотелось бы понять как он пришел к таким единицам измерения, которые обычно используются для измерения пропускной способности. Это как-то похоже на то, если бы вместо скорости автомобиля замеряли сколько автомобилей пропустит туннель за единицу времени.
От этого создается ощущение, что тебе хотят показать большие цифры скрывая их суть.
И почему ГБ/с из первой секции последней таблицы
wasmblr (tuned 2): 2.73 GB/s (56956492.7 iters/sec)на один порядок меньше чем из последней
wasmblr (tuned 2): 93.79 GB/s (29814.89 iters/sec)однако количество итераций в секунду во первом случае на несколько порядков больше.
Условно в первом случае перекладываем из одного мешка в другой орехи. Вес ореха малый, но много времени уходит на махание руками туда-сюда, хоть и быстро и часто машем.
Во-втором руками машем на порядки медленнее и реже, но таскаем арбузы.
В итоге, произведение числа маханий руками на вес переносимого за раз груза во втором случае в 40 раз происходит эффективнее (меньше накладных расходов на транспортировку).
Да, логично. А зачем производительность оборотами цикла в секунду меряют, а не,например, абсолютным временем выполнения вычислительной задачи? Какие у такого способа измерения преимущества?
Я вот скажем как-то делал функцию для многократного бросания игральных кубиков. И там замерял общее время генерации скажем миллиона результатов. И таким образом я мог сравнивать имплементацию алгоритма генерации. А что сравнивается тут? Никак в толк не возьму.
Сравнивается количество "перемолотых" данных в секунду. Автор, в целом, грамотно показал доступные на данный момент возможности по делегированию тяжелых задач в native на js платформе. Т.е. современный js предлагает весьма гибкий API для вызова низкоуровневых cpu инструкций. Лично меня впечатлило, что разговор зашел о кэшах - верный признак приближения к железу
Если я правильно понял, то тут сравнивая с вашей аналогией получается:
производительность кубиков на 6 граней
производительность кубиков на 64 грани
производительность кубиков на 1024 грани
Потому скорее всего и выходит такая методика проверки - не по количеству бросков а насколько меняется производительность на обработку 1 грани 1 кубика в разных алгоритмах и окружениях
Хм, если подумать, это имеет резон. Мерять производительность через полезную работу. Например не грузоподъемность и номинальную мощность двитагателя самолета, а сколько полезного груза он перевезет за год при непрерывном использовании. И тогда рентабельность считать вполне удобно. Интересный, бизнес-ориентированый подход.
Тут нужно сравнение в скорости с Numba.
Сложение векторов со скоростью 154 Гб/с на WebAssembly