Re[20]: C++ vs ???
От: gear nuke  
Дата: 06.12.05 01:10
Оценка:
Здравствуйте, 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
Re[21]: C++ vs ???
От: reductor  
Дата: 06.12.05 02:27
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Pzz, Вы писали:


>>> Pzz>Выяснилось, что у Ocaml'а вызов функции более эффективно устроен на

>>> Pzz>ассемблерном уровне.
>>>
>>> А не было ли это причиной того, что копмилятор OCaml приводил
>>> рекурсивный вызов к простому циклу?

Pzz>>1. Нет, не сводил

Pzz>>2. GCC тоже умеет превращать хвостовую рекурсию в цикл

GN>Тогда не знаю, что и как там может быть более эффективно. Смотрел код, но никаких гениальных решений не увидел.


Вы же сами видели, что из окамла можно генерить эффективный код даже _без оптимизирующего_ компилятора.
причем, случай с float'ами далеко не лучшая сторона окамла
лучшая — это вызов функций и свобода делать с переменными и значениями то, что ему заблагорассудится не оглядываясь.

программа на окамле не играет со стеком, не играет с пойнтерами и адресной арифметикой, не делает никаких джампов и тп.
там можно без статического анализа много выжать на чистом знании этого. а уж если прикрутить оптимизатор как у MSVC...

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ocaml&lang2=icpp
вот, скачайте акермана посмотрите
или там бинарные деревья

Только очень прошу, без цирка на этот раз. Здесь все же речь о языках шла, а не о том какая компания выпускает самый навороченный компилятор и какая библиотека лучше всех считает. Можно иногда и профессионализм проявить.
дело не в конкретном компиляторе.
Re[23]: C++ vs ???
От: zip_ Россия  
Дата: 06.12.05 11:50
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, zip_, Вы писали:


_>>jedit стоит посмотреть, с первого взгляда неплохо, возможно будет функциональнее PN2.


E>Посмотри тему 10 Reasons to Dump Your [Java] IDE
Автор: Павел Кузнецов
Дата: 11.10.05
, там jedit так же обсуждался.


Почитал, смешанные чувства. Надо ставить и пробовать, чем сейчас и займусь.

E>А по поводу vim-а, зря ты так суров, я сам сижу, в основном под Windows, но пользуюсь vim-ом. Очень удобно.


Возможно, но я привыкнуть так и не смог, ни к vim, ни к emacs (XEmacs, если это что-то меняет).
Re[23]: C++ vs ???
От: Cyberax Марс  
Дата: 06.12.05 11:56
Оценка:
z00n wrote:

> emacs или vim — это такая вещь, что потратил несколько дней — и забыл

> о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005
> добавили emacs-раскладку, навыки еще и не пропадут

В качестве противовеса: http://rsdn.ru/Forum/Message.aspx?mid=1313142
Автор: Cyberax
Дата: 08.08.05


Эхх... Опять минусов наставят....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: C++ vs ???
От: little_alex  
Дата: 06.12.05 12:01
Оценка:
Здравствуйте, z00n, Вы писали:


Z>emacs или vim — это такая вещь, что потратил несколько дней — и забыл о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005 добавили emacs-раскладку, навыки еще и не пропадут


Серьезно? А можно ссылку?
Re[24]: C++ vs ???
От: z00n  
Дата: 06.12.05 13:15
Оценка: 2 (1)
Здравствуйте, little_alex, Вы писали:

_>Здравствуйте, z00n, Вы писали:



Z>>emacs или vim — это такая вещь, что потратил несколько дней — и забыл о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005 добавили emacs-раскладку, навыки еще и не пропадут


_>Серьезно? А можно ссылку?


http://msdn2.microsoft.com/en-us/library/ms165509.aspx
Re[24]: C++ vs ???
От: z00n  
Дата: 06.12.05 13:28
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>z00n wrote:


>> emacs или vim — это такая вещь, что потратил несколько дней — и забыл

>> о проблемах на всю жизнь. Тем более, после того, как в MSVS 2005
>> добавили emacs-раскладку, навыки еще и не пропадут

C>В качестве противовеса: http://rsdn.ru/Forum/Message.aspx?mid=1313142
Автор: Cyberax
Дата: 08.08.05


Я, собственно, после этой темы и решился попробовать Если не обращать внимания на флейм,
там много полезной информации.
Re[22]: C++ vs ???
От: gear nuke  
Дата: 06.12.05 22:20
Оценка: 46 (4)
Здравствуйте, reductor,

GN>>Тогда не знаю, что и как там может быть более эффективно. Смотрел код, но никаких гениальных решений не увидел.


R>Вы же сами видели, что из окамла можно генерить эффективный код


К сожалению, Вы как-то не правильно интерпретируете выделенное. "Эффективность" полученного asm я комментировал — Re[20]: кодогенератор ocamlopt
Автор: gear nuke
Дата: 04.12.05
.

R>даже _без оптимизирующего_ компилятора.


Оптимизирующему компилятору там не особо есть где развернуться, на мой взгляд. Ну, уберут очевидные ляпы, поднимут производительность процентов на 5. Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих. Не знаю, является ли это следствием особенностей языка или же конкретной реализации. Поэтому и спрашиваю что конкретно там эффективно. Ответа не вижу.

R>причем, случай с float'ами далеко не лучшая сторона окамла


Это было заметно

R>лучшая — это вызов функций


В чём это выражается? Вариации на тему fastcall делает любой нормальный компилятор С++.

R>и свобода делать с переменными и значениями то, что ему заблагорассудится не оглядываясь.


Как это может сказаться на качестве результирующего asm?

R>программа на окамле не играет со стеком


Факты:
_camlRay__aux_106:
    sub esp, 24
L111:
    mov DWORD PTR 12[esp], eax
    mov DWORD PTR 8[esp], ecx
    mov eax, DWORD PTR [eax]
    mov DWORD PTR 4[esp], eax
    movzx   eax, BYTE PTR [ebx-4]
    test   eax, eax
    je  L109
    mov DWORD PTR 0[esp], ebx
    mov ebx, DWORD PTR [ebx]
    mov eax, DWORD PTR [ecx+12]
    call    _camlRay__ray_sphere_94
L112:
    fld REAL8 PTR [eax]
    fstp    REAL8 PTR 16[esp]
    mov eax, DWORD PTR 4[esp]
    fld REAL8 PTR [eax]
    fcomp   REAL8 PTR 16[esp]
    fnstsw  ax
    and ah, 69
    dec ah
    cmp ah, 64
    jae L110
    mov eax, DWORD PTR 12[esp]
    add    esp, 24
    ret


R>не играет с пойнтерами и адресной арифметикой, не делает никаких джампов и тп.


Если можно, подробнее про это. Исходя из Вашего понимания "не играет со стеком" могу сделать неправильные выводы.

R>там можно без статического анализа много выжать на чистом знании этого.


"Мы хотим здесь и сейчас" (с)

R>а уж если прикрутить оптимизатор как у MSVC...


Для этого нужно-то — почитать IA-32 Intel® Architecture Optimization Reference Manual или взять в команду человека, который это сделал. Я вот не пойму, что этому мешает. Может быть элитизм?

R>http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ocaml&lang2=icpp

R>вот, скачайте акермана посмотрите или там бинарные деревья

Посмотрю 2й раз, ничего не увижу, начну задавать вопросы... и получу очередную ссылку "посмотреть"

R>Только очень прошу, без цирка на этот раз.


Спасибо, приятно осознавать себя клоуном.

R>Здесь все же речь о языках шла, а не о том какая компания выпускает самый навороченный компилятор


Вот и взял
Автор: gear nuke
Дата: 04.12.05
первый попавшийся компилятор, ничего сверхестественного. 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
Re[23]: C++ vs ???
От: reductor  
Дата: 06.12.05 22:27
Оценка: :))
Здравствуйте, gear nuke, Вы писали:

GN>Оптимизирующему компилятору там не особо есть где развернуться, на мой взгляд. Ну, уберут очевидные ляпы, поднимут производительность процентов на 5. Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих. Не знаю, является ли это следствием особенностей языка или же конкретной реализации. Поэтому и спрашиваю что конкретно там эффективно. Ответа не вижу.


Все понятно, спасибо за ваше мнение и артистизм.
Что в функциональных языках нельзя распараллеливать выполнение — это очень ценное замечание и архиценное в силу своей редкости мнение.
Re[24]: C++ vs ???
От: gear nuke  
Дата: 06.12.05 22:33
Оценка: 1 (1) +3
Здравствуйте, 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
Re[25]: C++ vs ???
От: reductor  
Дата: 06.12.05 22:38
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, reductor,


GN>>>Результирующий код построен таким образом, что затруднено распараллеливание инструкций — многие команды зависят от результатов предыдущих.


R>>Что в функциональных языках нельзя распараллеливать выполнение — это очень ценное замечание и архиценное в силу своей редкости мнение.


GN>Вы каким-то интересным способом вырываете смысл (цитаты) из контекста. Инструкция — это команда процессора. К ФЯ не имеет никакого отношения.


Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32
Я таковыми считаю свойства исходного кода.
Это касается и игры со стеком и всего прочего.
Но, тем не менее, не могу еще раз не выразить вам благодарность за очень ценное мнение.
Re[26]: C++ vs ???
От: gear nuke  
Дата: 06.12.05 22:45
Оценка:
Здравствуйте, 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
Re[23]: C++ vs ???
От: z00n  
Дата: 06.12.05 23:05
Оценка:
Здравствуйте, gear nuke, Вы писали:
<...>
http://pauillac.inria.fr/~xleroy/publi/ZINC.ps.gz
http://www.ocaml-tutorial.org/performance_and_profiling
Re[27]: C++ vs ???
От: reductor  
Дата: 06.12.05 23:56
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, reductor, Вы писали:


R>>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32


GN>Причина "почему-то" очень проста:

GN>

Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница


Видимо, мне пора прекращать использовать общие фразы, а в каждом сообщении прикладывать объяснение на три листа что я имел в виду.
Вдруг, у собеседника проблемы с абстрактным мышлением и с пониманием метафор, аллегорий, гипербол и он ничтоже сумняшеся готов все буквализировать.

R>>Я таковыми считаю свойства исходного кода.

R>>Это касается и игры со стеком и всего прочего.

GN>А разве в исходном коде на том же С++ как-то фигурирует стек? Это же не Forth :).


В исходном коде С++ фигурирует адресная арифметика.
В явном виде или нет, но в случае с С++ нельзхя быть уверенным ни в чем.
Re[24]: C++ vs ???
От: gear nuke  
Дата: 07.12.05 00:49
Оценка:
Здравствуйте, z00n, Вы писали:

Z>http://pauillac.inria.fr/~xleroy/publi/ZINC.ps.gz


Вот это почитать возможности нет.

Z>http://www.ocaml-tutorial.org/performance_and_profiling


О! Да там оказывается большенство функции полиморфные, вот так преимущество по скорости даст проверка типов аргументов в 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
Re[28]: C++ vs ???
От: gear nuke  
Дата: 07.12.05 01:18
Оценка: 1 (1) +1
Здравствуйте, reductor, Вы писали:

R>>>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32


GN>>Причина "почему-то" очень проста:

GN>>

Просто <b>откомпилируйте</b> что-нибудь простое на окамле и си++ — увидите в чем разница


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
Re[25]: C++ vs ???
От: reductor  
Дата: 07.12.05 01:32
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>О! Да там оказывается большенство функции полиморфные, вот так преимущество по скорости даст проверка типов аргументов в runtime. :)) А они ещё при этом VTbl в С++ называют тормозом. :-/

GN>Сильно "порадовало", как OCaml хранит целые числа — в форме 2*x+1.
GN>В общем, целочисленная арифметика тоже идёт в лес. :down:-/

GN>Что же такое позволяет компилировать OCaml в эффективный машинный код так и не понял. Видимо, это действительно фантазии. :(


Такое впечатление, у вас личная заинтересованность в том, чтобы "опустить" здесь o'caml, а не "найти истину"

http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/889d06f5cffb61881f47d04a0e625617.en.html

let test2 n : int = n + (n * 2)

получается (ocamlopt):
        .globl  camlTest__test2_57
        .type   camlTest__test2_57,@function
camlTest__test2_57:
.L100:
        lea     -2(%eax, %eax, 2), %eax
        ret


int test2(int n) {
   return (n + (n * 2));
}

получается (gсс -O3 -fomit-frame-pointer):
        .globl test2
        .type   test2, @function
test2:
        movl    4(%esp), %eax
        leal    (%eax,%eax,2), %eax
        ret
Re[29]: C++ vs ???
От: reductor  
Дата: 07.12.05 02:14
Оценка: :))
Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, reductor, Вы писали:


R>>>>Речь шла о свойствах окамла. Вы почему-то таковыми считаете результирующий код, который генерирует его компилятор под win/ia32


GN>>>Причина "почему-то" очень проста:

GN>>>

Просто <b>откомпилируйте</b> что-нибудь простое на окамле и си++ — увидите в чем разница


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:


Вы думаете, у меня есть такая цель, кого-то убедить в том, что С++ тормоз?
Те, для кого это критично и сами давно во всем разобрались.
В моем случае я лишь просто объясняю почему для числодробильных задач я возьму скорее фортран, чем С++.
Убеждает вас это или нет — мне все равно. Еще не хватало шатать чью-то веру.
Re[26]: C++ vs ???
От: gear nuke  
Дата: 07.12.05 02:32
Оценка:
Здравствуйте, reductor, Вы писали:

R>Такое впечатление, у вас личная заинтересованность в том, чтобы "опустить" здесь o'caml, а не "найти истину"


Совершенно не верно. Всё что я хотел — показать абсурдность высказавания "С++ — медленный". Кстати, зачем оно делалось?

R>http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/889d06f5cffb61881f47d04a0e625617.en.html


> 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).


R>
R>let test2 n : int = n + (n * 2)
R>

R>получается (ocamlopt):
R>
R>        .globl  camlTest__test2_57
R>        .type   camlTest__test2_57,@function
R>camlTest__test2_57:
R>.L100:
R>        lea     -2(%eax, %eax, 2), %eax
R>        ret

R>
R>int test2(int n) {
R>   return (n + (n * 2));
R>}

R>получается (gсс -O3 -fomit-frame-pointer):
R>
R>        .globl test2
R>        .type   test2, @function
R>test2:
R>        movl    4(%esp), %eax
R>        leal    (%eax,%eax,2), %eax
R>        ret

И где здесь преимущество OCaml? То, что GCC добавил выделенную строку — это конвенция вызова ccall. Бывают и другие конвенции. При inline подстановке такого не будет в обоих языках.

А теперь посмотрим другой пример:
let test2 n : int = n - (n / 5)

_camlTest__test2_57:
L100:
    mov ebx, eax
    mov ecx, 5
    mov eax, ebx
    sar eax, 1
    cdq
    idiv    ecx
    sal eax, 1
    sub ebx, eax
    mov eax, ebx
    ret
Выделенные команды — следствие формата целых чисел.

int __fastcall test(int n) { return n - (n / 5); }

; Оптимизация по размеру
; Function compile flags: /Ogspy
?test@@YIHH@Z PROC                  ; test, COMDAT
; _n$ = ecx
    push    esi
    mov eax, ecx ;; * 
    push    5
    cdq
    pop esi
    idiv    esi
    pop esi
    sub 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
Re[30]: C++ vs ???
От: gear nuke  
Дата: 07.12.05 03:13
Оценка: 1 (1) +3
Здравствуйте, reductor, Вы писали:

R>Вы поняли то, что хотели

R>я же не писал, что откомпилируйте рейтрейсер или откомпилируйте какой-то еще код
R>не говорил, что сравните производительностью любого кода с любым кодом любого компилятора
R>не говорил про платформы и ос
R>не так ли?

Не так:

Просто откомпилируйте что-нибудь простое на окамле и си++ — увидите в чем разница

просто откомпилировал и посмотрел. рейтрейсер — первое, что попалось.

R>имелась в виду некоторая абстракция — окамл можно откомпилировать красивее и быстрее, чем с/с++ код.


По другой теории, с/с++ код можно откомпилировать лучше, чем это делается сейчас.

R>и в некоторых случаях это уже происходит, в других — нет. устраивать цирк с флотами, да еще на х86 — это неадекват. уж извините.


Зачем повторяете, что я клоун с неадекватным поведением? Оскорбить меня так не получится, не обращаю внимание на такое

R>прежде чем вы начнете здесь возражать, давайте определимся точнее — в разряд чего вы отнесете фразу

R>"фортран быстрее, чем С++"
R>вы согласны с этим утверждением, не согласны или что-то третье?

Не знаю. На фортране только лабы делал когда-то. Думаю, не быстрее. С++ — это же ассемблер

R>>>>>Я таковыми считаю свойства исходного кода.

R>>>>>Это касается и игры со стеком и всего прочего.
R>
R>void test(int a, ...) {
R>        int* x = &a;
R>        x++;
R>        cout << *x;
R>}

R>int main() {
R>        test(5, 6);
R>        return 0;
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
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.