Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, reductor, Вы писали:
R>>И не только вызов функции. R>>Что особо примечательно, компилятор у окамла почти не оптимизирует ничего, он простой как три рубля. R>>Если бы еще и оптимизировал...
VD>Офигительно простой. Видимо из-за простоты умудряется переписывать рекурсию в итерацию. И за одно размещать объекты в стеке, а не в ЖЦ. Ява и дотнет до такой простоты еще не доросли.
VD>ЗЫ
VD>Тебе не программированием, тебе пиаром нужно было заниматься. :)
Переписать хвостовою рекурсию в цикл — это вообще за оптимизацию не считается.
ну и в случае со стеком и регистрами в случае с окамлом — это не оптимизация вообще. мы заранее знаем, что это ничего не сломает.
сложная оптимизация — это обширный статанализ, которым компилятор имени ксавье лероя явно не страдает.
Здравствуйте, reductor, Вы писали:
R>Переписать хвостовою рекурсию в цикл — это вообще за оптимизацию не считается.
Да? А мужики то и не знали. А как же тогда назвать изменение кода повышающее его быстродействие?
R>ну и в случае со стеком и регистрами в случае с окамлом — это не оптимизация вообще. мы заранее знаем, что это ничего не сломает.
Если заранее извесно, что оптимизация что-то сломает, то это уже не оптимизация, а какое-то вредительство. Любая оптимизация делается в рассчете на то, что она не изменит результат вычисления.
R>сложная оптимизация — это обширный статанализ, которым компилятор имени ксавье лероя явно не страдает.
Анализ — это анализ. К оптимизации он имеет отдаленное отношение. Что же до оптимизаций, то самой эффективной оптимизацией по сегодняшний день остается банальная подстановка тела метода вместо его вызова. Учитывая же Так что для ФЯ рекурсия заменяет циклы, ее устранение это не просто оптимизация, а одна из самых полезных оптимизаций. И сравнивать ее результаты с реальным рекурсивным вызовом не очень то разумно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gear nuke, Вы писали:
GN>.NET вот тоже не даёт начудить с указателями, потому и проигрывает в скорости на одном и том же компиляторе.
Вообще-то дает. Есть ансэйф-режим. Ты как раз в него компилировал.
GN> Хотя там и копейки, для многих задач. Кстати, интересно что на платформе windows управляемый С++ работают со скоростью OCaml Ну и С# соответственно тоже, если не быстрее в некоторых местах.
Это проблемы качества оптимизатора. Рано или поздно они уйдут и разница исчезнет.
GN>Действительно, даже если посчитать языки, которые дали нам возможность общаться на этом форуме, будут обе категории. Кстати, можно даже попробовать список составить
На этом форуме языки закончатся на C#. Ну, разве что еще можно сюда клиентские скрипты на JScript приплести. Но он то уж точно используются по минимуму и является просто данью стандартам. Хотя коенечно есть еще SQL. Но это скорее специализированный DSL нежели ЯП.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Я бы внес в стандарт С++ невозможность взятия адреса локальной переменной или адреса значения по ссылке. Это нонсенсы и унаследованные совершенно ненужные св-ва С.
Да, да. Согласен. Ссылки дрались именно с С.
V>OCalm еще явно сырой.
Еще?
V> Но представь хоть на минуту, если в него вложить столько же усилий, сколько в С++ от MS. Мне не нравится этот язык, просто я отдаю себе отчет в потенциале верифицируемого и заведомо оптимизируемого кода.
Думаю, что в Окамл вложили куда больше усилий.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
R>let rec qsort array = match array with
R> [] -> []
R> | pivot::rest -> let left,right = List.partition (function x -> x < pivot) rest
R> in (qsort left) @ pivot::(qsort right);;
R>
Кстати, о быстрой сортировке. На Питоне и Руби она не хуже выглядит... пока в качестве pivot используется первый эелемнт. А как насчет того чтобы взять pivot из центра списка? А то ведь такая версия очень не эффективна на отсортированных списках.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, reductor, Вы писали:
R>>Переписать хвостовою рекурсию в цикл — это вообще за оптимизацию не считается.
VD>Да? А мужики то и не знали. А как же тогда назвать изменение кода повышающее его быстродействие?
Какое быстродействие. для этого а) не нужно никакого анализа. б) это прописано в _стандартах_ некоторых языков.
как можно _оптимизацией_ называть то, что входит в стандарт?
в случае со scheme и haskell, например, это "уменьшение быстродействия" приведет к неработоспособному коду
вот и все.
R>>ну и в случае со стеком и регистрами в случае с окамлом — это не оптимизация вообще. мы заранее знаем, что это ничего не сломает.
VD>Если заранее извесно, что оптимизация что-то сломает, то это уже не оптимизация, а какое-то вредительство. Любая оптимизация делается в рассчете на то, что она не изменит результат вычисления.
если мы делаем dead code elimination, loop unrolling и прочее — мы должны уметь _доказать_, что это не изменит результат вычислений.
то есть мы должны сделать анализ и сопоставив его и спецификацию язяка доказать, что это ни на что не повляиет.
а то так можно назвать оптимизацией сам факт компиляции вместо интерпретации кода на месте — тоже ведь повышаем быстродействие.
R>>сложная оптимизация — это обширный статанализ, которым компилятор имени ксавье лероя явно не страдает.
VD>Анализ — это анализ. К оптимизации он имеет отдаленное отношение. Что же до оптимизаций, то самой эффективной оптимизацией по сегодняшний день остается банальная подстановка тела метода вместо его вызова. Учитывая же Так что для ФЯ рекурсия заменяет циклы, ее устранение это не просто оптимизация, а одна из самых полезных оптимизаций. И сравнивать ее результаты с реальным рекурсивным вызовом не очень то разумно.
инлайнинг — тоже требует анализа того, что это сделать можно. потому что не каждая функция может быть заинлайнена.
потому у окамла и плохо с этим, кстати.
Здравствуйте, reductor, Вы писали:
S>>По-моему кое-кто здесь пытается выставить себя очень умным по сравнению с остальными участниками дискуссии.
R>Выставить? Здесь что-то типа аукциона или конкурс на звание очень умного с призами?
Мужики. Замните, плиз этот не лицеприятный разговор. Или прийдется принимать меры. Давайте лучше обсуждать не друг-друга, а тему.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gear nuke, Вы писали:
GN>Что же такое позволяет компилировать OCaml в эффективный машинный код так и не понял. Видимо, это действительно фантазии.
Типобезопасность. Этого достаточно... ну, не считая, что еще нужно найти хорошие руки с головой которые напишут этот самый оптимизатор.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, reductor, Вы писали:
R>>Другая: R>>
R>>let rec qsort array = match array with
R>> [] -> []
R>> | pivot::rest -> let left,right = List.partition (function x -> x < pivot) rest
R>> in (qsort left) @ pivot::(qsort right);;
R>>
VD>Кстати, о быстрой сортировке. На Питоне и Руби она не хуже выглядит... пока в качестве pivot используется первый эелемнт. А как насчет того чтобы взять pivot из центра списка? А то ведь такая версия очень не эффективна на отсортированных списках.
Здравствуйте, reductor, Вы писали:
R>Какое быстродействие.
Обычное.
R> для этого а) не нужно никакого анализа. б) это прописано в _стандартах_ некоторых языков. R>как можно _оптимизацией_ называть то, что входит в стандарт?
Пофигу куда что входит. Для ФЯ эта оптимизация жизненно-важна, вот и додумался народ упомянуть о ней в стандарте. Попробуй найти ИЯ в котором такое же упоминание найдется.
R>в случае со scheme и haskell, например, это "уменьшение быстродействия" приведет к неработоспособному коду R>вот и все.
С чего бы это? Если ты о линивости, то это несколько другая песня.
R>если мы делаем dead code elimination, loop unrolling и прочее — мы должны уметь _доказать_, что это не изменит результат вычислений.
+1
R>то есть мы должны сделать анализ и сопоставив его и спецификацию язяка доказать, что это ни на что не повляиет.
Этот анализ делается на бумаге прежде чем делать оптимизацию в компиляторе.
R>а то так можно назвать оптимизацией сам факт компиляции вместо интерпретации кода на месте — тоже ведь повышаем быстродействие.
Ненадо излишней философии. Мы говорим об оптимизациях в компиляторах. Ни один интерпретатор на вычислительных задачах и рядом не встанет с компилятором.
R>инлайнинг — тоже требует анализа того, что это сделать можно. потому что не каждая функция может быть заинлайнена.
Заинлайнина может быть любая функция. Другое дело, что иногда кроме этого нужно оставлять тело метода. Но это детали. Какое это отношение имеет к делу?
Ты утверждашь, что замена рекурсии итерацией не оптимизация. Почему же тогда это не делается почти во всех компиляторах ИЯ?
R>потому у окамла и плохо с этим, кстати.
У Окамла плохо не с этим. У него плохо с тем кто пишет бэкэнд компилятора. Хотя я бы назвал это даже не плохо, а так... "не супер". Все же он генерирует довольно приличный код. У Окамла есть куда больше идеологических проблем вроде ориентации на списки. Тут уже потрбеются алгоритмические оптимизации которые куда как сложнее в реализации.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>>>Другая: R>>>
R>>>let rec qsort array = match array with
R>>> [] -> []
R>>> | pivot::rest -> let left,right = List.partition (function x -> x < pivot) rest
R>>> in (qsort left) @ pivot::(qsort right);;
R>>>
VD>>Кстати, о быстрой сортировке. На Питоне и Руби она не хуже выглядит... пока в качестве pivot используется первый эелемнт. А как насчет того чтобы взять pivot из центра списка? А то ведь такая версия очень не эффективна на отсортированных списках.
R>да, говно язык окамл, согласен.
Забавно. Снова уход от ответа. Ты уже, наверно, десятый пропогандист ФЯ который ушел от ответа на этот вопрос.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, reductor, Вы писали:
R>>>>Другая: R>>>>
R>>>>let rec qsort array = match array with
R>>>> [] -> []
R>>>> | pivot::rest -> let left,right = List.partition (function x -> x < pivot) rest
R>>>> in (qsort left) @ pivot::(qsort right);;
R>>>>
VD>>>Кстати, о быстрой сортировке. На Питоне и Руби она не хуже выглядит... пока в качестве pivot используется первый эелемнт. А как насчет того чтобы взять pivot из центра списка? А то ведь такая версия очень не эффективна на отсортированных списках.
R>>да, говно язык окамл, согласен.
VD>Забавно. Снова уход от ответа. Ты уже, наверно, десятый пропогандист ФЯ который ушел от ответа на этот вопрос.
А мне неинтересно отвечать на такие вопросы.
Так же как и складывать 2+2 по заказу.
Ничего личного.
Здравствуйте, VladD2, Вы писали:
GN>>.NET вот тоже не даёт начудить с указателями, потому и проигрывает в скорости на одном и том же компиляторе.
VD>Вообще-то дает. Есть ансэйф-режим. Ты как раз в него компилировал.
Это я не про конкретный мой пример говорил, а отвечал на:
Ты не можешь предвычислять участки кода (или оптимизировать алгоритм), если обращаешься к данным через указатели, значение которых устанавливается где-то вне контекста. Это же очевидно и reductor просто не находит слов (или желания) для объяснения очевидных вещей.
Тогда должно выходить, что safe режим обязан работать намного быстрее уже сейчас. (клинические случаи, как я когда-то поставил внутрь цикла __asm nop не рассматриваются)
VD>Это проблемы качества оптимизатора. Рано или поздно они уйдут и разница исчезнет.
А мне кажется, что разница будет. JIT теоретически позволяет компилировать под конкретную модель процессора, оптимизируя под экзотические сейчас вещи вроде структуры кеша, организацию банков памяти, количество ядер CPU...
GN>>Действительно, даже если посчитать языки, которые дали нам возможность общаться на этом форуме, будут обе категории. Кстати, можно даже попробовать список составить
VD>На этом форуме языки закончатся на C#.
Я имею ввиду ещё и языки, которые позволили запустить браузеры и Janus на голом железе
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, VladD2, Вы писали:
R>>Какое быстродействие. VD>Обычное.
С какой стати быстродействие-то? где в Си или Яве используется хвостовая рекурсия для итераций.
и где им увеличит быстродействие раскрутка хвостовой рекурсии.
VD>Пофигу куда что входит. Для ФЯ эта оптимизация жизненно-важна, вот и додумался народ упомянуть о ней в стандарте. Попробуй найти ИЯ в котором такое же упоминание найдется.
Это не оптимизация. Это требование существования. Продолжать здесь спорить я не буду. Вопрос закрыт.
R>>в случае со scheme и haskell, например, это "уменьшение быстродействия" приведет к неработоспособному коду R>>вот и все.
VD>С чего бы это? Если ты о линивости, то это несколько другая песня.
Потому что у хаскеля нет циклов. При любой рекурсии он тогда начнет вылетать со stack overflow.
R>>а то так можно назвать оптимизацией сам факт компиляции вместо интерпретации кода на месте — тоже ведь повышаем быстродействие.
VD>Ненадо излишней философии. Мы говорим об оптимизациях в компиляторах. Ни один интерпретатор на вычислительных задачах и рядом не встанет с компилятором.
Я не понял только при чем тут раскрутка хвостовой рекурсии. Почему в java ее нет до сих пор?
R>>инлайнинг — тоже требует анализа того, что это сделать можно. потому что не каждая функция может быть заинлайнена. VD>Заинлайнина может быть любая функция. Другое дело, что иногда кроме этого нужно оставлять тело метода. Но это детали. Какое это отношение имеет к делу?
прошу показать инлайнинг рекурсивной функции задаром.
VD>Ты утверждашь, что замена рекурсии итерацией не оптимизация. Почему же тогда это не делается почти во всех компиляторах ИЯ?
потому что там есть циклы.
R>>потому у окамла и плохо с этим, кстати. VD>У Окамла плохо не с этим. У него плохо с тем кто пишет бэкэнд компилятора. Хотя я бы назвал это даже не плохо, а так... "не супер". Все же он генерирует довольно приличный код. У Окамла есть куда больше идеологических проблем вроде ориентации на списки. Тут уже потрбеются алгоритмические оптимизации которые куда как сложнее в реализации.
Ориентация на что у окамла? на списки?
На какие еще списки? где у него такая ориентация?
Здравствуйте, VladD2, Вы писали:
VD>Вообще-то слушать тебя интересно. Если бы ты вместо того чтобы обижаться просто снизил бы объем рекламщины и пиара в своих словах, то и те немногие трое тоже изменили бы свое мнение.
Увы, я не 100 долларов, чтобы всем нравиться.
VD>ЗЫ
VD>Экаунты вечны и возврату не подлежат.
VD>Пофигу куда что входит. Для ФЯ эта оптимизация жизненно-важна, вот и додумался народ упомянуть о ней в стандарте. Попробуй найти ИЯ в котором такое же упоминание найдется. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2.1
31 Tail recursion has long been known as a compiler optimization trick. A coherent semantic basis for tail recursion was provided by Carl Hewitt (1977), who explained it in terms of the ``message-passing'' model of computation that we shall discuss in chapter 3. Inspired by this, Gerald Jay Sussman and Guy Lewis Steele Jr. (see Steele 1975) constructed a tail-recursive interpreter for Scheme. Steele later showed how tail recursion is a consequence of the natural way to compile procedure calls (Steele 1977). The IEEE standard for Scheme requires that Scheme implementations be tail-recursive.
Ты не можешь предвычислять участки кода (или оптимизировать
> алгоритм), если обращаешься к данным через указатели, значение которых
> устанавливается где-то вне контекста. Это же очевидно и reductor
> просто не находит слов (или желания) для объяснения очевидных вещей.
Это неверно, кстати. В C/C++ есть ключевое слово restrict, которое
говорит оптимизатору, что указатель не будет иметь alias'инга.
То есть типа:
void copy(restrict int *a, restrict int *b)
{
while(a!=b) *b=*(a++);
}
Здравствуйте, Cyberax, Вы писали:
C>Это неверно, кстати. В C/C++ есть ключевое слово restrict, которое C>говорит оптимизатору, что указатель не будет иметь alias'инга.
Есть в С99, а в С++ всего 3 ключевых слова на "R": return, register и reinterpret_cast
z00n wrote:
> C>Это неверно, кстати. В C/C++ есть ключевое слово restrict, которое > C>говорит оптимизатору, что указатель не будет иметь alias'инга. > Есть в С99, а в С++ всего 3 ключевых слова на "R": return, register и > reinterpret_cast
Оно будет в C++09, а пока есть в GCC и MSVC в виде __restrict.
Ну и С# соответственно тоже, если не быстрее в некоторых местах. 
