VD>А, ясно. Я это называю посой (не обижайся, плиз).
Тут нечего обижаться, так и есть, по сути большая часть фигня, но есть и полезные вещи.
VD>В прципе конечно тоже рынок. Только такой сойт без проблем может писать и на том же дотнете, если ОС — это Виндовс. Ну, код который должен в режиме ядра работать, конечно нужно на С писать. А все остальное — это бессмысленная трата времени.
Извини Влад, но ты в этом не разбираешься
Re[20]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали: T>То есть, чтобы, например, прочитать число из файла, нужно провести проверки в рантайме.
Это-то ясно. Но при типонебезопасном рантайме все равно нужно эти проверки делать.
Re[21]: Быстро превратить интерпретатор в компилятор
T>>То есть, чтобы, например, прочитать число из файла, нужно провести проверки в рантайме. MC>Это-то ясно. Но при типонебезопасном рантайме все равно нужно эти проверки делать.
В целом, верно. Но не все. Например, вы прочитали число N из файла и инициализируете массив числами от 1 до N:
is = array(N)
for (i = 0; i < N; i++)
is[i] = i
Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит. В другом случае, если в цикле будет условие (i < g(N)), оптимизатору нужно будет сначала доказать, что всегда g(N) <= N. Если какие-то компиляторы и это делают, то вобще супер.
Выяснением какой компилятор какие конструкции сокращает я не занимался, поэтому хорошего живого примера нет, и мне не хотелось бы нарочно придумывать код против оптимизации, это как-то глупо. В основном, проблемы с лишними проверками в том, что процедуры часто зависят от побочных эффектов (и здесь я имею в виду не ввод, который надо проверять в любом случае, а глобальные переменные и т.п.), компиляторы обычно консервативные, а человек может применить грубые оптимизации (и ошибиться, именно поэтому лишние проверки оправданы).
Re[22]: Быстро превратить интерпретатор в компилятор
Да я как-то не учел, что в типонебезопасном варианте программист может держать в голове (а не в коде) какие-то инварианты, которые безопасный рантайм будет проверять (а оптимизатор может и не выкинуть).
Re[22]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
T>В целом, верно. Но не все. Например, вы прочитали число N из файла и инициализируете массив числами от 1 до N:
T>
T>is = array(N)
T>for (i = 0; i < N; i++)
T> is[i] = i
T>
T>Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит.
Ага есть. Называется jit. Если он видит паттерн
for (i = 0; i < ary.Length; i++)
то он выкидывает проверку. Естественно анализ идет на уровне IL-а...
В прочем проверка границ может иметь влияние на производительность только, если в цикле выполняется одна-две примитивных инструкций. В большинстве же случаев — это не так.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
T>Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит. В другом случае, если в цикле будет условие (i < g(N)), оптимизатору нужно будет сначала доказать, что всегда g(N) <= N. Если какие-то компиляторы и это делают, то вобще супер.
Делают. Причем это не просто оптимизация, а система типов построена так что можно доказать что не будет выхода за придела массива. http://scholar.google.com/scholar?cluster=6505909062216609091&hl=en&as_sdt=2000
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Быстро превратить интерпретатор в компилятор
T>>Поскольку мы только что создали массив из N элементов, то в выражении `is[i]` проверку выхода за границу массива выполнять не надо. Может быть есть такой умный компилятор, который её опустит. В другом случае, если в цикле будет условие (i < g(N)), оптимизатору нужно будет сначала доказать, что всегда g(N) <= N. Если какие-то компиляторы и это делают, то вобще супер. WH>Делают. Причем это не просто оптимизация, а система типов построена так что можно доказать что не будет выхода за придела массива. WH>http://scholar.google.com/scholar?cluster=6505909062216609091&hl=en&as_sdt=2000
Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.
С другой стороны, вон, товарищ Vlad2 сообщает, что .NET компилятор уже сегодня оптимизирует конкретно этот случай без зависимых типов.
Re[23]: Быстро превратить интерпретатор в компилятор
VD>Ага есть. Называется jit. Если он видит паттерн
ngen уж тогда он называется. Вряд ли все JiT компиляторы делают такую оптимизацию, только потому что их запускают непосредственно перед выполнением программ, правда?
VD>
for (i = 0; i < ary.Length; i++)
VD>то он выкидывает проверку. Естественно анализ идет на уровне IL-а...
VD>В прочем проверка границ может иметь влияние на производительность только, если в цикле выполняется одна-две примитивных инструкций. В большинстве же случаев — это не так.
Отлично, .NET компилятор оптимизирует тот паттерн, который я привёл в примере. Это здорово, но смысл был не в этом. Вы прочитали сообщение целиком? Вот Mr.Cat правильно меня понял. http://www.rsdn.ru/forum/philosophy/3681225.1.aspx
И, по короткому опыту нашего общения, мне кажется, что причина тому — у него было желание понять, а у вас другое. Ну, или я не умею выражать свои мысли, а с Mr.Cat так совпало, что мы подумали об одном.
Re[24]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
T>Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.
Это вопрос времени.
T>С другой стороны, вон, товарищ Vlad2 сообщает, что .NET компилятор уже сегодня оптимизирует конкретно этот случай без зависимых типов.
Без них можно оптимизировать только очень не большое колличество частных случаев.
Это уже хрен оптимизируешь ибо у нас нет информации о том что векторы одного размера.
assert length <| {n:nat} 'a array(n) -> int(n)
and sub <| {n:nat} {i:nat | i < n} 'a array(n) * int(i) -> 'a
fun dotprod(v1, v2) =
let
fun loop(i, n, sum) =
if i=n then sum
else loop(i+1, n, sum + sub(v1, i) * sub(v2, i))
where loop <| {n:nat} {i:nat | i <= n} int(i) * int(n) * int -> int
in
loop(0, length v1, 0)
end
where dotprod <| {p:nat} {q:nat | p <= q } int array(p) * int array(q) -> int
В любом случае подобные оптимизации оказывают влияние на весьма не большое колличество кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
VD>>Ага есть. Называется jit. Если он видит паттерн
T>ngen уж тогда он называется. Вряд ли все JiT компиляторы делают такую оптимизацию, только потому что их запускают непосредственно перед выполнением программ, правда?
Эту оптимизацию делает и джит и нген. Кстати, в принципе джит делает больше оптимизаций, как не странно. Но Нген эффетивен за счет устранения инициализации не нужных вещей. Например, классов замыканий.
VD>>
for (i = 0; i < ary.Length; i++)
VD>>то он выкидывает проверку. Естественно анализ идет на уровне IL-а...
VD>>В прочем проверка границ может иметь влияние на производительность только, если в цикле выполняется одна-две примитивных инструкций. В большинстве же случаев — это не так.
T>Отлично, .NET компилятор оптимизирует тот паттерн, который я привёл в примере. Это здорово, но смысл был не в этом. Вы прочитали сообщение целиком? Вот Mr.Cat правильно меня понял. http://www.rsdn.ru/forum/philosophy/3681225.1.aspx
И, по короткому опыту нашего общения, мне кажется, что причина тому — у него было желание понять, а у вас другое. Ну, или я не умею выражать свои мысли, а с Mr.Cat так совпало, что мы подумали об одном.
Несомненно есть случае когда типобезопасность выливается в дополнительные проверки рантайме. Только вот в хорошем С-коде эти проверки тоже будут. Ну, и нужно задуматься о том насколько такие проверки влияют на реальную производительность. Пока что я вижу только какие-то домыслы. Меж тем есть не мало тестов демонстрирующие, что в большинстве случаев такое влияние ничтожно мало.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
T>С другой стороны, вон, товарищ Vlad2 сообщает, что .NET компилятор уже сегодня оптимизирует конкретно этот случай без зависимых типов.
VladD2, если приглядеться.
Проблема в том, что оптимизируются только отдельные паттерны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Быстро превратить интерпретатор в компилятор
T>>Отлично, .NET компилятор оптимизирует тот паттерн, который я привёл в примере. Это здорово, но смысл был не в этом. Вы прочитали сообщение целиком? Вот Mr.Cat правильно меня понял. http://www.rsdn.ru/forum/philosophy/3681225.1.aspx
И, по короткому опыту нашего общения, мне кажется, что причина тому — у него было желание понять, а у вас другое. Ну, или я не умею выражать свои мысли, а с Mr.Cat так совпало, что мы подумали об одном.
VD>Несомненно есть случае когда типобезопасность выливается в дополнительные проверки рантайме. Только вот в хорошем С-коде эти проверки тоже будут.
Рад, что мы пришли к общему знаменателю.
VD>Ну, и нужно задуматься о том насколько такие проверки влияют на реальную производительность. Пока что я вижу только какие-то домыслы. Меж тем есть не мало тестов демонстрирующие, что в большинстве случаев такое влияние ничтожно мало.
Да я тоже за то, чтоб не считать спички. Но когда есть возможность компилятором (то есть бесплатно, без участия человека и в каждой программе на десятки лет вперед) сэкономить пол-процента, глупо не воспользоваться.
А сколько эти пол-процента в количественном выражении будут — действительно, иногда ничтожно мало (я охотно верю, что тесты есть и что они верны, это даже без тестов можно простой логикой показать). С другой стороны, есть специфические области, типа шедулеров процессов в ядре или движков 3D графики, где цикл будет выполняться мильёны раз, тогда и один if и один cache miss окажутся существенны.
Здравствуйте, vbn2007, Вы писали:
V>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".
Сделать компилятор C-- и воспользоваться любым существующим транслятором C--. Как это делают многие современные компиляторы. http://en.wikipedia.org/wiki/C--
Удачи!
Re[26]: Быстро превратить интерпретатор в компилятор
Здравствуйте, Temoto, Вы писали:
T>Да я тоже за то, чтоб не считать спички. Но когда есть возможность компилятором (то есть бесплатно, без участия человека и в каждой программе на десятки лет вперед) сэкономить пол-процента, глупо не воспользоваться.
К сожалению, в случае с С/С++ экономия никогда не бывает бесплатной. Она практически всегда получается в следствии выбора между надежностью и производительностью.
Есть и еще один аспект. "Быстрый код" на С не только "хакерский", но еще и очень низкоуровневый. Приходится работать с очень низкоуровневыми абстракциями. Это часто приводит к тому, что хотя на низком уровне выжимаются микросекунды и биты, но на макро-уровне делаются серьезные алгоритмические просчеты, которые легко приводят к тому, что казалось бы высокооптимизированная программа безбожно тормозит.
Конечно и на более высокоуровневом языке или используя более высокоуровневые подходы можно накосячить. Но все же при этом значительно проще держать все под контролем и не допускать фатальных ошибок. Ну, и рефакторинг, конечно проще.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Быстро превратить интерпретатор в компилятор
V>>Есть уже отлаженный вполне интерпертатор. Для ускорения его работы мне нужно быстро-пребыстро переделать его в компилятор. Есть несколько функций для каждой parse: push, pop, reduce, shift, gotostate. Я обратился сюда, чтобы сэкономить время: возможно мне просто посоветуют, какие функции из перечисленных нужно изменить. Экономия времени порядка недели. yacc порождает порядка 25 штук вызовов упомянутых функций для простого синтаксического разбора "=0".
T>Сделать компилятор C-- и воспользоваться любым существующим транслятором C--. Как это делают многие современные компиляторы. T>http://en.wikipedia.org/wiki/C--
T>Удачи!
К сожалению, авторы забросили проект из-за закрытия финансирования. Собирались выложить его в публичный репозиторий на гитхабе, чтобы кто-то развивал, но пока нет.
Re[25]: Быстро превратить интерпретатор в компилятор
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Temoto, Вы писали:
T>>Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет. WH>Это вопрос времени.
А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[26]: Быстро превратить интерпретатор в компилятор
Здравствуйте, FR, Вы писали:
VD>>В прципе конечно тоже рынок. Только такой сойт без проблем может писать и на том же дотнете, если ОС — это Виндовс. Ну, код который должен в режиме ядра работать, конечно нужно на С писать. А все остальное — это бессмысленная трата времени. FR>Извини Влад, но ты в этом не разбираешься
Так расскажи, в чем специфика. Мне вот тоже интересно стало
Подозреваю, что может быть много интеропа, в таком случае писать код исключительно на том же C# достаточно геморойно. Но на C++\CLI или даже на C++\CLI + C# вполне. Уж по крайней мере ГУЙ писать, который у таких утилиток как правило весьма "нарядный".
Re[26]: Быстро превратить интерпретатор в компилятор
Здравствуйте, LaPerouse, Вы писали:
LP>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.
Могут.
Более того если ты посмотришь саму статью то найдешь там деструктивные присваивания контролируемые этой системой типов...
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
