Исходное сообщение
"Проект elk развивает компактный JavaScript-движок для микрок..." Отправлено ммнюмнюмус, 26-Сен-21 17:18
>> Стоп, а что тот мусорного, не считая неподдерживаемых массивов? > Вы же сами ответили в предыдущем сообщении. "Зачем хранить все результаты, когда > нужет только один, последний". Наверное, что бы заполнить 4 (или 8?) > миллионов байт ОЗУ и измерить время обработки 1000 ошибок страниц (или > сколько их будет?). Понятно. В каждом мусоре есть доля мусора))). >[оверквотинг удален] >     a = b; >     b = c; >     i++; > } > Если такое скомпилировать в машинные команды, получится примерно 1 сложение, 2 пересылки, > 1 декремент (i++ и i <= n эффективнее заменить уменьшением n > и сравнением с 0) и 1 условный переход. 5 команд и > 2 зависимости по данным (сложение и 1я пересылка + декремент и > переход), то есть процессор потенциально может выполнить по 3-2 команды за > такт. Это применимо к JS? Может, на С оно и было, а на JS ещё оверхед на интерпретатор. Если только интерпретатор умеет себя мерять, но я сильно сомневаюсь, что это относится к проекту типа elk-js. Но и то - на С только при использовании примиттивных неоптимизирующих компиляторов типа tinycc, на gcc и clang без живых измерений не обойтись.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> Стоп, а что тот мусорного, не считая неподдерживаемых массивов? >> Вы же сами ответили в предыдущем сообщении. "Зачем хранить все результаты, когда >> нужет только один, последний". Наверное, что бы заполнить 4 (или 8?) >> миллионов байт ОЗУ и измерить время обработки 1000 ошибок страниц (или >> сколько их будет?). > Понятно. В каждом мусоре есть доля мусора))). >>[оверквотинг удален] >> a = b; >> b = c; >> i++; >> } >> Если такое скомпилировать в машинные команды, получится примерно 1 сложение, 2 пересылки, >> 1 декремент (i++ и i <= n эффективнее заменить уменьшением n >> и сравнением с 0) и 1 условный переход. 5 команд и >> 2 зависимости по данным (сложение и 1я пересылка + декремент и >> переход), то есть процессор потенциально может выполнить по 3-2 команды за >> такт. > Это применимо к JS? > Может, на С оно и было, а на JS ещё оверхед на > интерпретатор. Если только интерпретатор умеет себя мерять, но я сильно сомневаюсь, > что это относится к проекту типа elk-js. > Но и то - на С только при использовании примиттивных неоптимизирующих компиляторов > типа tinycc, на gcc и clang без живых измерений не обойтись.
	Введите код, изображенный на картинке: