Предыдущая страница [1] [2] > 3 <

Автор Сообщение

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6105   2012-05-06 21:08 GMT+3 часа(ов)      
Цитата
Почему именно 5%, а не 10% - откуда появилась эта цифра? Что мне мешает произвести 50 замеров и вычислить среднее значение?

Чтобы говорить о статистической значимости, вам надо знать какое у случайной величины распределение. Ну или класс распределений хотя бы. Или ряд свойств этиого распределения (как минимум).

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

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

Цитата
Тогда почему же я их не видел

Не знаю. Мы вообще о чем конкретно говорим? О байткоде racket? Там прямо так и написано: (%inline + x y z), например.

Цитата
Тогда лучше просто сохранять синтаксический объект. И не называть его компилятором, а просто - оптимизатор кода.

Байткод компактнее
Представьте если бы у вас в Racket исполняемый файл весил не 10мб а 110мб - существенная разница, не так ли? То есть по сути байткод - это именно оригинальный expanded-код, который прошел через оптимизацию и компактно закодирован.

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

Не совсем понял. Давайте заново разберемся:
1. байткод в том же Racket высокоуровневый
2. из-за этого при компиляции в байткод можно проводить только высокоуровневые оптимизации
3. микрооптимизации существенно зависят от целевой архитектуры, по-этому на этапе генерации байткода их произвести нельзя
4. Байткод близкий к хост-языку генерить проще и удобнее, чем байткод какого-нибудь абстрактного RISC-процессора.
Итак, исходя из вышесказнного - какой смысл генерить байткод для RISC-процессора, а не байткод, близкий к структуре хост-языка?

Цитата
Ну, так это не ко мне вопрос.

А это и не вопрос. Это аргумент в пользу того, что dead-code elimination и т.п. оптимизации нужны, эффективны, и работают, несмотря на то, что в коде как буд-то этими оптимизациями обрабатывать нечего

Цитата
А почему я не видел #%app в байткоде?

Не знаю

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6106   2012-05-07 01:29 GMT+3 часа(ов)      
Цитата
Чтобы говорить о статистической значимости, вам надо знать какое у случайной величины распределение. Ну или класс распределений хотя бы. Или ряд свойств этиого распределения (как минимум).
В реальной жизни никто не производит этих расчетов для подобных измерений. Кстати, мне хотелось бы взглянуть на твои расчеты, а то мне не понятно - откуда 5%. Просто навскидку должно быть как минимум 12-15%, опять же зависит от условий эксперимента.
Цитата
Не понял. Единственная оптимизация хвостовых вызовов при генерации байткода, которую вы можете сделать - это указать, что вот эта форма - хвостовая. Все.

Я сравниваю байткод рэкета с RISC-байткодом.
Цитата
Не знаю. Мы вообще о чем конкретно говорим? О байткоде racket? Там прямо так и написано: (%inline + x y z), например.

Где это написано?
Цитата
Представьте если бы у вас в Racket исполняемый файл весил не 10мб а 110мб - существенная разница, не так ли?
Ты утрируешь От силы 14мб.
Цитата
Итак, исходя из вышесказнного - какой смысл генерить байткод для RISC-процессора, а не байткод, близкий к структуре хост-языка?
Т.к. RISC-байткод будет фактически повторять машкод, то проще и удобнее компилировать в последний.
Цитата
Не знаю
Да просто его там нет

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6109   2012-05-07 08:29 GMT+3 часа(ов)      
Цитата
В реальной жизни никто не производит этих расчетов для подобных измерений. Кстати, мне хотелось бы взглянуть на твои расчеты, а то мне не понятно - откуда 5%.

Ну не 5%, а 10%. Это несущественно.

Цитата
Я сравниваю байткод рэкета с RISC-байткодом.

Ок.

Цитата
Где это написано?

В выхлопе парсера байткода.

Цитата
Ты утрируешь От силы 14мб.


Я приуменьшил. На самом деле было бы больше 100мб. 100мб - это исходники _до_ экспанда

Цитата
Т.к. RISC-байткод будет фактически повторять машкод, то проще и удобнее компилировать в последний.

Как показывает практика jit и так весьма шустро справляется.

Цитата
Да просто его там нет

Аналог формы аппликации? Есть, есть.

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6177   2012-05-24 23:24 GMT+3 часа(ов)      
Цитата
Ну не 5%, а 10%. Это несущественно.
Лучше не гадать. Ведь эта величина зависит от конкретной машины. Например, на мощном пк может быть 1,5%, а на слабом и все 15%. А вообще, многое зависит от условий эксперимента. Кстати, для её вычисления необходимо вычислить среднее значение (предварительно отсеяв промахи, но это можно сделать графически).
Цитата
В выхлопе парсера байткода.
Я не помню, чтобы декомпилятор выдавал мне %inline. Да и в документации ничего не сказано. А может все-таки #%in?
Цитата
Я приуменьшил. На самом деле было бы больше 100мб. 100мб - это исходники _до_ экспанда
Шутка
Цитата
Как показывает практика jit и так весьма шустро справляется.
Но это можно делать еще быстрее.
Цитата
Аналог формы аппликации? Есть, есть.
А, так все-таки - аналог, т.е. не #%app. Может представишь фрагмент кода для компиляции.


Онлайн :

0 пользователь(ей), 32 гость(ей) :




Реклама на сайте: