Здравствуйте, Pzz, Вы писали:
>> Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на >> Pzz>ассемблерном уровне. >> >> А не было ли это причиной того, что копмилятор OCaml приводил >> рекурсивный вызов к простому циклу?
Pzz>1. Нет, не сводил Pzz>2. GCC тоже умеет превращать хвостовую рекурсию в цикл
Тогда не знаю, что и как там может быть более эффективно. Смотрел код, но никаких гениальных решений не увидел.
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
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Pzz, Вы писали:
>>> Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на >>> Pzz>ассемблерном уровне. >>> >>> А не было ли это причиной того, что копмилятор OCaml приводил >>> рекурсивный вызов к простому циклу?
Pzz>>1. Нет, не сводил Pzz>>2. GCC тоже умеет превращать хвостовую рекурсию в цикл
GN>Тогда не знаю, что и как там может быть более эффективно. Смотрел код, но никаких гениальных решений не увидел.
Вы же сами видели, что из окамла можно генерить эффективный код даже _без оптимизирующего_ компилятора.
причем, случай с float'ами далеко не лучшая сторона окамла
лучшая — это вызов функций и свобода делать с переменными и значениями то, что ему заблагорассудится не оглядываясь.
программа на окамле не играет со стеком, не играет с пойнтерами и адресной арифметикой, не делает никаких джампов и тп.
там можно без статического анализа много выжать на чистом знании этого. а уж если прикрутить оптимизатор как у MSVC...
Только очень прошу, без цирка на этот раз. Здесь все же речь о языках шла, а не о том какая компания выпускает самый навороченный компилятор и какая библиотека лучше всех считает. Можно иногда и профессионализм проявить.
дело не в конкретном компиляторе.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, zip_, Вы писали:
_>>jedit стоит посмотреть, с первого взгляда неплохо, возможно будет функциональнее PN2.
E>Посмотри тему 10 Reasons to Dump Your [Java] IDE
Почитал, смешанные чувства. Надо ставить и пробовать, чем сейчас и займусь.
E>А по поводу vim-а, зря ты так суров, я сам сижу, в основном под Windows, но пользуюсь vim-ом. Очень удобно.
Возможно, но я привыкнуть так и не смог, ни к vim, ни к emacs (XEmacs, если это что-то меняет).
z00n wrote:
> emacs или vim — это такая вещь, что потратил несколько дней — и забыл > о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005 > добавили emacs-раскладку, навыки еще и не пропадут
Z>emacs или vim — это такая вещь, что потратил несколько дней — и забыл о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005 добавили emacs-раскладку, навыки еще и не пропадут
Здравствуйте, little_alex, Вы писали:
_>Здравствуйте, z00n, Вы писали:
Z>>emacs или vim — это такая вещь, что потратил несколько дней — и забыл о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005 добавили emacs-раскладку, навыки еще и не пропадут
_>Серьезно? А можно ссылку?
Здравствуйте, Cyberax, Вы писали:
C>z00n wrote:
>> emacs или vim — это такая вещь, что потратил несколько дней — и забыл >> о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005 >> добавили emacs-раскладку, навыки еще и не пропадут
C>В качестве противовеса: http://rsdn.ru/Forum/Message.aspx?mid=1313142
Здравствуйте, reductor,
GN>>Тогда не знаю, что и как там может быть более эффективно. Смотрел код, но никаких гениальных решений не увидел.
R>Вы же сами видели, что из окамла можно генерить эффективный код
К сожалению, Вы как-то не правильно интерпретируете выделенное. "Эффективность" полученного asm я комментировал — Re[20]: кодогенератор ocamlopt
Оптимизирующему компилятору там не особо есть где развернуться, на мой взгляд. Ну, уберут очевидные ляпы, поднимут производительность процентов на 5. Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих. Не знаю, является ли это следствием особенностей языка или же конкретной реализации. Поэтому и спрашиваю что конкретно там эффективно. Ответа не вижу.
R>причем, случай с float'ами далеко не лучшая сторона окамла
Это было заметно
R>лучшая — это вызов функций
В чём это выражается? Вариации на тему fastcall делает любой нормальный компилятор С++.
R>и свобода делать с переменными и значениями то, что ему заблагорассудится не оглядываясь.
Как это может сказаться на качестве результирующего asm?
R>программа на окамле не играет со стеком
R>не играет с пойнтерами и адресной арифметикой, не делает никаких джампов и тп.
Если можно, подробнее про это. Исходя из Вашего понимания "не играет со стеком" могу сделать неправильные выводы.
R>там можно без статического анализа много выжать на чистом знании этого.
"Мы хотим здесь и сейчас" (с)
R>а уж если прикрутить оптимизатор как у MSVC...
первый попавшийся компилятор, ничего сверхестественного. MSVC — обычный mainstream. В представлении не принимали участие платные Intel C++ и Vector C или что там самое навороченное, даже не знаю.
R>и какая библиотека лучше всех считает.
Никаких сторонних библиотек не было.
R>Можно иногда и профессионализм проявить.
Работа у меня такая — копаться в песочнице с машинным кодом.
R>дело не в конкретном компиляторе.
А в том, что гипотетически OCaml быстрее С++ ?
Вот MS придумали .NET. Все кричали, что это тормоз. Но сделали качественный компилятор, и скорость более чем на уровне для своих задач.
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
Здравствуйте, gear nuke, Вы писали:
GN>Оптимизирующему компилятору там не особо есть где развернуться, на мой взгляд. Ну, уберут очевидные ляпы, поднимут производительность процентов на 5. Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих. Не знаю, является ли это следствием особенностей языка или же конкретной реализации. Поэтому и спрашиваю что конкретно там эффективно. Ответа не вижу.
Все понятно, спасибо за ваше мнение и артистизм.
Что в функциональных языках нельзя распараллеливать выполнение — это очень ценное замечание и архиценное в силу своей редкости мнение.
Здравствуйте, reductor,
GN>>Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих.
R>Что в функциональных языках нельзя распараллеливать выполнение — это очень ценное замечание и архиценное в силу своей редкости мнение.
Вы каким-то интересным способом вырываете смысл (цитаты) из контекста. Инструкция — это команда процессора. К ФЯ не имеет никакого отношения.
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
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, reductor,
GN>>>Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих.
R>>Что в функциональных языках нельзя распараллеливать выполнение — это очень ценное замечание и архиценное в силу своей редкости мнение.
GN>Вы каким-то интересным способом вырываете смысл (цитаты) из контекста. Инструкция — это команда процессора. К ФЯ не имеет никакого отношения.
Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32
Я таковыми считаю свойства исходного кода.
Это касается и игры со стеком и всего прочего.
Но, тем не менее, не могу еще раз не выразить вам благодарность за очень ценное мнение.
Здравствуйте, reductor, Вы писали:
R>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32
R>Я таковыми считаю свойства исходного кода. R>Это касается и игры со стеком и всего прочего.
А разве в исходном коде на том же С++ как-то фигурирует стек? Это же не Forth .
R>Но, тем не менее, не могу еще раз не выразить вам благодарность за очень ценное мнение.
Спасибо
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
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, reductor, Вы писали:
R>>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32
GN>Причина "почему-то" очень проста: GN>
Видимо, мне пора прекращать использовать общие фразы, а в каждом сообщении прикладывать объяснение на три листа что я имел в виду.
Вдруг, у собеседника проблемы с абстрактным мышлением и с пониманием метафор, аллегорий, гипербол и он ничтоже сумняшеся готов все буквализировать.
R>>Я таковыми считаю свойства исходного кода. R>>Это касается и игры со стеком и всего прочего.
GN>А разве в исходном коде на том же С++ как-то фигурирует стек? Это же не Forth :).
В исходном коде С++ фигурирует адресная арифметика.
В явном виде или нет, но в случае с С++ нельзхя быть уверенным ни в чем.
О! Да там оказывается большенство функции полиморфные, вот так преимущество по скорости даст проверка типов аргументов в runtime. А они ещё при этом VTbl в С++ называют тормозом.
Библиотека вся почему-то написана на С, но это мелочи — главное, прилюдно не забывать называть С++ тормознам языком.
Сильно "порадовало", как OCaml хранит целые числа — в форме 2*x+1.
В общем, целочисленная арифметика тоже идёт в лес.
Что же такое позволяет компилировать OCaml в эффективный машинный код так и не понял. Видимо, это действительно фантазии.
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
Здравствуйте, reductor, Вы писали:
R>>>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32
GN>>Причина "почему-то" очень проста: GN>>
R>Видимо, мне пора прекращать использовать общие фразы, а в каждом сообщении прикладывать объяснение на три листа что я имел в виду. R>Вдруг, у собеседника проблемы с абстрактным мышлением и с пониманием метафор, аллегорий, гипербол и он ничтоже сумняшеся готов все буквализировать.
Да, наверное.
Я так и не понял, что же Вы хотите сказать этой фразой выше.
То, что я ранее неверно понял выделенное слово?
Дык это можно сказать без трёх листов, прямо — буквально двумя словами.
R>>>Я таковыми считаю свойства исходного кода. R>>>Это касается и игры со стеком и всего прочего.
GN>>А разве в исходном коде на том же С++ как-то фигурирует стек? Это же не Forth .
R>В исходном коде С++ фигурирует адресная арифметика.
(Замечание про стек Вы уже никак обосновывать не хотите )
И какие проблемы это даёт для компилятора?
Например:
Способ представления целых чисел в OCaml (x * 2 + 1) делает невозможным производить арифметику одной машинной командой. В случае со сложением, они выкручиваются за счёт LEA (хотя это потребует 2й команды, для проверки результата на 0, с переполнением ещё хуже). В остальных случаях всё очень плохо. Как будем вычислять X / Y ?
R>В явном виде или нет, но в случае с С++ нельзхя быть уверенным ни в чем.
Я уверен. Почему я заблуждаюсь?
P.S. У Вас хорошо получается писать про монады. И плохо — что С++ тормоз. Я для себя давно решил, лучше делать то, что получается хорошо.
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
Здравствуйте, gear nuke, Вы писали:
GN>О! Да там оказывается большенство функции полиморфные, вот так преимущество по скорости даст проверка типов аргументов в runtime. :)) А они ещё при этом VTbl в С++ называют тормозом. :-/ GN>Сильно "порадовало", как OCaml хранит целые числа — в форме 2*x+1. GN>В общем, целочисленная арифметика тоже идёт в лес. :down:-/
GN>Что же такое позволяет компилировать OCaml в эффективный машинный код так и не понял. Видимо, это действительно фантазии. :(
Такое впечатление, у вас личная заинтересованность в том, чтобы "опустить" здесь o'caml, а не "найти истину"
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, reductor, Вы писали:
R>>>>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32
GN>>>Причина "почему-то" очень проста: GN>>>
R>>Видимо, мне пора прекращать использовать общие фразы, а в каждом сообщении прикладывать объяснение на три листа что я имел в виду. R>>Вдруг, у собеседника проблемы с абстрактным мышлением и с пониманием метафор, аллегорий, гипербол и он ничтоже сумняшеся готов все буквализировать.
GN>Да, наверное. GN>Я так и не понял, что же Вы хотите сказать этой фразой выше. :???:
GN>То, что я ранее неверно понял выделенное слово? GN>Дык это можно сказать без трёх листов, прямо — буквально двумя словами.
Вы поняли то, что хотели
я же не писал, что откомпилируйте рейтрейсер или откомпилируйте какой-то еще код
не говорил, что сравните производительностью любого кода с любым кодом любого компилятора
не говорил про платформы и ос
не так ли?
имелась в виду некоторая абстракция — окамл можно откомпилировать красивее и быстрее, чем с/с++ код.
и в некоторых случаях это уже происходит, в других — нет. устраивать цирк с флотами, да еще на х86 — это неадекват. уж извините.
прежде чем вы начнете здесь возражать, давайте определимся точнее — в разряд чего вы отнесете фразу
"фортран быстрее, чем С++"
вы согласны с этим утверждением, не согласны или что-то третье?
R>>>>Я таковыми считаю свойства исходного кода. R>>>>Это касается и игры со стеком и всего прочего.
GN>>>А разве в исходном коде на том же С++ как-то фигурирует стек? Это же не Forth :).
R>>В исходном коде С++ фигурирует адресная арифметика.
GN>(Замечание про стек Вы уже никак обосновывать не хотите :-\)
void test(int a, ...) {
int* x = &a;
x++;
cout << *x;
}
int main() {
test(5, 6);
return 0;
}
что напечатает эта программа и почему?
GN>И какие проблемы это даёт для компилятора?
Очень смешно.
GN>Например: GN>Способ представления целых чисел в OCaml (x * 2 + 1) делает невозможным производить арифметику одной машинной командой. В случае со сложением, они выкручиваются за счёт LEA (хотя это потребует 2й команды, для проверки результата на 0, с переполнением ещё хуже). В остальных случаях всё очень плохо. Как будем вычислять X / Y ?
Вы узнать хотите или что? :)
R>>В явном виде или нет, но в случае с С++ нельзхя быть уверенным ни в чем.
GN>Я уверен. Почему я заблуждаюсь?
Откуда я знаю почему.
GN>P.S. У Вас хорошо получается писать про монады. :up: И плохо — что С++ тормоз. Я для себя давно решил, лучше делать то, что получается хорошо. :beer:
Вы думаете, у меня есть такая цель, кого-то убедить в том, что С++ тормоз?
Те, для кого это критично и сами давно во всем разобрались.
В моем случае я лишь просто объясняю почему для числодробильных задач я возьму скорее фортран, чем С++.
Убеждает вас это или нет — мне все равно. Еще не хватало шатать чью-то веру.
> Does the Caml integer/pointer bit trick make arithmetics slower (with
> respect to 'pure' 32 bit arithmetics) because of some mask/shift
> intermediate operations or is it just the same ?
In principle yes, because int values are represented as tagged
(31bits) ints (with the LSB set to 1). So conversion is a shift
followed by an addition (or viceversa).
И где здесь преимущество OCaml? То, что GCC добавил выделенную строку — это конвенция вызова ccall. Бывают и другие конвенции. При inline подстановке такого не будет в обоих языках.
Выделенные команды — следствие формата целых чисел.
int __fastcall test(int n) { return n - (n / 5); }
; Оптимизация по размеру
; Function compile flags: /Ogspy
?test@@YIHH@Z PROC ; test, COMDAT
; _n$ = ecxpush esimov eax, ecx ;; *
push 5
cdq
pop esi
idiv esipop esisub ecx, eax
mov eax, ecx ;; *
ret 0
Выделенные команды — следствие, что функция не заинлайнена (по конвенции вызовов, ESI нельзя портить). При inline подстановке так же не будет команд (*). Число 5 загружается в esi 2мя командами — это медленнее, но меньше по размеру.
; оптимизация по скорости - деление на константу заменено умножением
; Function compile flags: /Ogtpy
?test@@YIHH@Z PROC ; test
; _n$ = ecx
mov eax, 1717986919 ; 66666667H
imul ecx
sar edx, 1
mov eax, edx
shr eax, 31 ; 0000001fH
add edx, eax
mov eax, ecx
sub eax, edx
ret 0
И, кстати, код делает разные вещи. А именно, работает для чисел разного диапазона.
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
Здравствуйте, reductor, Вы писали:
R>Вы поняли то, что хотели R>я же не писал, что откомпилируйте рейтрейсер или откомпилируйте какой-то еще код R>не говорил, что сравните производительностью любого кода с любым кодом любого компилятора R>не говорил про платформы и ос R>не так ли?
Не так:
Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница
просто откомпилировал и посмотрел. рейтрейсер — первое, что попалось.
R>имелась в виду некоторая абстракция — окамл можно откомпилировать красивее и быстрее, чем с/с++ код.
По другой теории, с/с++ код можно откомпилировать лучше, чем это делается сейчас.
R>и в некоторых случаях это уже происходит, в других — нет. устраивать цирк с флотами, да еще на х86 — это неадекват. уж извините.
Зачем повторяете, что я клоун с неадекватным поведением? Оскорбить меня так не получится, не обращаю внимание на такое
R>прежде чем вы начнете здесь возражать, давайте определимся точнее — в разряд чего вы отнесете фразу R>"фортран быстрее, чем С++" R>вы согласны с этим утверждением, не согласны или что-то третье?
Не знаю. На фортране только лабы делал когда-то. Думаю, не быстрее. С++ — это же ассемблер
R>>>>>Я таковыми считаю свойства исходного кода. R>>>>>Это касается и игры со стеком и всего прочего. R>
В некоторых случаях напечатает 2й параметр, переданный в test. Потому что в ISO/IEC 14882 ничего не говориться про стек.
GN>>И какие проблемы это даёт для компилятора?
R>Очень смешно.
Это не смешно — постоянно уходить от ответа.
GN>>Например: GN>>Способ представления целых чисел в OCaml (x * 2 + 1) делает невозможным производить арифметику одной машинной командой. В случае со сложением, они выкручиваются за счёт LEA (хотя это потребует 2й команды, для проверки результата на 0, с переполнением ещё хуже). В остальных случаях всё очень плохо. Как будем вычислять X / Y ?
R>Вы узнать хотите или что?
Это пример, как представление целых чисел в OCaml мешает компилятору.
Хотелось бы увидеть аналогичный пример, как мешает компилятору стек.
R>>>В явном виде или нет, но в случае с С++ нельзхя быть уверенным ни в чем.
GN>>Я уверен. Почему я заблуждаюсь?
R>Откуда я знаю почему.
Хорошо, перефразирую вопрос.
Почему "нельзя быть уверенным ни в чем" ?
R>Вы думаете, у меня есть такая цель, кого-то убедить в том, что С++ тормоз?
Высказывания о тормознутости С++ принадлежат имеено Вам, не знаю, какую смысловую нагрузку они несут.
R>Те, для кого это критично и сами давно во всем разобрались.
Для меня критично. Я разобрался
R>В моем случае я лишь просто объясняю почему для числодробильных задач я возьму скорее фортран, чем С++.
Хех, уже FORTRAN вместо OCaml
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