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

NC>CF — флаг процессора, устанавливается, если арифметическая операция
NC>произвела перенос из старшего бита результата, старшим является 7, 15,
NC>31 биты, в зависимости от размерности операнда. (с) В.И. Юров, "Assembler"

Нет, ты расскажи что такое CF в C++.

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

NC>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется
NC>JIT'ом для конкретной ф-ции....

Можно посмотреть в Debug->Window->Disassembl.

WolfHound пишет:
> Здравствуйте, _d_m_, Вы писали:
>
> ___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
> ИМХО ты сильно переоцениваешь время которое сожрет болие умная оптимизация.

угу... то-то у меня на работе проект без оптимизации компилируется 15
минут, а с оптимизаций несколько часов....

VladD2 пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>этот тест не предполагал какого-то полного, строгого тестирования двух
> NC>языков большим количеством народа, просто надо было быстренько сравнить
> NC>два языка (изначально C# и C#2) и писать придумывать для этого свой
> NC>алгоритм генерации случайных чисел, думаю, было бы нерационально
>
> На этот счет есть очень протсые решения которые можно найти за 5 минут на нашем же сайте.
> Например, Mab не наз приводил вот такое решение:
>

...
>

> Проще не придумашь, а для целей тестирования более чем подходит.
ок, буду иметь ввиду... но чтобаы найти этот самый пример я думаю
потратил бы значительно больше времени, чем писал все 3 теста...


> Даверять можно чему угодно, но не в тестах компилятора. Более того в тестах вообще не стоит применять библиотеки, если конечно не идет речь о тестировании самих библиотек.
> Тест — это можно сказать микроскопическая научно-исследовательская
работа. И как и любая научная работа она должна строится на базе
научного подхода. Иначе ценность тестов становится сомнительной.

в общем случае — согласен, в данном не очень.... у меня была задача
сравнить да компилятора на чем-то элементарном, причем сравнить быстро
(в течение 5-10 минут)...

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

NC>угу... то-то у меня на работе проект без оптимизации компилируется 15
NC>минут, а с оптимизаций несколько часов....
Это каким компилятором? У меня есть подозрение что там что-то не то с ключами ибо в моей практике релиз компилится как правило быстрее чем дебуг ибо генерится меньше временных файлов.(это если мы про С++ говорим)
К томуже скорость компиляции у С++ и C# немного разная...

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

NC>ок, буду иметь ввиду... но чтобаы найти этот самый пример я думаю
NC>потратил бы значительно больше времени, чем писал все 3 теста...

Гы. Так на то как раз и есть форумы и поиск!
Можно или найти или спросить.

NC>в общем случае — согласен, в данном не очень.... у меня была задача
NC>сравнить да компилятора на чем-то элементарном, причем сравнить быстро
NC>(в течение 5-10 минут)...

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

Между тем написание теста обычно и минуты не занимает.

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

NC>>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется
NC>>JIT'ом для конкретной ф-ции....

L>Можно посмотреть в Debug->Window->Disassembl.

Вот так не стоит. В отладочной версии ты получишь результат далекий от того что будет в релизе.

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

NC>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется
NC>JIT'ом для конкретной ф-ции....

Единственный способ подключиться отладчиком к уже запущенной программе.

Сделать это можно вставив, например, Trace.Assert(false) в код метода. Но при этом нужно понимать, что маленькая функция может изменить свои характеристики от наличия в ней лишнего кода.

Так что лучше присоденяться не VS, а cordbg (тоже к запущенной программе) и делать точку останова через консоль.

NC>конечно можно прогнать ngen'ом и потом дизассемблировать, но что-то не
NC>рабует перспектива разбираться в куче ассемблерного кода без
NC>комментариев в виде исходника....

ngen на сегодня к тому же еще и по умолчанию генерирует более медленный код. Его можно заставить делать код почти аналогичный JIT-овскому, но это очень не просто.

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

IT>Любой вменяемый компилятор перводит сначала исходный код в в промежуточный код (intermediate code или intermediate representation (IR)). И уже затем этот код оптимизируется. Никто не оптимизирует ИСХОДНЫЙ КОД. Как ты вообще себе это представляешь?

В принципе на базе AST тоже можно делать оптимизации. Более того некоторые из них даже выгодно делать на этом уровне. Например, ОО-оптимизации, переписыание кода. Но как раз подобных оптимизаций С++-ные компиляторы и не делают. Им мешают указатели. Ведь не дай бок кто-то зацепил объект указателем или еще хуже через void тип привел и приплызд гарантирован.

IT>Так вот, IR любого компилятора как набор данных для оптимизатора не сильно отличается от IL.

Более того Феникс как раз и занимается конвертацией IL в IR. Там в разделе расскзывающем о IR говорится, что у байкода Явы есть такие-то свойства, у MSIL-а такие-то, а при переводе в IR производится декомпозиция и оба набора свойств становятся доступны в IR.

IT>В общем, пора тебе прекращать заниматься фантазёрством.

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

В общем, забавнейший тип. Даже банить жалко.

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

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

NC>>>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется
NC>>>JIT'ом для конкретной ф-ции....

L>>Можно посмотреть в Debug->Window->Disassembl.

VD>Вот так не стоит. В отладочной версии ты получишь результат далекий от того что будет в релизе.
Почему? Для релиза также можно включить генерацию отладочной информации.

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

AZ>Почему? Для релиза также можно включить генерацию отладочной информации.

Включить можно. Но мои слова это не изменит. Запустив даже релиз-версию из под отладчика мы получим не оптимизированный код. Только запус без отладчика приведет к тому, что JIT-перейдет в режим оптимизации.

Здравствуйте, <Аноним>, Вы писали:

А>

Интересно, ты поиском пользоваться умешь?

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

NC>угу... то-то у меня на работе проект без оптимизации компилируется 15
NC>минут, а с оптимизаций несколько часов....

С++Builder?

находится в регистре FLAGS
CF — флаг переноса. устанавливается если арифметич. операция вызвала перенос или заем из старшего бита результата

Lloyd пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>CF — флаг процессора, устанавливается, если арифметическая операция
> NC>произвела перенос из старшего бита результата, старшим является 7, 15,
> NC>31 биты, в зависимости от размерности операнда. (с) В.И. Юров, "Assembler"
>
> Нет, ты расскажи что такое CF в C++.

насколько я знаю в C++ такого флага нет

VladD2 пишет:
> ... Пока что я легко могу доказать, что многие С++-компиляторы (и МС-ный тоже) после оптимизаци изменяют алгоритм и способны привести к неработоспособности корретного С++-кода. А вот обратное найти не просто. Было пара случаев, но их исправли. Да и случаи били уж очень экзотические.

можешь накидать пример в несколько строк?.... действительно никогда не
видел кода, который не работает из-за компилятора.... и... может
перенести это сообщение (и следующую за ним ветку) в форум о C++?

WolfHound пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>угу... то-то у меня на работе проект без оптимизации компилируется 15
> NC>минут, а с оптимизаций несколько часов....
> Это каким компилятором? У меня есть подозрение что там что-то не то с ключами ибо в моей практике релиз компилится как правило быстрее чем дебуг ибо генерится меньше временных файлов.(это если мы про С++ говорим)
> К томуже скорость компиляции у С++ и C# немного разная...

на работе C++

vhonest пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>угу... то-то у меня на работе проект без оптимизации компилируется 15
> NC>минут, а с оптимизаций несколько часов....
>
> С++Builder?

MS VS 7.1

VladD2 пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>ок, буду иметь ввиду... но чтобаы найти этот самый пример я думаю
> NC>потратил бы значительно больше времени, чем писал все 3 теста...
> Гы. Так на то как раз и есть форумы и поиск!
> Можно или найти или спросить.
да, я видел сравнения, на RSDN тоже ситал статью — там сравниваются
быстрые сортировки разными алгоритмами, на C# и для примера приведен еще
и C++. Но раньше я не встречал ситуации, чтобы шарп оказался быстрее...
сравнений между .NET и .NET2 честно скажу — даже не искал... просто
инетресно было, вот и попробовал.

> NC>в общем случае — согласен, в данном не очень.... у меня была задача
> NC>сравнить да компилятора на чем-то элементарном, причем сравнить быстро
> NC>(в течение 5-10 минут)...
> Дык, задумайся что будет если ты все же ошибся. 10 минут то не жалко. А вот то заблуждение в которое можно ввести тысячи человек может привести к тому, что разного рода фобии потом не выбить много лет.
именно поэтому я и дал сначала эти элементарные алгоритмы проверить 2м
другим программистам.

> Между тем написание теста обычно и минуты не занимает.
я не умею так быстро набивать текст на клаве