___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
Вообще-то компиляция происходит один раз.
Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет.
ищем по слову SWAP. Там мой пример того, почему JIT-у будет проблематично(но реально) оптимизировать код. Ещё раз подчеркну: это только ОДИН случай, коих могут быть миллионы (по разнообразию алгоритмов). Жду комментов.
T>>Наверное, вы всё же больше трепло, м? WH>Давно не мылся? Ну так баня на RSDN безразмерная. И если ты будешь продолжать в томже стиле то ты там окажешься.
Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м? Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного, посему не понимаю возмущений. Ближе к теме, меньше понтов, ага?
T>>Я уже привёл пример со SWAP — да, ПОТЕНЦИАЛЬНО и эту команду можно распознавать. Но есть ещё тонны других, менее тривиальных случаев. WH>Я бы конечно мог объяснить...
Не надо разглагольствований. Любую проблему можно кратко и понятно описать. "Кто ясно мыслит, тот ясно излагает" (с) (кто-то умный)
Я уже в третий раз показываю людям с чем у jit могут быть грабли. В ответ один трындёж, передёргивания и бузина с дядькой.
Не нравится — оканчивайте флейм, разойдёмся каждый при своём.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, NovaCxarmulo, Вы писали:
NC>>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, проекты компилировались в Visual Studio 2005 Express Edition, в C++ все оптимизации выставлены на скорость. WH>Когда публикуешь орезультаты тестов то публикуй и исходники этих тестов. Иначе никто ничего сказать не сможет.
Да ведь не сложно и самому тест сделать.
Год назад тест делал, что-то вроде:
for(int i=0;i<...;i++)//не помню количество итераций
for(int j=0;j<..;j++)
{
string s = i+j;
int x = Convert.ToInt32(s);
Console.WriteLine(x);
}
Сделал аналоги для C++ (под builder 6 без оптимизации) и Java.
Результаты (примерно:
Java 55c
C# 25c
C++ 30c
Меня тогда это сильно удивило.
Важно было другое: что С# сравним по скорости с тем же C++, при этом писать на нём значительно легче (конечно, алгоритм в любом случае писать придётся, но высокоуровневых средств для этого значительно больше, как факт меньше ошибок).
Поэтому при возможности стараюсь использовать C#.
Здравствуйте, Thornik, Вы писали:
T>Вы, видимо, несколько переоцениваете "ускоряющие" возможности C#. Скажу больше: ни ООП, ни ФП, ни прочие мозгозавихрения НЕ УСКОРЯЮТ разработки.
Какой наивный милый бред
Дай угадаю. Ты никогда ничего серьёзного не писал на C# и об его "ускоряющих" возможностях сам догадался. Правильно?
Если нам не помогут, то мы тоже никого не пощадим.
В>И что может jit-у помешать использовать команду swap?
Теоретически — ничто, надо только самую малость — уметь распознавать ИМЕННО ЭТОТ кусок кода. И что вы предлагаете, КАЖДОЕ такое место проверять на паттерны? Не устанете?
И потом, это тривиальный случай (хотя даже за него я не уверен, что у JIT будет именно SWAP — поинтересуйтесь у мелкомягких). А как быть с остальными? Вот тоже тупой, но показательный пример: есть массив, в нём 32 байта. Их все надо заполнить числом (это не объявление, это уже алгоритм!). Самое оптимальное — вызвать 4 раза команду из MMX для каждого 8-байтового блока со специальным аргументом. Будет ли это же самое делать jit? Хрена с два — по алгоритму ему положено пройти по 32-ум байтам и занести в них константу. В лучшем случае ("лучшем" для мелкософта) можно оптимизировать проверку границ (и то если правильно написать исходный код).
Ну и что лучше?
Здравствуйте, _d_m_, Вы писали:
___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
Прав. Более того на сегодня JIT-ы зачастую уступают компиляторам.
Но потенциально никаких препятствий нет. Ведь:
1. Компилятор, например, из C# в MSIL может тоже делать опитимизации.
2. Кроме JIT может использоваться и пред-JIT. А при этом можно тратить куда больше времени.
3. JIT может получать информацию об узких точках от профелирования и включать более агрессивную оптимизацию для отдельных частей приложения.
Учитявая, что JIT/пре-JIT произвоидет оптимизацию под конкретную машину, потенциально он в более выиграшном положении. Так что уверен, что рано или поздно JIT-ы будут в среднем обходить обычные компиляторы по скорости получаемого кода. Вот тлько уверен я и в том, что какого-то сверх-приемущества это не даст. Особенно по сравнению с алгоритмическими оптимизациями доступными пока только человеку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Thornik, Вы писали:
T>Это не было бы так плохо, если бы не было с чем сравнивать. Старт Volkov Commander, который загружается сам, СЧИТЫВАЕТ КОНФИГУРАЦИЮ КОМПА, список каталогов, да ещё отрисовывает это на экране, занимает такие доли секунды, что просто не успеваешь сосчитать! Спрашивается, за каким Х нам программы, которые тратят ДЕСЯТКИ СЕКУНД на всякую лабуду, по вине раздолбаев-архитекторов?
Ага. Сравнивать действительно есть с чем.
Очень забавно сравнивать тот же Photoshop с Piant.NET. Второй грузится в десятки, а то и сотни раз быстрее. Ну, а разница в функциональности зачастую не так велика чтобы предпочесть Photoshop. В итоге я знаю людей которые с большим удовольствием пользуются Piant.NET вместо Photoshop когда нужно периодически отредактировать несколько файлов файлов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
___>>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а? WH>ИМХО ты сильно переоцениваешь время которое сожрет болие умная оптимизация.
Согласен. Есть конечно оптимизации способные вообще никогда не закончиться, но многие мощьные оптимизации можно осуществить на средней программе за доли секунд.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>этот тест не предполагал какого-то полного, строгого тестирования двух NC>языков большим количеством народа, просто надо было быстренько сравнить NC>два языка (изначально C# и C#2) и писать придумывать для этого свой NC>алгоритм генерации случайных чисел, думаю, было бы нерационально
На этот счет есть очень протсые решения которые можно найти за 5 минут на нашем же сайте.
Например, Mab не наз приводил вот такое решение:
class MyRandom
{
int seed;
public int Next()
{
seed = (int) (seed * 214013L + 2531011L);
return (seed >> 16) & 0x7fff;
}
}
Проще не придумашь, а для целей тестирования более чем подходит.
NC>про проверку — согласен, про компараторы — не согласен: NC>1. Я исхожу из того, что компилятор и все стандартные библиотеки NC>работают правильно (обратное конечно бывает, но крайне редко, мне еще не NC>попадалось)
Ненадо не из чего исходить. Ты можешь даже неподозревать о том что ошибка в принципе возможна.
Тем временем обычно тесты очень легко пишутся без каких либо абстракций. Ведь все что нужно — это проверить верность результатов.
Я наблюдал как очень заслуженные программисты делали тесты с ошибками. Например, ты можешь взять откуда-то компаратор реализванный как "x — y", а данные могут содержать большие числа и в итоге получится переполнение и не верное сравнение.
В общем, тест нельзя рассматривать в серьез если к нему не приводятся доказательсва. А доказательства должны быть максимально независимыми простыми.
NC>2. Если не доверять стандартным библиотекам, то придется весь FW NC>переписывать самому (лично я использую C# из-за большого набора NC>встроенных в FW велосипедных классов)... уверен глюков будет значительно NC>больше, чем есть сейчас
Даверять можно чему угодно, но не в тестах компилятора. Более того в тестах вообще не стоит применять библиотеки, если конечно не идет речь о тестировании самих библиотек.
Тест — это можно сказать микроскопическая научно-исследовательская работа. И как и любая научная работа она должна строится на базе научного подхода. Иначе ценность тестов становится сомнительной.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ведмедь, Вы писали:
В>На вопрос что такое CF посылать в ветку, где первое упоминание CF это "Факт тот, что мне понадобился флаг CF...", а последукющие посты вида "Выше я привёл пример с CF ... " выглядит по крайней мере странно.
В>Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash ( первые строчки при гуглении здесь )? Я весь в недоумении, при чем тут CompactFlash и оптимизация.. Поясните, пожалуйста, что вы подразумеваете под буквами CF?
Думаю, что речь идет о фроцессоном флаге переполнения. Видимо товарищь считает, что он является неотемлемой частью С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Thornik, Вы писали:
T>А! Понятно. Уважаемый, тогда вас надо отсылать не то что вверх, а вообще куда-то туда.. T>Видите, как всё завязано: все кругом флеймят — то у них C# крутой, то Хаскель, а на самом деле без ассемблера — никуда.
А ты не думал на тему того, что говоря о С++ и C# (платформно-независимы языках) не очень разумного без дополнительных объяснений говорить о флагах процессора, да еще и конкретного типа?
Может тебя отослать к стандартам этих языков, чтобы ты понял, что никаких CF в них нет?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Thornik, Вы писали:
T>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
Опять сам догадался? Ну молодец!
Любой вменяемый компилятор перводит сначала исходный код в в промежуточный код (intermediate code или intermediate representation (IR)). И уже затем этот код оптимизируется. Никто не оптимизирует ИСХОДНЫЙ КОД. Как ты вообще себе это представляешь?
Так вот, IR любого компилятора как набор данных для оптимизатора не сильно отличается от IL.
В общем, пора тебе прекращать заниматься фантазёрством.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Thornik, Вы писали:
WH>>Ну открой "Красного дракона" и почитай. T>Не слишком исчерпывающий ответ. Я могу тоже отсылать читать до бесконечности. Лаконично можно объяснить?
Ты спросил как относится трехадресный код к оптимизации я тебя отправил читать то где об этом написано.
T>Вот здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=1861334&all=1
ищем по слову . Там мой пример того, почему JIT-у будет проблематично(но реально) оптимизировать код. Ещё раз подчеркну: это только ОДИН случай, коих могут быть миллионы (по разнообразию алгоритмов). Жду комментов.
Это сейчас мода такая давать ссылки на пост в котором искомых слов нет? Не первый раз уже.
Если ты про это
Простой пример: надо обменять два байта в слове, что в исходнике закодировано операцией $. Если выражать это на IL, то получится примерно так:
1)Сделать копию операнда
2)Копию сдвинуть влево, оригинал — вправо (оба с заполнением нулями)
3)OR на операнд и копию
А на x86 это делается одной командой SWAP.
Теперь разница есть?
То
1)Это на каком языке? Сколько на С++ писал таких операторов не видел.
2)Не вижу препятствий почему JIT не сможет отследить поток данных.
Все что для этого нужно это добавить в трехадресный код которым оперерует оптимизатор (не путать с IL это лишь одно из представлений трехадресного кода) комманду обмена бит в ячейке. Эта комманда при возможности может развернутся в swap или что-то другое на других архитектурах или в набор сдвигов, and'ов и or'ов в зависимости от параметров комманды.
А свернуть все эти шаманства в эту комманду можно анализом потока данных.
Другое дело что это не маленький объем работы для очень редкой операции и это врядли будут длеать в коммерческом оптимизаторе.
T>Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м?
Я говорю то что вижу. Я увидил что ты не понимаешь как работают оптимизаторы по этому и посоветовал тебе почитать чтонибудь на эту тему.
В ответ получил хамство. T>Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного,
А что ты хотел чтобы я тебе пересказал сотню страниц из красного дракона? T>посему не понимаю возмущений.
Ну я не обзывался. T>Ближе к теме, меньше понтов, ага?
И тебе тогоже.
T>Не надо разглагольствований. Любую проблему можно кратко и понятно описать. "Кто ясно мыслит, тот ясно излагает" (с) (кто-то умный)
Ок. Нужно произвести анализ потока данных. Понятно? Думаю нет. А для того чтобы было понятно нужно написать очень много и нарисовать кучу картинок ибо алгоритм не тривиальный. T>Я уже в третий раз показываю людям с чем у jit могут быть грабли.
У С++ будут теже проблемы. Причем проблемы не принципиальные, а при жилании вполне решаемые. T>В ответ один трындёж, передёргивания и бузина с дядькой.
Этим какраз ты занимаешься.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Thornik пишет: > В>И что может jit-у помешать использовать команду swap? > > Теоретически — ничто, надо только самую малость — уметь распознавать ИМЕННО ЭТОТ кусок кода. И что вы предлагаете, КАЖДОЕ такое место проверять на паттерны? Не устанете? > И потом, это тривиальный случай (хотя даже за него я не уверен, что у JIT будет именно SWAP — поинтересуйтесь у мелкомягких). А как быть с остальными? Вот тоже тупой, но показательный пример: есть массив, в нём 32 байта. Их все надо заполнить числом (это не объявление, это уже алгоритм!). Самое оптимальное — вызвать 4 раза команду из MMX для каждого 8-байтового блока со специальным аргументом. Будет ли это же самое делать jit? Хрена с два — по алгоритму ему положено пройти по 32-ум байтам и занести в них константу. В лучшем случае ("лучшем" для мелкософта) можно оптимизировать проверку границ (и то если правильно написать исходный код). > Ну и что лучше?
хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется
JIT'ом для конкретной ф-ции....
конечно можно прогнать ngen'ом и потом дизассемблировать, но что-то не
рабует перспектива разбираться в куче ассемблерного кода без
комментариев в виде исходника....
тогда можно было бы и проверить.... для C++ в подобном случае у меня
генерировались инициализации по 4 байта за раз...
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Lloyd пишет: > Здравствуйте, Thornik, Вы писали: > > T>А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), > > Мне стыдно, очень стыдно. Но все-таки расскажи что это такое (а то закрадывается подозрение, что ты и сам этого не знаешь).
CF — флаг процессора, устанавливается, если арифметическая операция
произвела перенос из старшего бита результата, старшим является 7, 15,
31 биты, в зависимости от размерности операнда. (с) В.И. Юров, "Assembler"
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, Thornik, Вы писали:
T>Теоретически — ничто, надо только самую малость — уметь распознавать ИМЕННО ЭТОТ кусок кода. И что вы предлагаете, КАЖДОЕ такое место проверять на паттерны?
Ага.
T> Не устанете?
Это программа делает. Ей понятие усталость незнакомо. Другие паттерны ведь распознаются?
Теперь что касается "обмена байт в слове". Покажи мне, плиз, С++-команду делающую такое. Или это тоже паттерн который нужно распозновать?
T>И потом, это тривиальный случай (хотя даже за него я не уверен, что у JIT будет именно SWAP — поинтересуйтесь у мелкомягких). А как быть с остальными? Вот тоже тупой, но показательный пример: есть массив, в нём 32 байта. Их все надо заполнить числом (это не объявление, это уже алгоритм!).
Ага. Алгоритм. Можешь продемонстрировать код на С++ который можно однозначно превратить в одну команду процессора?
К тому же фанатам оптимизации нужно знать, что примитивные инструкции вроде movs на практике сегодня выигрыша не дают. Процесоры ведь давно разбивают их на примитивы.
T> Самое оптимальное — вызвать 4 раза команду из MMX для каждого 8-байтового блока со специальным аргументом.
И кто будет определять, что вместо кучи команд на С++ нужно вызвать 1-2 ММХ? Ну, и что помешает тоже самое сделать джиту?
Неповеришь, но в тех местах где это дейсвтиельно дает выигрышь JIT испоьзует ММХ-команды. А вот при компиляции под Pentium их использовать нельзя, так как у этого камня оных инструкций просто нет. Выходит, что прийдется ограничивать низний процессор или делать несолько модулей.
T> Будет ли это же самое делать jit? Хрена с два — по алгоритму ему положено пройти по 32-ум байтам и занести в них константу. В лучшем случае ("лучшем" для мелкософта) можно оптимизировать проверку границ (и то если правильно написать исходный код). T>Ну и что лучше?
Ты демонстрирущь веру. Спорить с ней практически не возможно. Верь дальше. Только тих. Без оскорблений окружающий.
Если вдруг почиташь описание на тот же Феникс, то поймешь, что был не прав и возможно станет даже стыдно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Thornik, Вы писали:
T>>>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД. WH>> Ну и упертый же ты. Гугли "трехадресный код" и читай до просветления. IL за однин проход преобразуется в трехадресный код.
T>Wolf, ты вообще в теме или так, попИсать вышел? Какой в ... трехадресный код? Мы говорим об оптимизации.
Он же тебе сказал "гугли". Трудно в гугль сходить?
Если ты не знаешь что такое "Гугль" и "гиглить", то мы можем конечно помочь. "трехадресный код"
T>>>А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), WH>>При этом тебе не стыдно говорить об оптимизаторах не зная как они работают даже в общих чертах.
T>Ну естественно! Если нечего сказать,
А сказать действительно не чего. Лично я дал тебе две ссылки из которых можно было почерпнуть информациию Вольфхаунд тоже указал куда копать. Ты же проигнорировал все это и занимашся обвинением оппонентов.
Пойми ты мыташся оспаривать такие базовые вещи, что возражать тебе просто смешно.
T>А тут доказывать не надо: ТЕОРЕТИЧЕСКИ можно оптимизировать всё что угодно. Практически — дело не идёт дальше десятка паттернов,
Ну, то есть принципиальных проблем у IL все же нет? Отлично! Уже сдвинулись с мертвой точки.
T>которые (в реализации мелкомягких) ещё и умудряются испоганить оптимизированный код.
Это нужно доказать. Пока что я легко могу доказать, что многие С++-компиляторы (и МС-ный тоже) после оптимизаци изменяют алгоритм и способны привести к неработоспособности корретного С++-кода. А вот обратное найти не просто. Было пара случаев, но их исправли. Да и случаи били уж очень экзотические.
T> Я уже привёл пример со SWAP — да, ПОТЕНЦИАЛЬНО и эту команду можно распознавать. Но есть ещё тонны других, менее тривиальных случаев.
Дык, ты ведь не ответил на вопрос "в чем тут разница с С++"? Понимш ли, в чем дело. Может случаи когда можно применять SWAP и не распознают, но не потому, что это сложно, а потому что бес толку. Виигрыша 0, а затраты времени и сил есть. Точно так же SWAP не лепят и в С++-компиляторах.
В общем, ты забавный орел. Сам игнорирушь все аргументы, уходишь от вопросов, и при этом во всю обвиняшь окружающих.
ЗЫ
Лучше обрати внимание на то, что тебя вообще никто не поддержал. Видимо все окружающие идиоты, а ты один на белом коне лучше всех все знашь. При этом тебе то и дело дают ссылки, а в ответ получают оскорбления.
В очередной раз говорю — не позорься. Изучи вопрос, а потом спорь до посинения, только разумно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Thornik, Вы писали:
T>Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м? Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного, посему не понимаю возмущений. Ближе к теме, меньше понтов, ага?
Хотел забавнить но столь искрометного хамсва, и распухшего до небес самомнения еще не видел. Так что хочется поглядеть на продолжение.
Излогайте дальше сэр! Ваши понты начинают не по детски прикалывать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
:
Если нам не помогут, то мы тоже никого не пощадим.
Ну и упертый же ты. Гугли "трехадресный код" и читай до просветления. IL за однин проход преобразуется в трехадресный код.