Здравствуйте, NovaCxarmulo, Вы писали:
NC>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>оказался быстрее...
Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC, жирные (чересчур)высокоуровневые конструкции для всего на свете, низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем. С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
MS>Мне нравится. Абстрактный поток команд значит... 5 баллов.
А чего ёрничать? Если не понял ответа, подумай второй раз.
JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию.
Я доходчив?
T>>Значит парень просто недотумкал с ключами компилера — мог бы оптимизировать.
MS>"Парень" сказал, что настроил по максимуму.
Он сказал, а я проверил на деле — ОПТИМИЗАЦИЯ БЫЛА ВЫКЛЮЧЕНА. Правда, после включения результат был не лучше.
MS>Откуда такая уверенность, что конечно C++ компиляторы по определению лучше?
А разве я говорил, что они лучше? Если договорить мою мысль, то я уверен в следущем: хороший компилятор выдаёт программу, которая ВСЕГДА БЫСТРЕЕ любого jit'а.
Разумеется, если мелкософт не научилась делать Ц++ компилеры, это не повод говорить, что C# лучше.
Правда, стоит отметить, что вообще сами по себе ООП языки — костыли ещё те. Если уж чешется сравнивать, то надо брать простой Си и Цэшарп.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, NovaCxarmulo, Вы писали:
NC>>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>>оказался быстрее...
А>Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Я конечно не знаю. Но что-то раньше было такое впечатление, что компилятор Microsoft C++ был прилично шустрее того от Интела.
Так что это вроде как байки, либо уж точно были компиляторы быстрее (статистику не видел). Но в любом случае, разница не такая, чтобы прямо интеловский компилятор был всегда быстрее .NET. Ссылку в студию! Мне интересно откуда дрова...
А>Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка,
Бесконечное создание объектов? Это что такое? А где вы обычно объекты держите, если не в куче?
Можете в стеке создавать... Вот вам структуры.
Что такое тасовка? Управление? Так оно и быстрее частенько, чем ручная манипуляция...
А> тупой GC
Мне прямо даже обидно за людей. Вот так делали, делали, столько там навернули, а вы прямо так его "тупой". Это в чем же? И как бы вы сделали его умнее? Только не говорите мне про счетчик ссылок — проверено, это гораздо медленнее.
А>жирные (чересчур)высокоуровневые конструкции для всего на свете
Это вы так объекты называете? Или что? О чем речь то?
А>низкая квалификация типичного .НЕТ-програмера
Низкая квалификация? Откуда дрова? Типа "если с трактором не умеешь обращаться, то гонщиком не быть"?
А>именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем.
Т.е. неквалифицированный программист С++ в среднем делает код, который работает в разы быстрее и в разы меньше памяти ест?
А>С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать.
А зачем сравнивать? Меня не напрягает, что моя машина не развивает 300км/час. А должно? Может просто бывают требования к производительности, которым надо удовлетворять, а все остальное никому не нужная трата времени?
А> А память нынче более доступна в цене, чем хорошие программеры.
Хороший программист это не тот, кто умеет память экономит. Я уверен.
А>У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает
Ну почему, он может еще работать хреново. Так и в чем тут преимущество — по вашей логике — так был бы код и работал бы. А так вообще ничего. Вот тебе плюс...
А>тупых сажают документацию писать
Вы любитель тупой документации? Хуже не бывает...
А> или же они менеджерскую/архитекторскую/аналитическую карьеру делают
Это что же хорошо, если архитектор или менеджер тупой? Это будет еще хуже тупого программиста...
А>А в .НЕТ таким кадрам многое по-плечу, они и наяривают.
А знаете, иногда больше и не надо. И слава богу, что теперь не надо помнить коды перфокарт.
А>Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
Я с вами согласен — плохой программист — это плохо. Но язык должен быть чем проще, тем лучше. Есть и другие важные факторы, но простота использования языка важна как хорошему, так и плохому программисту в равной степени.
В остальном же я вообще не понимаю. Вы видимо на C++ пишите, и здесь читаете, чтобы знать врага в лицо.
Ну сделал и сделал — чего кричать-то?
Как я понял, ты сравнил C#-прогу с аналогичной, но под Win32. Так?
MS>JIT имеет больше возможностей для оптимизации, чем C++ компилятор.
С какой стати? C# делает псевдокод, потом JIT его перемалывает в машинный. А Ц++ сразу имеет право генерить x86.
Т.е. там, где у JIT идёт абстрактный поток команд, у Ц++ полная инфа об алгоритме.
MS>Это я не помню как оптимизация называется. Но на семинаре по гайдам МС всегда приводят эту строку в пример — говорят, не пытайтесь думать за компилятор — он неплохо соображает и знает что делать... В данном случае вроде как он исключает проверку выход за пределы массива, так как по объявлению цикла видит, что он никогда не выйдет.
Значит парень просто недотумкал с ключами компилера — мог бы оптимизировать.
Неважно, КАКОЙ КОНКРЕТНО транслятор лучше. Здесь речь о том, что есть абстрактный компилятор, который переводит исходный код в МАШИННЫЕ КОМАНДЫ. Есть другой транслятор, который переводит этот же исходник в команды IL (тут уже конкретный мелкомягкий продукт). Кстати, какой-то умник выше продолжает талдычить, что IL — это вовсе не ассемблер. Отсылаю его сюда: http://se.math.spbu.ru/Courses/dotNET/Examples/CSharp_1.html дабы он окончательно убедился в своей некомпетентности.
Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), то мы увидим очевидное преимущество native компилятора — он может использовать архитектурные особенности процессора, вместо того, чтобы поддерживать "обобщённую виртуальную машину".
Здравствуйте, Thornik, Вы писали:
T>Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м? Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного, посему не понимаю возмущений. Ближе к теме, меньше понтов, ага?
Хотел забавнить но столь искрометного хамсва, и распухшего до небес самомнения еще не видел. Так что хочется поглядеть на продолжение.
Излогайте дальше сэр! Ваши понты начинают не по детски прикалывать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, проекты компилировались в Visual Studio 2005 Express Edition, в C++ все оптимизации выставлены на скорость.
Когда публикуешь орезультаты тестов то публикуй и исходники этих тестов. Иначе никто ничего сказать не сможет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
T>>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД. WH> Ну и упертый же ты. Гугли "трехадресный код" и читай до просветления. IL за однин проход преобразуется в трехадресный код.
Wolf, ты вообще в теме или так, попИсать вышел? Какой в ... трехадресный код? Мы говорим об оптимизации.
T>>А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), WH>При этом тебе не стыдно говорить об оптимизаторах не зная как они работают даже в общих чертах.
Ну естественно! Если нечего сказать, остаётся закидать шапками. Вы, наверное, здесь самый главный по оптимизаторам? Тогда непонятно, почему ваш флейм никак не перерастает в качественное обсуждение. Наверное, вы всё же больше трепло, м?
T>>то мы увидим очевидное преимущество native компилятора — он может использовать архитектурные особенности процессора, вместо того, чтобы поддерживать "обобщённую виртуальную машину". WH>Осталось только доказать что JIT не может это делать.
А тут доказывать не надо: ТЕОРЕТИЧЕСКИ можно оптимизировать всё что угодно. Практически — дело не идёт дальше десятка паттернов, которые (в реализации мелкомягких) ещё и умудряются испоганить оптимизированный код. Я уже привёл пример со SWAP — да, ПОТЕНЦИАЛЬНО и эту команду можно распознавать. Но есть ещё тонны других, менее тривиальных случаев.
K> Представьте, что вы разрабатываете утилиту на с++ в течение года...
Ну если "год", то не такая уж это и "утилита"
Вы, видимо, несколько переоцениваете "ускоряющие" возможности C#. Скажу больше: ни ООП, ни ФП, ни прочие мозгозавихрения НЕ УСКОРЯЮТ разработки. Парадигма — это всего лишь ВЗГЛЯД на архитектуру программы. Если программа создаётся, она должна делать что-то НОВОЕ. И это новое НАДО ПИСАТЬ — хоть на чём, неважно.
Т.е. у программы всегда есть некий объективный минимум, быстрее которого просто НЕВОЗМОЖНО написать код. А в случае C# и C++ — вообще смех сравнивать, это почти одно и то же.
> ... то на добавление фичи у вас уйдет месяц или два. А у ваших конкурентов неделя от силы
Неверно, см. аргументацию выше.
По идее, "добавление фичи" зависит только от грамотности изначальной архитектуры.
> возможная кроссплатформенность
Не делайте мне смешно! Мелкомягкие заинтересованы ТОЛЬКО в Винде. Как максимум — использование своих утилит в Линуксе. В идеале — умерщвление Линукса.
Здравствуйте, zzzale, Вы писали:
Z>Вообще-то компиляция происходит один раз. Z>Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет.
Это может быть верным только для static функций. Если функция не static, компилировать ее обязаны, так как вызов может быть из другого файла им им займется уже линкер.
Здравствуйте, VladD2, Вы писали:
VD>К тому же фанатам оптимизации нужно знать, что примитивные инструкции вроде movs на практике сегодня выигрыша не дают. Процесоры ведь давно разбивают их на примитивы.
Более того, на современных процах эти команды работают медленнее пары mov ax, [si]; mov [di], ax! Причина проста — movs не суперскалярен.
Вот ссылки любителям: здесь искать слово movs, отсюда цитата
For example, MOVSD uses both pipes, so no instruction can be executed in parallel with MOVSD.
The use of both pipes does make MOVSD nearly twice as fast on the Pentium as on the 486, but it's nonetheless slower than using equivalent simpler instructions that allow for superscalar execution.
Movs блокирует суперскалярность и выполняется "в эксклюзиве". За время его выполнения может выполниться большее число примитивных, но суперскалярных инструкций. Так что movs must die!
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, NovaCxarmulo, Вы писали:
NC>MatFiz пишет: >> Запускай релиз и без дебаггинга — тогда все встанет на свои места
NC>ну.... вообще говоря я так и запускал...
Сказали же — потому что автоматом исключаются проверки выхода за пределы массива при каждом обращении.
P>А чего плохого в том, чтобы подождать 15 сек пока программа загрузится? Photoshop сколько грузится? И ничего, все ждут
Это не было бы так плохо, если бы не было с чем сравнивать. Старт Volkov Commander, который загружается сам, СЧИТЫВАЕТ КОНФИГУРАЦИЮ КОМПА, список каталогов, да ещё отрисовывает это на экране, занимает такие доли секунды, что просто не успеваешь сосчитать! Спрашивается, за каким Х нам программы, которые тратят ДЕСЯТКИ СЕКУНД на всякую лабуду, по вине раздолбаев-архитекторов?
T>>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
OE>ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
Да неважно! Факт тот, что на вход 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, то знай, ты разумно поступил, что залез из под анонимайзера. Так как выступления из бани караются баней по IP.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Andrbig, Вы писали: A>>И какой командой на C++ можно проанализировать этот самый "флаг переноса"?
А>естественно никакой. т.к. это платформенно-зависимый код. (под С++ подразумевается стандарт)
а вот в C# проанализировать можно...
сравни:
byte a;
a = 255;
checked { a++; }
и
byte a;
a = 255;
unchecked { a++; }
разница в выполнении есть?
Тот кто говорит не знает, тот кто знает не говорит.
А что вы удивляетесь? Сколько лет назад последний раз обновлялся С++ компилер? вот-вот а JIT компилер вышел совсем недавно, это к тому прогеры-компиляторщики тоже улучшают свои качества, и вкладывают их в новые компилеры.
ищем по слову SWAP. Там мой пример того, почему JIT-у будет проблематично(но реально) оптимизировать код. Ещё раз подчеркну: это только ОДИН случай, коих могут быть миллионы (по разнообразию алгоритмов). Жду комментов.
T>>Наверное, вы всё же больше трепло, м? WH>Давно не мылся? Ну так баня на RSDN безразмерная. И если ты будешь продолжать в томже стиле то ты там окажешься.
Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м? Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного, посему не понимаю возмущений. Ближе к теме, меньше понтов, ага?
T>>Я уже привёл пример со SWAP — да, ПОТЕНЦИАЛЬНО и эту команду можно распознавать. Но есть ещё тонны других, менее тривиальных случаев. WH>Я бы конечно мог объяснить...
Не надо разглагольствований. Любую проблему можно кратко и понятно описать. "Кто ясно мыслит, тот ясно излагает" (с) (кто-то умный)
Я уже в третий раз показываю людям с чем у jit могут быть грабли. В ответ один трындёж, передёргивания и бузина с дядькой.
Не нравится — оканчивайте флейм, разойдёмся каждый при своём.
Re[10]: CF - carry flag
От:
Аноним
Дата:
21.04.06 18:39
Оценка:
находится в регистре FLAGS
CF — флаг переноса. устанавливается если арифметич. операция вызвала перенос или заем из старшего бита результата
Здравствуйте, Thornik, Вы писали:
T>Простой пример: надо обменять два байта в слове, что в исходнике закодировано операцией $. Если выражать это на IL, то получится примерно так:
T> T>Сделать копию операнда T>Копию сдвинуть влево, оригинал — вправо (оба с заполнением нулями) T>OR на операнд и копию T>
T>А на x86 это делается одной командой SWAP.
T>Теперь разница есть?
Пока не заметно. А ты уверен, что SWAP будет быстрее, чем вышеприведеный набор команд эквивалентный SWAP-у? Не факт. А тебе знакомы концепции CISC и RISC? Так шта...
Здравствуйте, Thornik, Вы писали:
T>Теоретически — ничто, надо только самую малость — уметь распознавать ИМЕННО ЭТОТ кусок кода.
Нет. Есть методики анализа, такие как SSA/SSI, которые позволяют точно понять, какое значение как используется. И сгенерировать оптимальные инструкции, особенно если под рукой есть хорошая модель целевой архитектуры. T>И что вы предлагаете, КАЖДОЕ такое место проверять на паттерны? Не устанете? T>И потом, это тривиальный случай (хотя даже за него я не уверен, что у JIT будет именно SWAP — поинтересуйтесь у мелкомягких). А как быть с остальными? Вот тоже тупой, но показательный пример: есть массив, в нём 32 байта. Их все надо заполнить числом (это не объявление, это уже алгоритм!). Самое оптимальное — вызвать 4 раза команду из MMX для каждого 8-байтового блока со специальным аргументом. Будет ли это же самое делать jit?
Совершенно точно будет. Молодец, что привел пример. Более того, если ты полезешь своими шаловливыми ручками в ассемблер и наваяешь этот же алгоритм вручную, он мигом упадет на процессоре без MMX. А вот джиту по барабану — он применит лучший вариант для текущей архитектуры. При этом в полученном нативном коде даже проверок на наличие MMX не останется. T>Хрена с два — по алгоритму ему положено пройти по 32-ум байтам и занести в них константу.
Твои представления об устройстве компиляторов отстали от реальности лет примерно на двадцать пять. Поэтому крайне рекомендую для начала вьехать в тему, почитав литературу. Например, хотя бы любую из modern compiler Аппеля.
Вкратце: джит совершенно не обязан компилировать каждую IL инструкцию отдельно. Поэтому сама фраза "по алгоритму ему положено" — верх глупости. По алгоритму джит может даже порядок выполнения присваиваний переставлять, потому что ему видно, что от этого ничего не зависит. T>В лучшем случае ("лучшем" для мелкософта) можно оптимизировать проверку границ (и то если правильно написать исходный код). T>Ну и что лучше?
Лучше, мой дорогой друг, избегать бравирования невежеством.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, BackstreetCat, Вы писали:
BC>>To VladD2 BC>>Лишать своего оппонента слова, пусть даже ведет он себя не совсем корректно это удар ниже пояса.
A>Любая свобода порождает ответственность. Некорректно он будет себя вести у себя на кухне. Форум — общественное место с вполне известными правилами поведения.
Да уж. Хотя, на самом деле лучше было бы его оставить в "живых". Потому что это было просто смешно. Только обсуждение тогда надо было перенести в форум "коллеги, улыбнитесь" A>Есть мнение — аргументированно выскажи. Не можешь опровергнуть аргументы оппонента — согласись, что неправ.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
Щас тут многие скажут "ну дык".
Но вообщем-то ничего непонятного. Разница не велика. Так что особо не о чем говорить.
То, что не медленнее, это было понятно — в конечном итоге все-равно машинный код.
JIT имеет больше возможностей для оптимизации, чем C++ компилятор.
Так что неудивительно.
NC>2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0; NC>i < arr.Length; ++i) выполняется быстрее, чем если длину массива NC>записать в отдельную переменную... (после вынесения arr.Length в NC>отдельную переменную время сортировки увеличилось с 86 до 116 сек).
Это я не помню как оптимизация называется. Но на семинаре по гайдам МС всегда приводят эту строку в пример — говорят, не пытайтесь думать за компилятор — он неплохо соображает и знает что делать... В данном случае вроде как он исключает проверку выход за пределы массива, так как по объявлению цикла видит, что он никогда не выйдет.
Здравствуйте, tilarids, Вы писали:
T>Главное в моей мысли — это то, что не нужно искать в языках виноватых или супер крутых. Виноват чаще всего программист, и программы пишет программист. Вот на это нужно обращать внимание. А охаять можно любой компилятор. Например, я уверен, что то, что С++ все же работал медленно в этом тесте — это тоже проблема программиста, а не компилятора.
А с этим никто не спорит.
Просто есть некая фобия что C# работает сльно медленней чем С++...
T>К тому же, идёт полная перекомпиляция. То есть, можно учесть не просто тип процессора, а версии библиотек, версии софта установленного, можно учесть всё
Только все это на практике работает с таким трахом...
T>"Наш биатлонист плохо управляется с лыжами, поэтому давайте будем только стрелять" Как видеть недостатки в С++(например, в отладке) — так это мы сразу, а как у себя чего-то увидеть — не корректно.
Проблема в том что в реальной жизни пару секунд на старт никто не заметит.
А если это сервер то время запуска вобще никого не волнует.
Заметят лишь основную работу. А ты предлагаешь измерять разогрев ВМ и скорость работы винта.
Вобще говоря сделать корректный микробенчмарк работа очень не простая.
T>Правильное выражение. 90% кода пишутся криворукими программистами. Но, простите, разве зеркалка за $4500 виновата, что фотограф забыл вдохновение дома?
Столь примитивная демагогия на старожил RSDN не действует... за многие годы имунитет выработался...
T>Так это на 20% больше железок нужно А если общая стоимость железок — $90000, то 20% — это сумасшедшие деньги Неужели нельзя найти программеров на $18 тыс., которые эти 20% уберут? Вообще, смысл моей ремарки был в том, что 20% — это очень даже важно, а не то, что я здесь прочитал
Люди которые в состоянии это сделать в москве стоят 3-5K$ в месяц. Также учти что писать на С++ труднее и дольше.
И я тебе больше скажу как правило процессор и память не являются узким местом в системах массового обслуживания.
Как правило тормозят винты. На втором месте сеть.
T>Ну, сейчас начнётся Это спор из оперы "Что лучше для сервака — Linux иди Windows?"(Правильный ответ — хороший админ). T>Такие споры(и этот тоже) рождаются по причине, которую я указывал здесь
Ты не на того напал. Я умею выберать инструменты под задачу.
Сейчас например читаю исходники lighttpd (написан на С) с целью захачить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, tilarids, Вы писали:
T>1. Не хочу обижать топикстартера, но то, что он использовал в качестве теста, с большим трудом можно назвать пузырьковым алгоритмом сортировки.
Это не имеет значения. Главное что алгоритм одинаковый.
T>2. Про преимущества JIT, который при компиляции знает конфигурацию компьютера конечного пользователя. Вот интересно, что мне скажут про Linux подход к установке софта(компиляция из исходников)? Так что никакое это не преимущество
Этим занимает меньшинство даже среди линуксойдов.
В основном народ просто накатывает пакеты и все.
Ибо собрать что-то большое из исхоников на С++ это часы, а то и десятки часов.
T>3. Как можно сравнивать два практически одинаковых куска кода?
Именно так и нужно сравнивать. T>Да у них же машинный код будет практически одинаковый!
Именно это и хотят выяснить. T>Если уж сравнивать, то нужно сравнивать готовые экзешники, запускать их в цикле и засекать время по выходу из экзешников.
А вот это делать нельзя. Ибо у систем с JIT'ом есть некоторое время на раскачку. И учитывать это время не корректно.
T>4. Видел пост, в котором говорится про то, что "писал на MFC, потому что хотел посчитать, как реально работает С++, а не со всякими там маньячными оптимизациями". Так вот, "маньячные" оптимизации — это фича С++. И не юзать ее — это то же самое, что добавлять в код Sleep(1); после каждой итерации. Оптимизация должна быть на полную включена, иногда от этого сильно зависит проивзодительность. Большая часть кода пишется без маньячных оптимизаций. Факт медицинский.
T>Есть 5 обслуживающих аппаратов. Их достаточно для того, чтобы пропускать поток покупателей без задержек. Внезапно ломается один из аппаратов(пресловутые 20%). Мгновенно выстраиваются очереди и люди начинают уходить(по таймауту )
Как правило дешевле поставить еще одну железку. Это я тебе как краевед массового обслуживания говорю.
ЗЫ Кстати практика показывает что в системах массового обслуживания JIT'ы чувствуют себя очень не плохо. У нас есть схожие системы на С++ и Жабе(миллионы запросов в сутки). С системой на жабе проблем меньше...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexZu, Вы писали:
AZ>Почему? Для релиза также можно включить генерацию отладочной информации.
Включить можно. Но мои слова это не изменит. Запустив даже релиз-версию из под отладчика мы получим не оптимизированный код. Только запус без отладчика приведет к тому, что JIT-перейдет в режим оптимизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nimnul, Вы писали:
N>А что вы удивляетесь? Сколько лет назад последний раз обновлялся С++ компилер?
В конце 2005-го?
N>вот-вот а JIT компилер вышел совсем недавно
В конце 2005-го?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Скорость C# это что-то непонятное
От:
Аноним
Дата:
18.04.06 03:06
Оценка:
а я слышал что С++ больше не поддерживается МС. так что там тотже самый старый С++. Что касается компилятора то он не претерпивал серьезных изменений с тех пор как он был написанн, под x86.
Здравствуйте, Nimnul, Вы писали:
N>а я слышал что С++ больше не поддерживается МС. так что там тотже самый старый С++. Что касается компилятора то он не претерпивал серьезных изменений с тех пор как он был написанн, под x86.
Здравствуйте, Thornik, Вы писали:
T>С какой стати? C# делает псевдокод, потом JIT его перемалывает в машинный. А Ц++ сразу имеет право генерить x86. T>Т.е. там, где у JIT идёт абстрактный поток команд, у Ц++ полная инфа об алгоритме.
Мне нравится. Абстрактный поток команд значит... 5 баллов.
У C++ идет алгоритм, а IL код это абстракционизм и вообще не алгоритм...
T>Значит парень просто недотумкал с ключами компилера — мог бы оптимизировать.
"Парень" сказал, что настроил по максимуму. Что там тумкать — в большинстве случаев компилятор С++ делает все что может...
Откуда такая уверенность, что конечно C++ компиляторы по определению лучше? Потому что их писали умнее люди, что-ли?
Здравствуйте, Thornik, Вы писали:
T>JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию. T>Я доходчив?
Не совсем. Приведи, пожалуйста, пример "сложной операции".
Элементарно! Свежий пример буквально из личных алгоритмов:
Делал конвертер из "бинарного" формата в "читабельный" (Base64), но байты декомпозицировал не как длинную цепочку бит, а просто отрезал от каждого байта "верхушку" и сунул в четвёртую. Не суть. Факт тот, что мне понадобился флаг CF, который В ПРИНЦИПЕ не может существовать в "виртуальной машине" или псевдокоде. Ну то есть ввести его можно, но выглядеть он будет глупо.
Я соглашусь, это не совсем те условия, что были в оригинале. Но если допустить, что в языке будет операция a = #(массив); (некая абстр. запись Base64), то увы, "псевдокодная" реализация операции никогда не будет реализована через x86-шный CF, а значит всё что остаётся jit'у — это оптимизировать то, что налабали мелкомягкие в качестве псевдокодной реализации #().
Здравствуйте, Thornik, Вы писали:
MS>>Мне нравится. Абстрактный поток команд значит... 5 баллов.
T>А чего ёрничать? Если не понял ответа, подумай второй раз. T>JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию. T>Я доходчив?
А чего не ёрничать, если вы думаете, что IL код генерится тупыми компиляторами.
Или если вы думаете, что там близко к ассемблеру...
T>Он сказал, а я проверил на деле — ОПТИМИЗАЦИЯ БЫЛА ВЫКЛЮЧЕНА. Правда, после включения результат был не лучше.
Ну так и вот я о том же. Я в свое время наигрался с этими ключами — толку мизерно мало.
MS>>Откуда такая уверенность, что конечно C++ компиляторы по определению лучше?
T>А разве я говорил, что они лучше? Если договорить мою мысль, то я уверен в следущем: хороший компилятор выдаёт программу, которая ВСЕГДА БЫСТРЕЕ любого jit'а.
JIT не компилятор или плохой и IL не код, а машинные команды. Ну вообще вернулись к тому с чего начали...
T>Разумеется, если мелкософт не научилась делать Ц++ компилеры, это не повод говорить, что C# лучше.
Как-то не знаю... Вот мой опыт показывает, что у них отличные C++ компиляторы.
T>Правда, стоит отметить, что вообще сами по себе ООП языки — костыли ещё те. Если уж чешется сравнивать, то надо брать простой Си и Цэшарп.
Щас я вам ссылку дам. Правда это под дебиан тесты и .нет там моновский...
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Исходники проектов и файл, на котором проводился тест здесь
При отценке време нельзя использовать функцию GetSystemTimeAsFileTime() так как во время выполнения сортировки планировщик может переключится на другую задачу. Нужно использовать функцию GetThreadTimes().
Здравствуйте, Thornik, Вы писали:
T>Делал конвертер из "бинарного" формата в "читабельный" (Base64), но байты декомпозицировал не как длинную цепочку бит, а просто отрезал от каждого байта "верхушку" и сунул в четвёртую.
В "четвёртую" что?
T>Не суть. Факт тот, что мне понадобился флаг CF, который В ПРИНЦИПЕ не может существовать в "виртуальной машине" или псевдокоде. Ну то есть ввести его можно, но выглядеть он будет глупо.
Здравствуйте, <Аноним>, Вы писали:
А>А просто компилятор си шарпа очень хорошо оптимизирует код, а в данном случае так как ясно что за границы массива А>индекс не вылезет то проверку на выход за границы убирают
Все верно, только это заслуга не компилятора си шарпа, а jit-а.
WH>Мда... Полное не понимание того как работают оптимизаторы.
Послушайте, милейший, вы словами не бросайтесь, ладно? А то как-то тошнит от выпендрёжей.
Если умеете выражаться кратко и по существу — велкам, а если надо понты кидать — для этого есть другой форум.
WH>При переводе из C# в IL с точки зрения оптимизатора не происходит потери информации.
Для оптимизатора IL может так оно и есть. Выше я привёл пример с CF — по этому поводу есть что сказать?
Здравствуйте, californie, Вы писали:
C>а уж если c# приложение вначале сконвертить ngen.exe то скорость еще выше станет...
Скорость загрузки и потребление памяти при множественном использовании библиотеки.
Еще скорость выше станет на редковызываемых методах. В остальном не станет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, Thornik, Вы писали:
T>А вы считаете себя глупее компилятора?
T>Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу.
Следуй. Но не жалуйся тогда на производительность.
K>Не факт. Разница в большинстве случаев очень незначительная. Для FW 2.0 по крайней мере. Разве только загрузку ускоряет.
Не разве, а только лишь — что еще оно может улучшить?
в ngen используется в точности тот же компилятор.
Хуже того — mSDN говорит о каких-то дополнительных возможностях jit, недоступных при ngen.. не знаю, реальных или теоретических, но, в общем, использование ngen теоретически может даже _замедлить_ выполнение программы.
Здравствуйте, Thornik, Вы писали:
MS>>Мне нравится. Абстрактный поток команд значит... 5 баллов.
T>А чего ёрничать? Если не понял ответа, подумай второй раз.
Ой я тут очень понимаю Max.Subpixel-а. Я когда отровенную глупость слышу, тоже тянет поерничать. Вот такой дурной характер.
T>JIT на входе получает, скажем так, "почти ассемблер".
Ассемблер говоришь? Ты Рефлектором мользушся? Видил как он декомпилирует этот ассемблер во вполне читаемый код? Как думашь, что мешает тогда и JIT-у разобраться в этом "ассемблере"?
В общем, MSIL конечно ассемблер, но типизированный и содержащий всю информацию необходимую оптимизирующему компилятору.
Скажу больше, большинство современных оптимизирующих С++-компиляторов производят оптимизации не над AST, а над специальной формой довольно низкоуровневого кода очень похожей на MSIL.
Чтобы быть в теме очень советую покурить на досуге Phoenix.
T> Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию. T>Я доходчив?
Очень доходчиво... и красноречиво показал, что не владешь темой.
T>А разве я говорил, что они лучше? Если договорить мою мысль, то я уверен в следущем: хороший компилятор выдаёт программу, которая ВСЕГДА БЫСТРЕЕ любого jit'а.
Обоснования этому утверждению будут?
T>Разумеется, если мелкософт не научилась делать Ц++ компилеры, это не повод говорить, что C# лучше.
T>Правда, стоит отметить, что вообще сами по себе ООП языки — костыли ещё те. Если уж чешется сравнивать, то надо брать простой Си и Цэшарп.
В общем, советую тебе не позориться, выключить понты и разобраться в обсуждаемой теме. А потом продолжим.
Начать можно отсюда, далее покурить Феникса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SiAVoL, Вы писали:
T>>И потом, неплохо бы иметь такие директивы, которые позволяют персонально каждому массиву задавать параметр — нужна ему эта долбаная проверка выхода за границы или нет SAV>курить unchecked keyword
unchecked к массивам отношения не имеет. Это возможность игнорировать переполнение при вычислениях. А вот отказаться от проверок выхода за пределы массива можно только если перейти на unsafe и указатели. Вот только это редко когда дает реальные приемущества. Тот же вынос проверки за пределы циклов устраняет оверхэд возникающий от зашиты предоставляемой дотнетом.
T>>(нормальная программа 100% в ней не нуждается). SAV>спорное утверждение, но в любом случае проверки можно отключить и для всей программы в целом
Нельзя. А утверждение более чем спорное.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В>На вопрос что такое CF посылать в ветку, где первое упоминание CF это "Факт тот, что мне понадобился флаг CF..."
А! Понятно. Уважаемый, тогда вас надо отсылать не то что вверх, а вообще куда-то туда..
Видите, как всё завязано: все кругом флеймят — то у них C# крутой, то Хаскель, а на самом деле без ассемблера — никуда.
Здравствуйте, _d_m_, Вы писали:
___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
ИМХО ты сильно переоцениваешь время которое сожрет болие умная оптимизация.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Thornik, Вы писали:
T>Спрашивается, за каким Х нам программы, которые тратят ДЕСЯТКИ СЕКУНД на всякую лабуду, по вине раздолбаев-архитекторов?
А за тем, что за все нужно платить. Представьте, что вы разрабатываете утилиту на с++ в течение года. Она замечательно работает, практически мгновенно грузится. Вы выходите с ней на рынок и обнаруживаете, что уже есть утилита на C#, которая делает все тоже самое, но ГРУЗИТСЯ 10 секунд. И что самое страшное, на ее разработку ушел 1 месяц. И она уже успешно продается в течение 11 месяцев. Вашу утилиту никто не купит, потому что, если вы ее год ваяли, то на добавление фичи у вас уйдет месяц или два. А у ваших конкурентов неделя от силы. + возможная кроссплатформенность. Неговоря уже о стоимости разработки.
Здравствуйте, Thornik, Вы писали:
T>убедился в своей некомпетентности.
Это ты про кого?
T>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД. Ну и упертый же ты. Гугли "трехадресный код" и читай до просветления. IL за однин проход преобразуется в трехадресный код.
T>А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать),
При этом тебе не стыдно говорить об оптимизаторах не зная как они работают даже в общих чертах. T>то мы увидим очевидное преимущество native компилятора — он может использовать архитектурные особенности процессора, вместо того, чтобы поддерживать "обобщённую виртуальную машину".
Осталось только доказать что JIT не может это делать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
T>>Да неважно! Факт тот, что на вход JIT подаётся не программа, а уже скомпилированная под "универсальный псевдопроцессор" куча команд.
brn> Сколько себя помню, я всегда считал что компилятор оптимизирует код на каком-то более позднем этапе
Я не спорю, И ТАКИЕ оптимизаторы имеют место быть. Однако, исходник даёт куда больше информации...
Простой пример: надо обменять два байта в слове, что в исходнике закодировано операцией $. Если выражать это на IL, то получится примерно так:
Сделать копию операнда
Копию сдвинуть влево, оригинал — вправо (оба с заполнением нулями)
OR на операнд и копию
А на x86 это делается одной командой SWAP.
Здравствуйте, 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, Вы писали:
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) А. Эйнштейн
Здравствуйте, NovaCxarmulo, Вы писали:
NC>CF — флаг процессора, устанавливается, если арифметическая операция NC>произвела перенос из старшего бита результата, старшим является 7, 15, NC>31 биты, в зависимости от размерности операнда. (с) В.И. Юров, "Assembler"
Здравствуйте, NovaCxarmulo, Вы писали:
NC>угу... то-то у меня на работе проект без оптимизации компилируется 15 NC>минут, а с оптимизаций несколько часов....
Это каким компилятором? У меня есть подозрение что там что-то не то с ключами ибо в моей практике релиз компилится как правило быстрее чем дебуг ибо генерится меньше временных файлов.(это если мы про С++ говорим)
К томуже скорость компиляции у С++ и C# немного разная...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Любой вменяемый компилятор перводит сначала исходный код в в промежуточный код (intermediate code или intermediate representation (IR)). И уже затем этот код оптимизируется. Никто не оптимизирует ИСХОДНЫЙ КОД. Как ты вообще себе это представляешь?
В принципе на базе AST тоже можно делать оптимизации. Более того некоторые из них даже выгодно делать на этом уровне. Например, ОО-оптимизации, переписыание кода. Но как раз подобных оптимизаций С++-ные компиляторы и не делают. Им мешают указатели. Ведь не дай бок кто-то зацепил объект указателем или еще хуже через void тип привел и приплызд гарантирован.
IT>Так вот, IR любого компилятора как набор данных для оптимизатора не сильно отличается от IL.
Более того Феникс как раз и занимается конвертацией IL в IR. Там в разделе расскзывающем о IR говорится, что у байкода Явы есть такие-то свойства, у MSIL-а такие-то, а при переводе в IR производится декомпозиция и оба набора свойств становятся доступны в IR.
IT>В общем, пора тебе прекращать заниматься фантазёрством.
Самое забавное, что человек даже не напрягает себя чтобы тыкнуть в ссылки и прочесть то что там написано. Вместо этого в наглую оскорбляет окружающих понтует... и обвиняет в этом оппонентов.
В общем, забавнейший тип. Даже банить жалко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _d_m_, Вы писали:
___>Да в принципе, алгоритм псевдослучайной последовательности прост как три копейки. Я не думаю, что стандартные средства чем-то отличаются. Можно использовать и их. Эти же алгоритмы применяются для генерации белого шума и для алгоритмов симметричного шифрования — начальное значение seed — есть ключ.
Смысл эттго куска кода в другом. То, что линейный конгруэнтый метод генерации псевдослучайной последовательности прост -- это правда. Проблема в тестах была в том, что rand из C RTL (кстати, она ведь у каждого компилятора своя) и Random из FW имеют разные параметры генератора. А хотелось получить абсолютно идентичные тесты. Поэтому пришлось использовать самописный генератор во всех испытаниях. Константы из этого фрагмента я, кажется, из исходника RTL VC 8.0 выдернул.
Здравствуйте, _d_m_, Вы писали:
___>Ага, прикольно. Скорее всего, подросток забавляется с ассемблером просто потому, что это "ну очень круто". И соответственно считает себя приверженцем некой высшей касты. Я лабал на асме в 93-ем — вирусы для DOS писал.
Я все же забанил это чудо, так как в другом сообщении нашел откровенный мат. Причем с сутью собщения я был согласен, но мат это уже переполнило чашу терпения.
Что до подростка, то это не наше дело. Бывают и 40-а и более летние дядки упертые по самые не хочу.
Что действительно подозрительно, в очередной раз это бывший Дельфист
. Ничего не хочу сазать против Дельфи или Дельфистов, но блин, уж больно часто среди Дельфистов и ВБшников появляются вот такие воинствующие личности позорящие не только себя, но и Дельфи/VB. Боюсь, что C# ждет тоже самое. Простота входа приводит к тому, что люди переоценивают себя и свои знания и считают, что заниматься серьезным самообучением не нужно. Зато прослеживается каке-то невероятное желание судить обовсем насвете не пытаясь разобраться в обсуждаемом предмете глубже.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
да Thornik вобще ламер накидал вначале понты про CF в C++ . Милейший Thornik да будет тебе известно CF это флаг регистра флагов eflags в архитетуре процессора x86 и используется он в основном для команд условного перехода таких как jne\jnz, в связи с этим совершенно непонятно что ты там лепетал про биты и оптимизацию.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Маленькое замечание. PD>Теоретически — да. А практически — у компилятора С++ на это времени столько, сколько надо. Если релиз компилируется 5 минут, то в этом ничего особенного нет. PD>А вот у JIT такого времени нет и не будет
Еще раз: С++ компилируется медленно из-за структуры языка, а оптимизатор ест относительно немного времени.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>Еще раз: С++ компилируется медленно из-за структуры языка, а оптимизатор ест относительно немного времени.
Медленно или быстро он компилируется, виной тут структура или нет — это, может быть и существенно, но я не об этом говорю. А о том, что у не-JIT компиляторов времени сколько угодно, а у JIT — ограничено. Поэтому в обычных компиляторах можно применять сколь угодно сложные алгоритмы, не слишком заботясь о времени, а в JIT- нельзя.
Здравствуйте, Nimnul, Вы писали:
N>от возмущения аж флаги перепутал CF используется в командах JB\JC\JNAE, JO, JBE\JNB и впрочим в многих других условных переходах. А jne\jnz использует ZF флаг. еще CF используется для проверки переполнение регистра, после последней операции.
И все? Учите матчасть, батенька. Команды сдвига RCR и RCL используют этот флаг — именно про этот способ и говорил автор.
Другой вопрос, что такие кульбиты вытворяются только в ассемблере и некорректно сравнивать ассемблер с языками высокого уровня.
И еще другой вопрос, что суперскалярность может (наверное) привести к тому, что несколько примитивных логических команд будут в итоге выполнены быстрее, чем это извращение через CF.
Здравствуйте, MisterIsk, Вы писали:
MI>Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC
В том же .net2 GC уже более умный, по сравнению с первым. MI> жирные (чересчур)высокоуровневые конструкции для всего на свете
Если вы имеете в виду синтаксис — то он практически полностью совпадает с С++. MI> низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем.
Проблема не языка, а фирм, которые нанимают неквалифицированных программистов. MI> С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
Сейчас компьютер стоит дешевле, чем программист. Поэтому экономить выгоднее не на мощных компьютерах, а на первоклассных программистах. На C# писать легче — поэтому можно брать программиста с более низкой квалификацией (но адекватной, а не "мастера", о котором Вы писали выше). MI>У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
С++ предоставляет доплонительные возможности для совершения ошибок, от которых не застрахованы даже профессионалы. Тот же переход в свитче по умолчанию к следующей ветке не выглядит сложным и редко опытный программист в этом ошибается, но никто не застрахован от таких глупых ошибок на 100%, и с повышением квалификации программиста увеличивается уже не блестящее синтаксиса языка (оно уже предполагается), а знание библиотек, хороших решений для разных задач, умение проектировать и т.д.
Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0,
проекты компилировались в Visual Studio 2005 Express Edition, в C++ все
оптимизации выставлены на скорость.
1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов
Время сортировки на
C#: 86.26 сек.
C++: 98 сек.
Пробовали запускать тест на другом компе — резуотат тот же... Шарп
оказался быстрее...
Именно так — C# справился быстрее.... сортировал один и тот же массив
(читал из файла), запускал тесты несколько раз, алгоритм сортировки один
и тот же (отличаются только синтаксические детали языков).
2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0;
i < arr.Length; ++i) выполняется быстрее, чем если длину массива
записать в отдельную переменную... (после вынесения arr.Length в
отдельную переменную время сортировки увеличилось с 86 до 116 сек).
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Re: Скорость C# это что-то непонятное
От:
Аноним
Дата:
13.04.06 19:32
Оценка:
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, NC>проекты компилировались в Visual Studio 2005 Express Edition, в C++ все NC>оптимизации выставлены на скорость.
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
NC>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>оказался быстрее...
NC>Именно так — C# справился быстрее.... сортировал один и тот же массив NC>(читал из файла), запускал тесты несколько раз, алгоритм сортировки один NC>и тот же (отличаются только синтаксические детали языков).
NC>2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0; NC>i < arr.Length; ++i) выполняется быстрее, чем если длину массива NC>записать в отдельную переменную... (после вынесения arr.Length в NC>отдельную переменную время сортировки увеличилось с 86 до 116 сек).
Здравствуйте, Max.Subpixel, Вы писали:
MS>Щас тут многие скажут "ну дык".
Дык, и будут правы. Особенно если учесть невироятное количество фобий порождаемых по этому вопросу.
Только давича нам рассказывали, что дотнет интерпретатор, и вообще сравнение байтов нужно писать на С++.
MS>Но вообщем-то ничего непонятного. Разница не велика. Так что особо не о чем говорить.
+1
MS>То, что не медленнее, это было понятно — в конечном итоге все-равно машинный код. MS>JIT имеет больше возможностей для оптимизации, чем C++ компилятор. MS>Так что неудивительно.
Вообще-то у джита куча мест усложняющих потимизацию. Но потенциально все именно так как ты говоришь.
MS>Это я не помню как оптимизация называется. Но на семинаре по гайдам МС всегда приводят эту строку в пример — говорят, не пытайтесь думать за компилятор — он неплохо соображает и знает что делать... В данном случае вроде как он исключает проверку выход за пределы массива, так как по объявлению цикла видит, что он никогда не выйдет.
Небольшое уточнение. Не "исключает", а выносит за пределы цикла. То есть проверка все же есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
не вопрос... где публиковть? просто в тесте сообщения конечно могу, но
думаю это не оч. красиво будет
WolfHound пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, проекты компилировались в Visual Studio 2005 Express Edition, в C++ все оптимизации выставлены на скорость. > Когда публикуешь орезультаты тестов то публикуй и исходники этих тестов. Иначе никто ничего сказать не сможет.
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, NovaCxarmulo, Вы писали:
NC>не вопрос... где публиковть? просто в тесте сообщения конечно могу, но NC>думаю это не оч. красиво будет
На RSDN можно заливать файлы. В форме отправки сообщения есть кнопка "загрузить".
ЗЫ Не отвечай сверху сообщения. Здесь так не принято. И следи за цитированием. Ибо за оверквотинг тут иногда даже банят.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Max.Subpixel пишет: > Здравствуйте, <Аноним>, Вы писали: > > А>отключите safe режим и собирите C++ еще раз > > Мне казалось, человек вообще не в МС++ делал, а в С++...
Да, именно в Native C++, вообще без поддержки CLR, ссылка на исходники в
другой ветке висит.
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, Nimnul, Вы писали:
N>а я слышал что С++ больше не поддерживается МС. так что там тотже самый старый С++. Что касается компилятора то он не претерпивал серьезных изменений с тех пор как он был написанн, под x86.
На КРИ 2006 на одном из семинаров представитель компании Intel Виктория Жислина сказала, что "в 2005 студии компания Microsoft сделала компилятор, который практически не уступает компилятору от Intel, но все же уступает". Из чего можно сделать вывод, что с++ МСом таки поддерживается и даже развивается
Re[3]: Скорость C# это что-то непонятное (исходники)
Вот доказательства того что надо использовать GetThreadTimes() а не GetSystemTimeAsFileTime(). При сортировке файла размером 54528 байт результат был такой:
count: 54528
iix пишет: > Вот доказательства того что надо использовать GetThreadTimes() а не GetSystemTimeAsFileTime(). При сортировке файла размером 54528 байт результат был такой: > count: 54528 > > bubble : 17.385 — GetThreadTimes() > bubble(bad) : 24.9058 — GetSystemTimeAsFileTime() > разница = 7,5208
bubble и bubble(bad) это одна и та же ф-ция?
> stl : 0.0100144 — GetThreadTimes() > stl(bad) : 0.0100144 — GetSystemTimeAsFileTime() >
> NovaCxarmulo ты из Ярославля?
да
а про GetThreadTimes() буду знать...
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Max.Subpixel пишет: > "Парень" сказал, что настроил по максимуму. Что там тумкать — в большинстве случаев компилятор С++ делает все что может...
так, к слову... у "Парня" ник есть....
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Имхо, не на тех задачах меряешь. В c# тесте везде value-типы и jit'у ничего не мешает сгенерить хороший машинный код. GC практически не используется и все те фичи managed-языков, которые их тормозят( тут сразу камнями не забрасывать. согласитесь, что пусть чуть-чуть, но медленне unmanaged-языков. ), не используются.
Да и это не новость. Еще пару лет назад читал про замеры. Так там и fw 1.1 при отключенной проверке выхода за пределы массива практически не уступал с++
Re: Скорость C# это что-то непонятное (собственно что непоня
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Непонятно почему: NC> for( int i = 0; i < arr.Length; ++i )
NC>работает быстрее, чем NC> int len = arr.Length; NC> for( int i = 0; i < len; ++i )
NC>причем значительно....
Запускай релиз и без дебаггинга — тогда все встанет на свои места
How are YOU doin'?
Re[3]: Скорость C# это что-то непонятное (собственно что неп
> Заархивированный файл тебя здал(7z).
а я думал. что ник
думаю если будем продолжать личное общение, то лучше перейти на email'ы
из форума... так что если что — пиши туда....
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, NovaCxarmulo, Вы писали:
>> "Парень" сказал, что настроил по максимуму. Что там тумкать — в большинстве случаев компилятор С++ делает все что может... NC>так, к слову... у "Парня" ник есть....
Я знаю, поэтому в кавычках
Best Regards. Max.
Re[2]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Непонятно почему: NC> for( int i = 0; i < arr.Length; ++i )
NC>работает быстрее, чем NC> int len = arr.Length; NC> for( int i = 0; i < len; ++i )
NC>причем значительно....
Потому что не надо делать вид, что ты умнее компилятора.
P.S. Ничего личного.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Скорость C# это что-то непонятное
От:
Аноним
Дата:
20.04.06 08:50
Оценка:
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, NC>проекты компилировались в Visual Studio 2005 Express Edition, в C++ все NC>оптимизации выставлены на скорость.
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
NC>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>оказался быстрее...
NC>Именно так — C# справился быстрее.... сортировал один и тот же массив NC>(читал из файла), запускал тесты несколько раз, алгоритм сортировки один NC>и тот же (отличаются только синтаксические детали языков).
NC>2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0; NC>i < arr.Length; ++i) выполняется быстрее, чем если длину массива NC>записать в отдельную переменную... (после вынесения arr.Length в NC>отдельную переменную время сортировки увеличилось с 86 до 116 сек).
А просто компилятор си шарпа очень хорошо оптимизирует код, а в данном случае так как ясно что за границы массива
индекс не вылезет то проверку на выход за границы убирают
Здравствуйте, Thornik, Вы писали:
T>А чего ёрничать? Если не понял ответа, подумай второй раз. T>JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию. T>Я доходчив?
Мда... Полное не понимание того как работают оптимизаторы. Очень рекомендую почитать чтонибудь на эту тему.
При переводе из C# в IL с точки зрения оптимизатора не происходит потери информации.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Скорость C# это что-то непонятное (собственно что неп
Lloyd пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>Непонятно почему: > NC> for( int i = 0; i < arr.Length; ++i ) > > NC>работает быстрее, чем > NC> int len = arr.Length; > NC> for( int i = 0; i < len; ++i ) > > NC>причем значительно.... > > Потому что не надо делать вид, что ты умнее компилятора. > P.S. Ничего личного.
я бы не удивился если б результат был бы одинаковый — ну запрашивается
переменная через св-во и всё.... но почему идет замедление цикла?
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, NovaCxarmulo, Вы писали:
NC>я бы не удивился если б результат был бы одинаковый — ну запрашивается NC>переменная через св-во и всё.... но почему идет замедление цикла?
ну тебе же ответили уже... исключаются проверки выхода за диапазон.
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, NovaCxarmulo, Вы писали:
NC> NC>я бы не удивился если б результат был бы одинаковый — ну запрашивается NC>переменная через св-во и всё.... но почему идет замедление цикла?
Потому что ты тем самым запутал jit-компилятор и он не смог выбросить из цикла проверку выхода зы границу массива.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Скорость C# это что-то непонятное (собственно что неп
L>Потому что не надо делать вид, что ты умнее компилятора.
А вы считаете себя глупее компилятора?
Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу.
Если человек ЗАРАНЕЕ ВЫЧИСЛИЛ длинну массива и далее использует её как константу, это есть метод УСКОРЕНИЯ приложения, но никак не наоборот!!!
То, что у мелкомягких проблемы с таким глупым примером, говорит только об одном — в погоне за оптимизацией они забывают про основной алгоритм.
Хуже того: а что если у меня в цикле используется индексатор не i, а (i + j % 7) ?
По-моему, человек вполне законно апеллирует к тому, что его оптимизированный код должен работать как минимум НЕ ХУЖЕ исходного алгоритма.
И потом, неплохо бы иметь такие директивы, которые позволяют персонально каждому массиву задавать параметр — нужна ему эта долбаная проверка выхода за границы или нет (нормальная программа 100% в ней не нуждается).
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, Thornik, Вы писали:
L>>Потому что не надо делать вид, что ты умнее компилятора.
T>А вы считаете себя глупее компилятора?
T>Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу. T>Если человек ЗАРАНЕЕ ВЫЧИСЛИЛ длинну массива и далее использует её как константу, это есть метод УСКОРЕНИЯ приложения, но никак не наоборот!!!
Ну это потому что вы предпочитаете не читать что пишут производители компиляторов. В С++ произойдет тоже самое.
T>То, что у мелкомягких проблемы с таким глупым примером, говорит только об одном — в погоне за оптимизацией они забывают про основной алгоритм.
Здравствуйте, Thornik, Вы писали:
WH>>При переводе из C# в IL с точки зрения оптимизатора не происходит потери информации.
T>Для оптимизатора IL может так оно и есть. Выше я привёл пример с CF — по этому поводу есть что сказать?
Здравствуйте, Thornik, Вы писали:
T>Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу.
если компилятор будет делать только то, что его просят (как это делали самые ранние компиляторы), то производительность будет очень низкой (никаких оптимизаций не будет)
T>Если человек ЗАРАНЕЕ ВЫЧИСЛИЛ длинну массива и далее использует её как константу, это есть метод УСКОРЕНИЯ приложения, но никак не наоборот!!!
это есть попытка оптимизации, которая может и провалиться. А оптимизировать что-то как известно надо только тогда, когда производительность не удовлетворительна. При этом надо производить тесты и замеры. До этого надо выбирать более читабельный вариант.
T>То, что у мелкомягких проблемы с таким глупым примером,
у них нет проблем с этим примером
T>По-моему, человек вполне законно апеллирует к тому, что его оптимизированный код должен работать как минимум НЕ ХУЖЕ исходного алгоритма.
вот именно, оптимизированный (JIT`ом) код работает быстрее
T>И потом, неплохо бы иметь такие директивы, которые позволяют персонально каждому массиву задавать параметр — нужна ему эта долбаная проверка выхода за границы или нет
курить unchecked keyword
T>(нормальная программа 100% в ней не нуждается).
спорное утверждение, но в любом случае проверки можно отключить и для всей программы в целом
Здравствуйте, californie, Вы писали:
C>а уж если c# приложение вначале сконвертить ngen.exe то скорость еще выше станет...
C>данное сообщение получено с www.gotdotnet.ru C>ссылка на оригинальное сообщение
Не факт. Разница в большинстве случаев очень незначительная. Для FW 2.0 по крайней мере. Разве только загрузку ускоряет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Скорость C# это что-то непонятное (собственно что неп
Ryf пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>я бы не удивился если б результат был бы одинаковый — ну запрашивается > NC>переменная через св-во и всё.... но почему идет замедление цикла? > ну тебе же ответили уже... исключаются проверки выхода за диапазон.
да, я тот ответ прочитал после того, как в эту ветку написал...
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, Thornik, Вы писали:
T>То, что у мелкомягких проблемы с таким глупым примером, говорит только об одном — в погоне за оптимизацией они забывают про основной алгоритм.
JIT оптимизирует те паттерны в коде, которым он специально обучен. Это как байка про актёров. Разница между плохим и хорошим актёром в том, что у первого на все случаи жизни лишь пять заготовок, а у хорошего сотня. Твой случай JIT просто пока не опознал, возможно следующие версии смогут это делать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Thornik, Вы писали:
T>Послушайте, милейший, вы словами не бросайтесь, ладно? А то как-то тошнит от выпендрёжей. T>Если умеете выражаться кратко и по существу — велкам, а если надо понты кидать — для этого есть другой форум.
Когда появляется человек и говорит что белое это черное то не остается ничего кроме как отправить его почитать о том как называются цвета.
T>Для оптимизатора IL может так оно и есть.
Так оно и есть для любого оптимизатора. Получить информации о коде написанном на C# больше чем из IL не возможно. При компиляции теряется форматирование и комментарии(надеюсь ты не станешь утверждать что это может повлиять на оптимизацию). Вся остальная информация сохраняется в IL. То что оптимизатор IL пока не очень умный не значит что он теоритически не в состоянии оптимизировать не хуже чем оптимизатор С++. T>Выше я привёл пример с CF — по этому поводу есть что сказать?
Приведи код того что ты имеешь в виду. И за одно потрудись объяснить в чем у С++ преймущество перед IL.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, NC>проекты компилировались в Visual Studio 2005 Express Edition, в C++ все NC>оптимизации выставлены на скорость.
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
Хмм... Очень странно. Думается мне, что Visual C++ не смог правильно соптимизировать ваш алгоритм пузырька (какой-то он странный). Попробуйте заменить функцию сортировки в обоих исходниках на такую:
Здравствуйте, Thornik, Вы писали:
T>Послушайте, милейший, вы словами не бросайтесь, ладно? А то как-то тошнит от выпендрёжей. T>Если умеете выражаться кратко и по существу — велкам, а если надо понты кидать — для этого есть другой форум.
Твое поведение — это поведение воинствующего ламера. Сам в вопросе не понимаешь и набирашся наглости на других оскорблять.
Уж если споришь, то спорь корректно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Так оно и есть для любого оптимизатора. Получить информации о коде написанном на C# больше чем из IL не возможно. При компиляции теряется форматирование и комментарии(надеюсь ты не станешь утверждать что это может повлиять на оптимизацию). Вся остальная информация сохраняется в IL. То что оптимизатор IL пока не очень умный не значит что он теоритически не в состоянии оптимизировать не хуже чем оптимизатор С++.
На самом деле теряется чуть больше. Теряется, например, информация о структурных конструкциях вроде for, if и т.п., но оптимизатору эта информация не так уж и нужна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
Несколько советов эксперементаторам.
1. Измерять время в дотнете лучше с помощью класса System.Diagnostics.Stopwatch. Это и проще и точнее.
2. GC.Collect() вызывать не только глупо но и вредно. GC.Collect() только запускает сборку мусора, и она может идти параллельно. Так что уж если вызывашь GC.Collect(), то стоит вызвать и GC.WaitForPendingFinalizers().
3. Перед запуском первого теста (а лучше вообще между каждым вложенным тестом) следует вызывать Thread.Sleep() со значением 100-300. Это даст CLR сделать всю теневую работу и тест будет более точным. Например, у тебя первый тест вообще не дает реальных результатов.
4. Данные для теста лучше генерировать одинаковым алгоритмом генерации случайных цифр. Это позволит другим не искать разные бинарные файлы, да и упростит сам код.
5. Делая тесты обязательно нужно делать проверку истинности результата. В твоем случае проверять, что массив отсортирован. При этом нельзя использовать общие функции и объекты (вроде компораторов), так как в них могут быть ошибки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов > NC>Время сортировки на > NC>C#: 86.26 сек. > NC>C++: 98 сек. > > Несколько советов эксперементаторам. > 1. Измерять время в дотнете лучше с помощью класса System.Diagnostics.Stopwatch. Это и проще и точнее.
ок, буду знать на будущее...
> 2. GC.Collect() вызывать не только глупо но и вредно. GC.Collect() только запускает сборку мусора, и она может идти параллельно. Так что уж если вызывашь GC.Collect(), то стоит вызвать и GC.WaitForPendingFinalizers().
тоже учту, не знал...
> 4. Данные для теста лучше генерировать одинаковым алгоритмом генерации случайных цифр. Это позволит другим не искать разные бинарные файлы, да и упростит сам код.
этот тест не предполагал какого-то полного, строгого тестирования двух
языков большим количеством народа, просто надо было быстренько сравнить
два языка (изначально C# и C#2) и писать придумывать для этого свой
алгоритм генерации случайных чисел, думаю, было бы нерационально
> 5. Делая тесты обязательно нужно делать проверку истинности результата. В твоем случае проверять, что массив отсортирован. При этом нельзя использовать общие функции и объекты (вроде компораторов), так как в них могут быть ошибки.
про проверку — согласен, про компараторы — не согласен:
1. Я исхожу из того, что компилятор и все стандартные библиотеки
работают правильно (обратное конечно бывает, но крайне редко, мне еще не
попадалось)
2. Если не доверять стандартным библиотекам, то придется весь FW
переписывать самому (лично я использую C# из-за большого набора
встроенных в FW велосипедных классов)... уверен глюков будет значительно
больше, чем есть сейчас
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, VladD2, Вы писали:
VD>На самом деле теряется чуть больше. Теряется, например, информация о структурных конструкциях вроде for, if и т.п., но оптимизатору эта информация не так уж и нужна.
Она может понадобится только для примитивных шаблонных оптимизаторов. А от них толку мало.
Сейчас JIT шаблонит по черному по тому и
for( int i = 0; i < arr.Length; ++i )
работает быстрее, чем
int len = arr.Length;
for( int i = 0; i < len; ++i )
А еслибы он не шаблонил, а честно просчитывал потоки данных и исполнения то и таких проблем бы небыло.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Это мне напомнило Лема с его секпульками...
На вопрос что такое CF посылать в ветку, где первое упоминание CF это "Факт тот, что мне понадобился флаг CF...", а последукющие посты вида "Выше я привёл пример с CF ... " выглядит по крайней мере странно.
Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash ( первые строчки при гуглении здесь )? Я весь в недоумении, при чем тут CompactFlash и оптимизация.. Поясните, пожалуйста, что вы подразумеваете под буквами CF?
Здравствуйте, Ведмедь, Вы писали:
В>Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash
Я поначалу подумал про Compact Framework.
(ищи по подстроке "CF")
В>Это мне напомнило Лема с его секпульками... В>На вопрос что такое CF посылать в ветку, где первое упоминание CF это "Факт тот, что мне понадобился флаг CF...", а последукющие посты вида "Выше я привёл пример с CF ... " выглядит по крайней мере странно.
В>Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash ( первые строчки при гуглении здесь )? Я весь в недоумении, при чем тут CompactFlash и оптимизация.. Поясните, пожалуйста, что вы подразумеваете под буквами CF?
Ну это типа крутые программеры знают, но молчат (нам до них далеко). Я так думаю, это какой-то бит из регистра флагов процессора.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>На самом деле теряется чуть больше. Теряется, например, информация о структурных конструкциях вроде for, if и т.п., но оптимизатору эта информация не так уж и нужна. WH>Она может понадобится только для примитивных шаблонных оптимизаторов. А от них толку мало. WH>Сейчас JIT шаблонит по черному по тому и WH>
WH>for( int i = 0; i < arr.Length; ++i )
WH>
WH>работает быстрее, чем WH>
WH>int len = arr.Length;
WH>for( int i = 0; i < len; ++i )
WH>
WH>А еслибы он не шаблонил, а честно просчитывал потоки данных и исполнения то и таких проблем бы небыло.
Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
Здравствуйте, Thornik, Вы писали:
T>А! Понятно. Уважаемый, тогда вас надо отсылать не то что вверх, а вообще куда-то туда.. T>Видите, как всё завязано: все кругом флеймят — то у них C# крутой, то Хаскель, а на самом деле без ассемблера — никуда.
Здравствуйте, Thornik, Вы писали:
T>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
Здравствуйте, Thornik, Вы писали:
T>>>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
OE>>ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
T>Да неважно! Факт тот, что на вход JIT подаётся не программа, а уже скомпилированная под "универсальный псевдопроцессор" куча команд.
А в чем принципиальная разница? Сколько себя помню, я всегда считал что компилятор оптимизирует код на каком-то более позднем этапе, когда вся "программа", как ты ее называешь, разбита на множество элементарных действий. Чем она в этот момент отличается от кода, подаваемого на вход Jit я не понимаю.
Здравствуйте, Thornik, Вы писали:
L>>Казалось бы, причем тут C++ ?
T>Неважно, КАКОЙ КОНКРЕТНО транслятор лучше. Здесь речь о том, что есть абстрактный компилятор, который переводит исходный код в МАШИННЫЕ КОМАНДЫ. Есть другой транслятор, который переводит этот же исходник в команды IL (тут уже конкретный мелкомягкий продукт). Кстати, какой-то умник выше продолжает талдычить, что IL — это вовсе не ассемблер. Отсылаю его сюда: http://se.math.spbu.ru/Courses/dotNET/Examples/CSharp_1.html дабы он окончательно убедился в своей некомпетентности. T>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке).
Следуем логике дальше. С++ оперирует ГОТОВЫМИ КОМАНДАМИ => для С++ нельзя написать хороший оптимизатор
T>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
Давай те приводить примеры
Какую дополнительную информацию имет native компилятор? Какая информация есть в исходном коде и которой нет в MSIL? Как эту инфорацию может использовать native компилятор? Почему ее не может вычислить JIT?
T>А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), то мы увидим очевидное преимущество native компилятора — он может использовать архитектурные особенности процессора, вместо того, чтобы поддерживать "обобщённую виртуальную машину".
Ага, а JIT у нас оказывается не умеет использовать архитектурные оссобенности процессора?
я могу так же утверждать что JIT имеет больше информции для оптимизации, так как он может получить инфомрацию о конкретной машине , памяти, установленных прилоежниях и статистики вызова кода. Этой инфорамации не обладает ни один native компилятор. Используется это в данных версиях оптимизатора или нет это другой вопрос
Здравствуйте, Thornik, Вы писали:
T>Wolf, ты вообще в теме или так, попИсать вышел? Какой в ... трехадресный код? Мы говорим об оптимизации.
Ну открой "Красного дракона" и почитай.
T>Ну естественно! Если нечего сказать, остаётся закидать шапками. Вы, наверное, здесь самый главный по оптимизаторам? Тогда непонятно, почему ваш флейм никак не перерастает в качественное обсуждение.
Обсуждения чего? Твоих голословных заявлений которые не имеют ничего общего с реальностью?
T>Наверное, вы всё же больше трепло, м?
Давно не мылся? Ну так баня на RSDN безразмерная. И если ты будешь продолжать в томже стиле то ты там окажешься.
T>А тут доказывать не надо: ТЕОРЕТИЧЕСКИ можно оптимизировать всё что угодно. Практически — дело не идёт дальше десятка паттернов, которые (в реализации мелкомягких) ещё и умудряются испоганить оптимизированный код. T>Я уже привёл пример со SWAP — да, ПОТЕНЦИАЛЬНО и эту команду можно распознавать. Но есть ещё тонны других, менее тривиальных случаев.
Я бы конечно мог объяснить как это может работать но писать трактат который потянет на статью ради человека который только и умеет что кричать не буду.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Thornik, Вы писали:
K>> Представьте, что вы разрабатываете утилиту на с++ в течение года...
T>Ну если "год", то не такая уж это и "утилита"
T>Вы, видимо, несколько переоцениваете "ускоряющие" возможности C#. Скажу больше: ни ООП, ни ФП, ни прочие мозгозавихрения НЕ УСКОРЯЮТ разработки. Парадигма — это всего лишь ВЗГЛЯД на архитектуру программы. Если программа создаётся, она должна делать что-то НОВОЕ. И это новое НАДО ПИСАТЬ — хоть на чём, неважно.
Зато сильно ускоряют разработку и ОТЛАДКУ готовые библиотеки + более лаконичные конструкции + сборка мусора
T>Т.е. у программы всегда есть некий объективный минимум, быстрее которого просто НЕВОЗМОЖНО написать код. А в случае C# и C++ — вообще смех сравнивать, это почти одно и то же.
>> ... то на добавление фичи у вас уйдет месяц или два. А у ваших конкурентов неделя от силы
T>Неверно, см. аргументацию выше. T>По идее, "добавление фичи" зависит только от грамотности изначальной архитектуры.
>> возможная кроссплатформенность
T>Не делайте мне смешно! Мелкомягкие заинтересованы ТОЛЬКО в Винде. Как максимум — использование своих утилит в Линуксе. В идеале — умерщвление Линукса.
Давай те не будем делать из МС самого главное злодея и параноика нашего времени. МС заитересовано в зарабоытвании большого количетво БАБОК. Сейчас у них это лучше всего получается на Windows и Windows приолжениях( оссобенно Office ). Если МС сможет зарабатывает подобные деньги на чем то другом я думаю ее не остановят "идеологические" препятсвия.
Здравствуйте, Thornik, Вы писали:
T>>>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
OE>>ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
T>Да неважно! Факт тот, что на вход JIT подаётся не программа, а уже скомпилированная под "универсальный псевдопроцессор" куча команд.
А что в С++ компиляторе не подобная ситуация? Просто команды записаны в текстовом виде для некой, а не в формате MSIL.
Что то я не могу вспомнить ни одного выражения в С++ специфичного для конкретного процессора.
Здравствуйте, Thornik, Вы писали:
T>>>Да неважно! Факт тот, что на вход JIT подаётся не программа, а уже скомпилированная под "универсальный псевдопроцессор" куча команд.
brn>> Сколько себя помню, я всегда считал что компилятор оптимизирует код на каком-то более позднем этапе
T>Я не спорю, И ТАКИЕ оптимизаторы имеют место быть. Однако, исходник даёт куда больше информации... T>Простой пример: надо обменять два байта в слове, что в исходнике закодировано операцией $. Если выражать это на IL, то получится примерно так:
T> T>Сделать копию операнда T>Копию сдвинуть влево, оригинал — вправо (оба с заполнением нулями) T>OR на операнд и копию T>
T>А на x86 это делается одной командой SWAP.
T>Теперь разница есть?
И что может jit-у помешать использовать команду swap?
___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
Вообще-то компиляция происходит один раз.
Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет.
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ведмедь, Вы писали:
В>На вопрос что такое 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 пишет: > В>И что может 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>>>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
WolfHound пишет: > Здравствуйте, _d_m_, Вы писали: > > ___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а? > ИМХО ты сильно переоцениваешь время которое сожрет болие умная оптимизация.
угу... то-то у меня на работе проект без оптимизации компилируется 15
минут, а с оптимизаций несколько часов....
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
VladD2 пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>этот тест не предполагал какого-то полного, строгого тестирования двух > NC>языков большим количеством народа, просто надо было быстренько сравнить > NC>два языка (изначально C# и C#2) и писать придумывать для этого свой > NC>алгоритм генерации случайных чисел, думаю, было бы нерационально > > На этот счет есть очень протсые решения которые можно найти за 5 минут на нашем же сайте. > Например, Mab не наз приводил вот такое решение: >
...
>
> Проще не придумашь, а для целей тестирования более чем подходит.
ок, буду иметь ввиду... но чтобаы найти этот самый пример я думаю
потратил бы значительно больше времени, чем писал все 3 теста...
> Даверять можно чему угодно, но не в тестах компилятора. Более того в тестах вообще не стоит применять библиотеки, если конечно не идет речь о тестировании самих библиотек. > Тест — это можно сказать микроскопическая научно-исследовательская
работа. И как и любая научная работа она должна строится на базе
научного подхода. Иначе ценность тестов становится сомнительной.
в общем случае — согласен, в данном не очень.... у меня была задача
сравнить да компилятора на чем-то элементарном, причем сравнить быстро
(в течение 5-10 минут)...
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, NovaCxarmulo, Вы писали:
NC>ок, буду иметь ввиду... но чтобаы найти этот самый пример я думаю NC>потратил бы значительно больше времени, чем писал все 3 теста...
Гы. Так на то как раз и есть форумы и поиск!
Можно или найти или спросить.
NC>в общем случае — согласен, в данном не очень.... у меня была задача NC>сравнить да компилятора на чем-то элементарном, причем сравнить быстро NC>(в течение 5-10 минут)...
Дык, задумайся что будет если ты все же ошибся. 10 минут то не жалко. А вот то заблуждение в которое можно ввести тысячи человек может привести к тому, что разного рода фобии потом не выбить много лет.
Между тем написание теста обычно и минуты не занимает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
NC>>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется NC>>JIT'ом для конкретной ф-ции....
L>Можно посмотреть в Debug->Window->Disassembl.
Вот так не стоит. В отладочной версии ты получишь результат далекий от того что будет в релизе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется NC>JIT'ом для конкретной ф-ции....
Единственный способ подключиться отладчиком к уже запущенной программе.
Сделать это можно вставив, например, Trace.Assert(false) в код метода. Но при этом нужно понимать, что маленькая функция может изменить свои характеристики от наличия в ней лишнего кода.
Так что лучше присоденяться не VS, а cordbg (тоже к запущенной программе) и делать точку останова через консоль.
NC>конечно можно прогнать ngen'ом и потом дизассемблировать, но что-то не NC>рабует перспектива разбираться в куче ассемблерного кода без NC>комментариев в виде исходника....
ngen на сегодня к тому же еще и по умолчанию генерирует более медленный код. Его можно заставить делать код почти аналогичный JIT-овскому, но это очень не просто.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Lloyd, Вы писали:
NC>>>хм... а можно как-нибудь посмотреть асмовый код, который сгенерируется NC>>>JIT'ом для конкретной ф-ции....
L>>Можно посмотреть в Debug->Window->Disassembl.
VD>Вот так не стоит. В отладочной версии ты получишь результат далекий от того что будет в релизе.
Почему? Для релиза также можно включить генерацию отладочной информации.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>угу... то-то у меня на работе проект без оптимизации компилируется 15 NC>минут, а с оптимизаций несколько часов....
Lloyd пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>CF — флаг процессора, устанавливается, если арифметическая операция > NC>произвела перенос из старшего бита результата, старшим является 7, 15, > NC>31 биты, в зависимости от размерности операнда. (с) В.И. Юров, "Assembler" > > Нет, ты расскажи что такое CF в C++.
насколько я знаю в C++ такого флага нет
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
VladD2 пишет: > ... Пока что я легко могу доказать, что многие С++-компиляторы (и МС-ный тоже) после оптимизаци изменяют алгоритм и способны привести к неработоспособности корретного С++-кода. А вот обратное найти не просто. Было пара случаев, но их исправли. Да и случаи били уж очень экзотические.
можешь накидать пример в несколько строк?.... действительно никогда не
видел кода, который не работает из-за компилятора.... и... может
перенести это сообщение (и следующую за ним ветку) в форум о C++?
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
WolfHound пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>угу... то-то у меня на работе проект без оптимизации компилируется 15 > NC>минут, а с оптимизаций несколько часов.... > Это каким компилятором? У меня есть подозрение что там что-то не то с ключами ибо в моей практике релиз компилится как правило быстрее чем дебуг ибо генерится меньше временных файлов.(это если мы про С++ говорим) > К томуже скорость компиляции у С++ и C# немного разная...
на работе C++
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
vhonest пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>угу... то-то у меня на работе проект без оптимизации компилируется 15 > NC>минут, а с оптимизаций несколько часов.... > > С++Builder?
MS VS 7.1
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
VladD2 пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>ок, буду иметь ввиду... но чтобаы найти этот самый пример я думаю > NC>потратил бы значительно больше времени, чем писал все 3 теста... > Гы. Так на то как раз и есть форумы и поиск! > Можно или найти или спросить.
да, я видел сравнения, на RSDN тоже ситал статью — там сравниваются
быстрые сортировки разными алгоритмами, на C# и для примера приведен еще
и C++. Но раньше я не встречал ситуации, чтобы шарп оказался быстрее...
сравнений между .NET и .NET2 честно скажу — даже не искал... просто
инетресно было, вот и попробовал.
> NC>в общем случае — согласен, в данном не очень.... у меня была задача > NC>сравнить да компилятора на чем-то элементарном, причем сравнить быстро > NC>(в течение 5-10 минут)... > Дык, задумайся что будет если ты все же ошибся. 10 минут то не жалко. А вот то заблуждение в которое можно ввести тысячи человек может привести к тому, что разного рода фобии потом не выбить много лет.
именно поэтому я и дал сначала эти элементарные алгоритмы проверить 2м
другим программистам.
> Между тем написание теста обычно и минуты не занимает.
я не умею так быстро набивать текст на клаве
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, NovaCxarmulo, Вы писали:
NC>можешь накидать пример в несколько строк?.... действительно никогда не NC>видел кода, который не работает из-за компилятора....
Раньше в MSDN Magazine была колонка "Bugslayer" или что-то вроде того. В ней часто пубилковали разные баги.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>да, я видел сравнения, на RSDN тоже ситал статью — там сравниваются NC>быстрые сортировки разными алгоритмами, на C# и для примера приведен еще NC>и C++. Но раньше я не встречал ситуации, чтобы шарп оказался быстрее... NC>сравнений между .NET и .NET2 честно скажу — даже не искал... просто NC>инетресно было, вот и попробовал.
Гы. Я их и писал. Потому и делюсь своими ошибками.
А быстрее... медленее... Порядок приблизительно одинаков. А там уже как карта ляжет. В общем, на разницу до 20% можно смело забить.
Тут уже от алгоритмов и выбора библиотек/метдов будет куда больше зависить.
А уж от проектного решения... Вот к примеру, С++-компилятор на чем его не пиши компилирует очень долго. А язык по куче возможностей превосходящий его но базирующийся на .net намного быстрее.
NC>именно поэтому я и дал сначала эти элементарные алгоритмы проверить 2м NC>другим программистам.
А куда проще было сделать коротенький тест.
Программисты тоже люди. Хотя это тоже полезно конечно.
>> Между тем написание теста обычно и минуты не занимает. NC>я не умею так быстро набивать текст на клаве
Это дело наживное.
Да и для сортировки можно сделать очень простой тест. Что-то вроде:
static int _controlSum; // рассчитывается на несортированном массивеvoid Test(int[] array)
{
for (int i = 1, controlSum = array[0]; i < array.Lenth; i++)
{
Trace.Assert(array[i - 1] <= array[i]);
controlSum += array[i];
}
Trace.Assert(controlSum == _controlSum);
}
Или вообще сделать копию массива, отсортировать ее библиотечной функцией и поэлементно сравнить.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Thornik, Вы писали:
T>>Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м? Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного, посему не понимаю возмущений. Ближе к теме, меньше понтов, ага?
VD>Хотел забавнить но столь искрометного хамсва, и распухшего до небес самомнения еще не видел. Так что хочется поглядеть на продолжение.
VD>Излогайте дальше сэр! Ваши понты начинают не по детски прикалывать.
Ага, прикольно. Скорее всего, подросток забавляется с ассемблером просто потому, что это "ну очень круто". И соответственно считает себя приверженцем некой высшей касты. Я лабал на асме в 93-ем — вирусы для DOS писал.
Здравствуйте, Thornik, Вы писали:
K>> Представьте, что вы разрабатываете утилиту на с++ в течение года...
T>Ну если "год", то не такая уж это и "утилита"
T>Вы, видимо, несколько переоцениваете "ускоряющие" возможности C#. Скажу больше: ни ООП, ни ФП, ни прочие мозгозавихрения НЕ УСКОРЯЮТ разработки. Парадигма — это всего лишь ВЗГЛЯД на архитектуру программы. Если программа создаётся, она должна делать что-то НОВОЕ. И это новое НАДО ПИСАТЬ — хоть на чём, неважно. T>Т.е. у программы всегда есть некий объективный минимум, быстрее которого просто НЕВОЗМОЖНО написать код. А в случае C# и C++ — вообще смех сравнивать, это почти одно и то же.
Между ними огромная разница. Разница не в языках — а в мощнейшей библиотеке классов C#
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, NovaCxarmulo, Вы писали:
NC>>этот тест не предполагал какого-то полного, строгого тестирования двух NC>>языков большим количеством народа, просто надо было быстренько сравнить NC>>два языка (изначально C# и C#2) и писать придумывать для этого свой NC>>алгоритм генерации случайных чисел, думаю, было бы нерационально
VD>На этот счет есть очень протсые решения которые можно найти за 5 минут на нашем же сайте. VD>Например, Mab не наз приводил вот такое решение: VD>
VD>Проще не придумашь, а для целей тестирования более чем подходит.
Да в принципе, алгоритм псевдослучайной последовательности прост как три копейки. Я не думаю, что стандартные средства чем-то отличаются. Можно использовать и их. Эти же алгоритмы применяются для генерации белого шума и для алгоритмов симметричного шифрования — начальное значение seed — есть ключ.
Здравствуйте, Аноним, Вы писали:
А>находится в регистре FLAGS А>CF — флаг переноса. устанавливается если арифметич. операция вызвала перенос или заем из старшего бита результата
И какой командой на C++ можно проанализировать этот самый "флаг переноса"?
VD>Думаю, что речь идет о фроцессоном флаге переполнения. Видимо товарищь считает, что он является неотемлемой частью С++.
Именно это и я хотел у него услышать и понять, как в С++ с ним можно работать
Просто хочется конкретных примеров, а то слова "native компилятор имеет код поэтому у него преимущества, а еще есть CF" не более чем треп Но человек упертый, только лозунги, никаких доказательств.
Здравствуйте, Ведмедь, Вы писали:
В>Именно это и я хотел у него услышать и понять, как в С++ с ним можно работать В>Просто хочется конкретных примеров, а то слова "native компилятор имеет код поэтому у него преимущества, а еще есть CF" не более чем треп Но человек упертый, только лозунги, никаких доказательств.
Откровенно говоря все его слова не подкреплены аргументами (скажем так). И при этом от него постоянно сылышны наезды высказываемые в оскорбительной форме по поводу того, что ему мол выдают один треп и т.п.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Скорость C# это что-то непонятное
От:
Аноним
Дата:
22.04.06 19:55
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>К тому же фанатам оптимизации нужно знать, что примитивные инструкции вроде movs на практике сегодня выигрыша не дают. Процесоры ведь давно разбивают их на примитивы.
Чушь полнейшая. Нечего они не разбивают.
Re[12]: CF - carry flag
От:
Аноним
Дата:
23.04.06 12:57
Оценка:
Здравствуйте, Andrbig, Вы писали: A>И какой командой на C++ можно проанализировать этот самый "флаг переноса"?
естественно никакой. т.к. это платформенно-зависимый код. (под С++ подразумевается стандарт)
Re[21]: Скорость C# это что-то непонятное
От:
Аноним
Дата:
23.04.06 13:43
Оценка:
Между прочим все вы забываете, что основным преимуществом оптимизатора JIT пред C++ является знание железа под которое надо компилировать, и компеляция происходит с использованием машинно-специфических команд, которые есть только на данном типе процессора например AMD 3D Now, более того JIT выдает такой машинный код который наиболее вероятно угадывается сборщиком команд на конвеер, а эти технологии разлечаются не только между производителями процессоров, но и просто между их марками. C++ в свою очередь не знает этого и генерит нейтральный код, который может работать на любом железе, естественно здесь его оптимизация даже рядом не валялась с JIT'ом.
от возмущения аж флаги перепутал CF используется в командах JB\JC\JNAE, JO, JBE\JNB и впрочим в многих других условных переходах. А jne\jnz использует ZF флаг. еще CF используется для проверки переполнение регистра, после последней операции.
Тоже заинтересовался, взял из проекта небольшой парсер, переписал его на native-C++ с MFC (тиха тиха, сейчас объясню почему). Данные для парсера брал из одного и тогоже фалйла, и вот что получили:
200 экземпляров парсеров в array, а что бы оптимизатор нечаянно не выринул расчеты, я у всех из массива вызывал функцию(она же и проверяла, что тектс на самом деле распарсен).
Созданиме массива и вызов функции — вне теста, в C++ — массив поинтеров, т.е. объекты не копируем, данные из файла так же читаются до теста. Никаких скоростных функций из FW не трогал. Созданные объекты не удалял. С++ — полная оптимизация на скорость. Теперь почему MFC — дело в том что меня интересует не пиковая скорость, которую можно выжать из С++, а реальная скорость, то есть код был написан в том стиле, как обычно пишется на C++ (в типичном проекте, без безумной оптимизации).
А, время замерялось в C++ timeGetTime(), в .NET через DateTime.Now (вот мож это и неправильно)
Не делайте мне смешно! Мелкомягкие заинтересованы ТОЛЬКО в Винде. Как максимум — использование своих утилит в Линуксе. В идеале — умерщвление Линукса.
ИМХО — не-а.
Почему то мне кажется что MS очень даж не против появлений .NET под Linux/Mac OS/разное, попой чую, хотят они этого, и уже не мало бабла вложили в технологию, и даже какие то свои продукты выпускают под Linux вроде, или мак, не помню, и с этоми продуктами идет кастрация от .NET, но что им мешает наваять взрослый фреймворк (когда он вырастит), туда? А потом продавать свои великолепные (Office, VS, прочее) ПО на вселенском рынке... А тем более тут даже запариваться не надо, линуесоиды за MS фреймворк перепишут, бесплатно..
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Скорость C# это что-то непонятное
От:
Аноним
Дата:
23.04.06 15:10
Оценка:
> MS очень даж не против появлений .NET под Linux/Mac OS/разное
Попытка умерщвления Mono говорит об обратном.
Здравствуйте, Thornik, Вы писали:
T>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
Вы правда думаете, что MSIL содержит меньше информации, чем исходные коды? А Reflector в таком случае получает исходный код по MSIL с помощью божественного откровения?
Понятно, что восстановленый код отличается от первоначального, но это из-за синтаксического сахарка. А сахарок он и есть сахарок. В чем принципиальная разница-то?
Вот и получается, что информации у JIT даже больше: полная информация о коде + информация об окружении. Можно оптимизировать под конкретный процессор, делать межсборочный инлайн etc.
По моему, об этом знают уже даже самые маленькие любители спорта.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Andrbig, Вы писали: A>>И какой командой на C++ можно проанализировать этот самый "флаг переноса"?
А>естественно никакой. т.к. это платформенно-зависимый код. (под С++ подразумевается стандарт)
Здравствуйте, <Аноним>, Вы писали:
А>Чушь полнейшая. Нечего они не разбивают.
Нда. Сходи что ли на сайт Интела, доки почитай. Или ты судишь по книжке "Ассемблер 80386 для профессионалов"?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
>То что оптимизатор IL пока не очень умный не значит что он теоритически не в состоянии оптимизировать не хуже чем оптимизатор С++.
Маленькое замечание.
Теоретически — да. А практически — у компилятора С++ на это времени столько, сколько надо. Если релиз компилируется 5 минут, то в этом ничего особенного нет.
А вот у JIT такого времени нет и не будет
Z>for(int i=0;i<...;i++)//не помню количество итераций
Z> for(int j=0;j<..;j++)
Z> {
Z> string s = i+j;
Z> int x = Convert.ToInt32(s);
Z> Console.WriteLine(x);
Z> }
Z>
Z>Сделал аналоги для C++ (под builder 6 без оптимизации) и Java. Z>Результаты (примерно: Z>Java 55c Z>C# 25c Z>C++ 30c
Z>Меня тогда это сильно удивило.
В этом тесте основное время отнимает функция Win32 WriteConsole, которая делает вызов int 2eH в нулевое кольцо и функция форматирования (в каждом языке своя). На фоне таких операций ToInt32 и i++ — семечки, о которых и говорить не стоит.
Z>Важно было другое: что С# сравним по скорости с тем же C++,
Может и так, может, и нет, но на основе такого теста лучше такие выводы не делать.
With best regards
Pavel Dvorkin
Re[21]: Скорость C# это что-то непонятное
От:
Аноним
Дата:
26.04.06 10:22
Оценка:
Cat, не беспокойтесь, спасибо за участие. Мальчика просто очень много били в детстве — вот и приходится вымещать это в возрасте. Никто не любит программистов
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это может быть верным только для static функций. Если функция не static, компилировать ее обязаны, так как вызов может быть из другого файла им им займется уже линкер.
1)Что значит из другого файла?
2)Почему статик функции нельзя вызвать из другого файла?
3)Да и вобще какая JIT'у разница?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BackstreetCat, Вы писали:
BC>Лишать своего оппонента слова, пусть даже ведет он себя не совсем корректно это удар ниже пояса.
Thornik был забанен за мат в другом форуме.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Это может быть верным только для static функций. Если функция не static, компилировать ее обязаны, так как вызов может быть из другого файла им им займется уже линкер. WH>1)Что значит из другого файла? WH>2)Почему статик функции нельзя вызвать из другого файла? WH>3)Да и вобще какая JIT'у разница?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Я имел в виду С++
А с каких это пор C++ выполняет компиляцию непосредственно перед выполнением? См. сообщение, на которое ты отвечал: Re[11]: Скорость C# это что-то непонятное
Здравствуйте, Sinclair, Вы писали:
S>А с каких это пор C++ выполняет компиляцию непосредственно перед выполнением? См. сообщение, на которое ты отвечал:
Отвечал я вот на что
Z>Вообще-то компиляция происходит один раз. Z>Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет
Ну я про С++ и ответил. Надеюсь, не будешь отрицать, что для С++ это верно ?
В общем, чистой воды недоразумение. Или ты впряь решил, что я не отличаю static в С++ и в C# ? Может, я последний и не блестяще знаю, но не настолько уж, чтобы такую чепуху говорить.
Здравствуйте, BackstreetCat, Вы писали:
BC>To VladD2 BC>Лишать своего оппонента слова, пусть даже ведет он себя не совсем корректно это удар ниже пояса.
Любая свобода порождает ответственность. Некорректно он будет себя вести у себя на кухне. Форум — общественное место с вполне известными правилами поведения.
Есть мнение — аргументированно выскажи. Не можешь опровергнуть аргументы оппонента — согласись, что неправ.
Здравствуйте, BackstreetCat, Вы писали:
>> MS очень даж не против появлений .NET под Linux/Mac OS/разное BC>Попытка умерщвления Mono говорит об обратном.
Для тех кто не в курсе — о какой попытке идет речь?
Здравствуйте, Pavel Dvorkin, Вы писали:
Z>>Вообще-то компиляция происходит один раз. Z>>Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет
PD>Ну я про С++ и ответил. Надеюсь, не будешь отрицать, что для С++ это верно ?
А ты утверждаешь что это верно? Вынужден тебя разочаровать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Медленно или быстро он компилируется, виной тут структура или нет — это, может быть и существенно, но я не об этом говорю. А о том, что у не-JIT компиляторов времени сколько угодно, а у JIT — ограничено. Поэтому в обычных компиляторах можно применять сколь угодно сложные алгоритмы, не слишком заботясь о времени, а в JIT- нельзя.
Но если jit-оптимизация будет занимать сколь угодно малое кол-во времени, то пусть занимаются сколь-угодно сложными оптимизациям.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну я про С++ и ответил. Надеюсь, не будешь отрицать, что для С++ это верно ?
Что верно? Что "Причём непосредственно перед вызовом некоторой функции" ???????
Это какой-то новый для меня С++. PD>В общем, чистой воды недоразумение.
А вот на это больше похоже.
Поясняю: тебе человек рассказывает про то, как джит компилирует MSIL. А ты ему в ответ начинаешь рассказывать про то, что это нельзя делать для нестатических функций.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Pavel Dvorkin пишет: > Здравствуйте, Sinclair, Вы писали: > > S>А с каких это пор C++ выполняет компиляцию непосредственно перед выполнением? См. сообщение, на которое ты отвечал: > > Отвечал я вот на что > > Z>Вообще-то компиляция происходит один раз. > Z>Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет > > Ну я про С++ и ответил. Надеюсь, не будешь отрицать, что для С++ это верно ?
Для C++ это, по-моему, не верно — он компилирует ф-ции не
непосредственно перед вызовом, а в момент компиляции приложения. И
компилирует он все функции. Лишний код уже потом линкер может
выкидывать. и Опять же это на стадии сборки приложения.
Т.е. если в C++ у тебя есть что-то вроде:
{
int a;
cin >> a;
if( a == 0)
myfunc();
}
то на C++ у тебя ф-ция myfunc() всегда будет компилироваться.
C# тоже всегда скомпилирует myfunc() и включит её в MSIL-код, а вот
компиляция в машинный код у неё может и не произойти...
При исполнении MSIL-кода ф-ция myfunc() будет откомпилирована только
если кто-то введет a, равное 0.
Вроде как дела обстоят так...
P.S. это моё личное мнение, оно может быть ошибочным...
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, Andrbig, Вы писали:
A>Здравствуйте, Nimnul, Вы писали:
N>>от возмущения аж флаги перепутал CF используется в командах JB\JC\JNAE, JO, JBE\JNB и впрочим в многих других условных переходах. А jne\jnz использует ZF флаг. еще CF используется для проверки переполнение регистра, после последней операции.
A>И все? Учите матчасть, батенька. Команды сдвига RCR и RCL используют этот флаг — именно про этот способ и говорил автор.
A>Другой вопрос, что такие кульбиты вытворяются только в ассемблере и некорректно сравнивать ассемблер с языками высокого уровня.
A>И еще другой вопрос, что суперскалярность может (наверное) привести к тому, что несколько примитивных логических команд будут в итоге выполнены быстрее, чем это извращение через CF.
Зачастую именно так и происходит.
Здравствуйте, BackstreetCat, Вы писали:
BC>To VladD2 BC>Лишать своего оппонента слова, пусть даже ведет он себя не совсем корректно это удар ниже пояса.
Слова он был лишен за мат. Чесно-слово не хотел банить это чудо природы, но мат это бан в атоматическом режиме. Остальные факторы были только отягощающими.
Ну, и оппонентом это чудо назвать язык не поворачивается. Вот в Философии программирования есть действительно оппоненты с которыми подобные вопросы обсуждались не раз. С их стороны были и аргументы, и банально связанные/логичные рассуждения. А тут одни понты и хамство. Вести беседу на таком уровне смысла нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Thornik, Вы писали:
T>Cat, не беспокойтесь, спасибо за участие. Мальчика просто очень много били в детстве — вот и приходится вымещать это в возрасте. Никто не любит программистов
Не говори от лица тех к числу кого ты не пренадлижишь, мальчик.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FonBalroG, Вы писали:
FBG>Да уж. Хотя, на самом деле лучше было бы его оставить в "живых". Потому что это было просто смешно. Только обсуждение тогда надо было перенести в форум "коллеги, улыбнитесь"
Это не поздно сделать и сейчас. Вопрос к модераторам форума.
Бан же в основном за мат. Причем в сообщении с которым во многом я был согласен. Так что ничего личного. Он долго добивался помывки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>А с каких это пор C++ выполняет компиляцию непосредственно перед выполнением? См. сообщение, на которое ты отвечал:
PD>Отвечал я вот на что
Z>>Вообще-то компиляция происходит один раз. Z>>Причём непосредственно перед вызовом некоторой функции. Так что, если какая-то функция не будет использоваться вообще, то компилироваться она тоже не будет
PD>Ну я про С++ и ответил. Надеюсь, не будешь отрицать, что для С++ это верно ?
Вообще-то это не верно и для С++. Причем сразу по нескольким сценариям.
1. Странно вообще говорить о компиляции перед вызовом в нэйтив-С++.
2. Если речь о менедед-комиляторе, то это не верно.
3. Есть нэйтив-С++-компиляторы проводящие глобальные оптимизации во время линковки. При этом без вопросов можноотбрасывать недостижимый код и неспользуемые функции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>То что оптимизатор IL пока не очень умный не значит что он теоритически не в состоянии оптимизировать не хуже чем оптимизатор С++.
PD>Маленькое замечание. PD>Теоретически — да. А практически — у компилятора С++ на это времени столько, сколько надо. Если релиз компилируется 5 минут, то в этом ничего особенного нет. PD>А вот у JIT такого времени нет и не будет
1. Теоритически у статического компилятора "времени столько, сколько надо", а практически многие оптимизации имеют непредсказуемое время и могут никогда не закончиться. Так что практически и С++-компиляторы не делают все допустимые оптимизации, а только самые шустрые.
2. У рантаймов вроде дотната и Явы есть возможность заниматься компиляцией при установке программы. И если программа действительно требует скорости выполнения, то большинство народу пожертвует скоростью установки.
3. Во втором фрэймворке появлися сервсис позволяющий запускать прекомпиляцию сборок во время инсталяции и сразу же отдавать управление инсталлятору. При этом компиляция сборок будет проходить в теневом режиме и может занимать любое время. Это позволяет тратить на оптимизацию гораздо больше времени.
Ну, и стоит упомянуть, о том, что реально есть только два пути существенного понятия производителности за счет компилятора:
1. Использование специфичных для конкретноо типа роцессоров инструкций. Имнно их исползование позволяет Intel C++ частенько надирать зад и JIT-ам, и MS VC.
2. Алгоритмические оптимизации.
Пункт 1 как буд-то специально создан для JIT- и pre-JIT-компяляторов. И их лидерсво в этой области дело времени.
Пункт 2 вообще пока очень большая экзотика в области оптимизации. Пожалуй что первой ласточкой станет JIT Явы который по слухам должен в ближайшее время обзавестись мудрой оптимизацией которая позволит размещать многие объекты в стеке. Хотя это тоже конечно слабо тянет на изменение алгоритма.
Так что важно только то есть ли для неготорого языка полноценный компилятора ли нет. Так как если это так, то много выиграть на выборе компилятора уже будет тяжело. А вот за счет оттачивания алгоритмов напротив можно и много.
Ну, а более качественный алгоритм можно сделать если ты используешь более простые и мощьные языки которые позволяют тратить меньше времени на ненужные вещи (воде ручного контроля памяти и понимании того что начудил с указателями сосед-программист), и обладает более выразительными консрукциями.
В итоге не трудно понять, что будущее за чем угодно но не за нэйтив-С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Похоже, недоразумение затянулось, на этот раз по моей вине.
Я имел в виду функции, описанные с атрибутом static, но отнюдь не члены класса.
static int f ()
{
// ...
}
Если в файле, где эта функция находится, нет к ней обращений, то умный компилятор может ее вообще выкинуть. Потому что из других файлов вызвать ее нельзя из-за static. Вот и все. О static членах классов я в тот момент не думал вообще.
Если же функция описана
int f ()
{
// ...
}
то этого делать нельзя, так как вызовы ее могут быть в других файлах проекта.
Приношу свои извинения всем за то, что неточно выразился и тем самым заставил обсуждать этот вопрос
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FonBalroG, Вы писали:
FBG>>Да уж. Хотя, на самом деле лучше было бы его оставить в "живых". Потому что это было просто смешно. Только обсуждение тогда надо было перенести в форум "коллеги, улыбнитесь"
VD>Это не поздно сделать и сейчас. Вопрос к модераторам форума.
Думаю стоит пока оставить здесь, а то ведь господа вроде Thornik вряд ли согласятся специально нас веселить VD>Бан же в основном за мат. Причем в сообщении с которым во многом я был согласен. Так что ничего личного. Он долго добивался помывки.
Да, вы уже говорили об этом выше.
Все-таки без него как-то спокойнее.
Здравствуйте, FonBalroG, Вы писали:
FBG>Все-таки без него как-то спокойнее.
Хотя и скучно. Ну да бог с ним, народ в ветке про 10 тыс записей плещет эмоциями
2 VladD2 >Ну, а более качественный алгоритм можно сделать если ты используешь более простые и мощьные языки которые позволяют тратить меньше времени на ненужные вещи (воде ручного контроля памяти и понимании того что начудил с указателями сосед-программист), и обладает более выразительными консрукциями. В итоге не трудно понять, что будущее за чем угодно но не за нэйтив-С++.
На данный момент я тоже подписываюсь под этим постом.
Про С++ я к примеру уже лет 5 как забыл
Здравствуйте, Andrbig, Вы писали:
>> MS очень даж не против появлений .NET под Linux/Mac OS/разное BC>Попытка умерщвления Mono говорит об обратном.
Для тех кто не в курсе — о какой попытке идет речь?
Я имел ввиду заявление представителя Microsoft по поводу Mono (попытка Novell портировать .Net на другие платформы, Linux в частности):
"Microsoft does not support the Mono product, nor has it licensed anything to Novell/Ximian. Mono is an attempt by Novell to reverse engineer parts of Microsoft's .NET Framework. It is not an extension of the .NET Framework and it should not be considered as such."
Возможно "умерщвление" это слишком сильно сказано, однако ясно что Microsoft заинтересовано только в связке .Net + Windows.
Смешно читать ответ ))) очень смешно. Афтар по всей видимости вообще без понимания темы. Зациклился на на своем C++. Ты знаешь, я тоже иногда ревностно защищал какой-нить язык, а знал и знаю я их достаточное множество, тот же C/C++, и имею свое личное мнение, программлю с 88 года под разными платформами. И если бы как ты продолжал тупо хаять все, кроме "своего", наверное уже в психушку свезли. )) С таким же успехом я могу сказать, матсдай в морг, линух рулез (ИМХО). Так вот шо я хотел сказать. Аноним, прежде чем шота слепо хаять, изучи тему. А то выглядит глупо твой пост.
Предыдущей пост относиться к Аноним: >>> Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC, жирные (чересчур)высокоуровневые конструкции для всего на свете, низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем. С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
Я бы не спешил с выводами и очевидностью. Я на втором Framework писал тест производительности относительно с++, так вот .net даже меня удивил — алгоритмы были один в один, и при этом .net без каких либо оптимизаций проигрывал с++ в среднем в 20 раз. С оптимизациями ситуация улучшалась где-то до тормознутости дотнета от 1.5 до 3 раз. Алгоритм просто перемножал матрицы из float. Всё это есть на gamedev.ru, включая обсуждение и попытки выжать пефоманс.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Я бы не спешил с выводами и очевидностью. Я на втором Framework писал тест производительности относительно с++, так вот .net даже меня удивил — алгоритмы были один в один, и при этом .net без каких либо оптимизаций проигрывал с++ в среднем в 20 раз. С оптимизациями ситуация улучшалась где-то до тормознутости дотнета от 1.5 до 3 раз. Алгоритм просто перемножал матрицы из float. Всё это есть на gamedev.ru, включая обсуждение и попытки выжать пефоманс.
ыы если руки кривые то можно написать хуже еще в 20 раз
Предыдущей пост относиться к Аноним: >>> Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC, жирные (чересчур)высокоуровневые конструкции для всего на свете, низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем. С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
ржу нимагу хороший пост. Но хочу не согласится про скорость работы C# vs C++, если писали мастера с обоих сторон разница будет не велика. За одним исключением на C# писать на порядок быстрее.
Здравствуйте, Thornik, Вы писали:
L>>Казалось бы, причем тут C++ ?
T>Неважно, КАКОЙ КОНКРЕТНО транслятор лучше. Здесь речь о том, что есть абстрактный компилятор, который переводит исходный код в МАШИННЫЕ КОМАНДЫ. Есть другой транслятор, который переводит этот же исходник в команды IL (тут уже конкретный мелкомягкий продукт). Кстати, какой-то умник выше продолжает талдычить, что IL — это вовсе не ассемблер. Отсылаю его сюда: http://se.math.spbu.ru/Courses/dotNET/Examples/CSharp_1.html дабы он окончательно убедился в своей некомпетентности. T>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
Если иметь редставление о том, как вообще устроены компиляторы, то можно разделить их на несклько частей:
FrontEnd -> Optimizer -> BackEnd.
FrontEnd отдает оптимизатору представление программы в неком IntermediateLanguage. Практически полный аналог исходнику, но удобный для дальнейшей работы.
Далее оптимизатор выполняет свое грязное дело и передает это все в BackEnd (сиречь CodeGenerator).
Так теперь применительно я разным языкам.
То, что называется C++ компилятор содержит в себе все три компонента.
То, что называется C# компилятор содержит в основном FrontEnd. Optimizer + BackEnd — это jit компилятор.
Говорить о том, что С++ компилятор работает с исходниками, а jit с "почти ассемблерными" инструкциями не верно, т.к. они работают с данными, практически одинакового уровня абстракции.
Здравствуйте, Thornik, Вы писали:
MS>>JIT имеет больше возможностей для оптимизации, чем C++ компилятор.
T>С какой стати?
С такой, что у JIT больше возможностей для оптимизации — он знает конкретно под какой именно процессор генерить код, знает практически все — от процессора до объема ОЗУ, версии ОС, и т.п.
А C++ компилятор вынужден генерировать код который должен работать по крайней мере на процессорах одного типа, писать прогу под процессор P4 630, которая не будет работать даже на P4 530 я думаю смысла нету...
T>C# делает псевдокод, потом JIT его перемалывает в машинный. А Ц++ сразу имеет право генерить x86.
это минус C++
T>Т.е. там, где у JIT идёт абстрактный поток команд, у Ц++ полная инфа об алгоритме.
Там где у C++ идет "абстрактный поток" машинного кода, у C# более детальная инфа об алгоритме, включая даже имена методов и классов
Таким образом:
— по бинарнику C++ проигрывает, т.к. IL дает больше инфы чем asm x86;
— по исполнению C++ проигрывает, т.к. JIT делает генерацию x86 кода с максимальной оптимизацией под конкретный процессор, а бинарник C++ как был 10 лет назад скомпилен так и будет работать c оптимизациями десятилетней давности...
Здравствуйте, Nimnul, Вы писали:
N>King of a Stellar War:
N>Я бы не спешил с выводами и очевидностью. Я на втором Framework писал тест производительности относительно с++, так вот .net даже меня удивил — алгоритмы были один в один, и при этом .net без каких либо оптимизаций проигрывал с++ в среднем в 20 раз. С оптимизациями ситуация улучшалась где-то до тормознутости дотнета от 1.5 до 3 раз. Алгоритм просто перемножал матрицы из float. Всё это есть на gamedev.ru, включая обсуждение и попытки выжать пефоманс. N>ыы если руки кривые то можно написать хуже еще в 20 раз
N>данное сообщение получено с www.gotdotnet.ru N>ссылка на оригинальное сообщение
Ты совсем идиот? Оптику настрой. Я же написал что алгоритм простейший. Вот он. Как его еще можно кривее написать?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Max.Subpixel, Вы писали:
MS>>JIT не компилятор или плохой и IL не код, а машинные команды. Ну вообще вернулись к тому с чего начали...
VD>+1
VD>Курица не пртица. JIT не компилятор. Баба не человек...
Здравствуйте, NovaCxarmulo, Вы писали:
NC>... NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек. NC>...
Прошу прощения, что восстанавливаю давно забытую тему, но мне кинули ссылку на нее в качестве доказательства превосходства C# над С++(с аргументами), поэтому я всю ее прочитал, и мне хотелось бы немного прокомментировать. Предупреждаю, что я не являюсь спецом по C#. Итак:
1. Не хочу обижать топикстартера, но то, что он использовал в качестве теста, с большим трудом можно назвать пузырьковым алгоритмом сортировки. Воинствующие дотнетчики и такие же нэйтивцы не заметили, что топикстартер приблизительно в два раза ухудшил сам алгоритм. Для справки, при сортировке пузырьком по возрастанию, за один проход максимальное число загоняется в самый конец. Таким образом, на следующем шаге нужно делать не N, а N-1 операций. На следующем — уже N-2 и т.д. Вот здесь, товарищи, нужно искать оптимизацию! А то увлеклись высокими сущностями...(Про то, что можно считать количество свапов при пузырьковой сортировке и при их отсутствии прекращать сортировку, я уже молчу. Оно даёт выигрыш только на больших случайных последовательностях, но я на них предпочитаю использовать другие алгоритмы сортировки ). На 12-ти страницах обсуждения один человек только запостил изменённый алгоритм(тов. Olegator на стр. 4), но и он написал не пузырьковую сортировку, остальные же просто не обратили внимания.
2. Про преимущества JIT, который при компиляции знает конфигурацию компьютера конечного пользователя. Вот интересно, что мне скажут про Linux подход к установке софта(компиляция из исходников)? Так что никакое это не преимущество
3. Как можно сравнивать два практически одинаковых куска кода? Да у них же машинный код будет практически одинаковый! Если уж сравнивать, то нужно сравнивать готовые экзешники, запускать их в цикле и засекать время по выходу из экзешников. После этого отсекать выскочившие из общей картины результаты. Когда мы будем ждать, пока C# и С++ код запустится, пока он считает данные. При этом реализовать все это в сходном объектном стиле и с учетом п.4. Вот это — как раз и есть сравнение двух компиляторов. А так — кусок на асме будет работать практически также, как кусок на С++(с учетом п.4) Но, надеюсь, никто не будет спорить, что асм — медленней?
4. Видел пост, в котором говорится про то, что "писал на MFC, потому что хотел посчитать, как реально работает С++, а не со всякими там маньячными оптимизациями". Так вот, "маньячные" оптимизации — это фича С++. И не юзать ее — это то же самое, что добавлять в код Sleep(1); после каждой итерации. Оптимизация должна быть на полную включена, иногда от этого сильно зависит проивзодительность.
5. Услышал забавное утверждение, что разница по скорости в 20% — несущественна. Ну, если разница между 20ю и 24мя фпсами — несущественна, то всегда можно посмотреть на теорию массового обслуживания, в которой, например, реальная такая ситуация:
Есть 5 обслуживающих аппаратов. Их достаточно для того, чтобы пропускать поток покупателей без задержек. Внезапно ломается один из аппаратов(пресловутые 20%). Мгновенно выстраиваются очереди и люди начинают уходить(по таймауту )
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, tilarids, Вы писали:
WH>Это не имеет значения. Главное что алгоритм одинаковый.
Главное в моей мысли — это то, что не нужно искать в языках виноватых или супер крутых. Виноват чаще всего программист, и программы пишет программист. Вот на это нужно обращать внимание. А охаять можно любой компилятор. Например, я уверен, что то, что С++ все же работал медленно в этом тесте — это тоже проблема программиста, а не компилятора. WH>Этим занимает меньшинство даже среди линуксойдов. WH>В основном народ просто накатывает пакеты и все. WH>Ибо собрать что-то большое из исхоников на С++ это часы, а то и десятки часов.
Эмм. Некоторые готовые бинарники ставят, а некоторые и собирают. И когда желают скорости — собирают вручную. Преимущество дотнета — в том, что выбора не остается?
А по поводу времени — кажется, тебя могли жестоко обмануть. Софт собирается не так и долго. Например, на современной машине ядро линуха собирается за 5 минут. А на мощной — меньше минуты. Так то ядро
К тому же, идёт полная перекомпиляция. То есть, можно учесть не просто тип процессора, а версии библиотек, версии софта установленного, можно учесть всё T>>3. Как можно сравнивать два практически одинаковых куска кода? WH>Именно так и нужно сравнивать. T>>Да у них же машинный код будет практически одинаковый! WH>Именно это и хотят выяснить.
Здесь, кажется, вы тоже заблуждаетесь. Я уже не помню 5 основных требований к программе, без которых невозможно никакое дальнейшее рассмотрение, но там точно присутствует такое понятие, как результативность. Так вот — сравнение должно идти по результативности, а не по кускам кода. Если уж сравнивать два языка, то нужно написать две программы, выполняющие одинаковые действия, причем желательно в стиле стандратно присущем каждому из языков. WH>А вот это делать нельзя. Ибо у систем с JIT'ом есть некоторое время на раскачку. И учитывать это время не корректно.
"Наш биатлонист плохо управляется с лыжами, поэтому давайте будем только стрелять" Как видеть недостатки в С++(например, в отладке) — так это мы сразу, а как у себя чего-то увидеть — не корректно. WH> Большая часть кода пишется без маньячных оптимизаций. Факт медицинский.
Правильное выражение. 90% кода пишутся криворукими программистами. Но, простите, разве зеркалка за $4500 виновата, что фотограф забыл вдохновение дома?
WH>Как правило дешевле поставить еще одну железку. Это я тебе как краевед массового обслуживания говорю.
Так это на 20% больше железок нужно А если общая стоимость железок — $90000, то 20% — это сумасшедшие деньги Неужели нельзя найти программеров на $18 тыс., которые эти 20% уберут? Вообще, смысл моей ремарки был в том, что 20% — это очень даже важно, а не то, что я здесь прочитал WH>ЗЫ Кстати практика показывает что в системах массового обслуживания JIT'ы чувствуют себя очень не плохо. У нас есть схожие системы на С++ и Жабе(миллионы запросов в сутки). С системой на жабе проблем меньше...
Ну, сейчас начнётся Это спор из оперы "Что лучше для сервака — Linux иди Windows?"(Правильный ответ — хороший админ). Такие споры(и этот тоже) рождаются по причине, которую я указывал здесь
А если от же тест сделать, но вместо native C++ — managed C++/CLI использовать?
Вот что интересно. Всем уж я думаю ясно, что в конечном счете с++ только для кросс-платформенной разработки на Win-платформе останется.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, NC>проекты компилировались в Visual Studio 2005 Express Edition, в C++ все NC>оптимизации выставлены на скорость.
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
NC>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>оказался быстрее...
NC>Именно так — C# справился быстрее.... сортировал один и тот же массив NC>(читал из файла), запускал тесты несколько раз, алгоритм сортировки один NC>и тот же (отличаются только синтаксические детали языков).
NC>2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0; NC>i < arr.Length; ++i) выполняется быстрее, чем если длину массива NC>записать в отдельную переменную... (после вынесения arr.Length в NC>отдельную переменную время сортировки увеличилось с 86 до 116 сек).
1.1.4 stable rev. 510
Если нам не помогут, то мы тоже никого не пощадим.
Команды сдвига RCR и RCL используют этот флаг — именно про этот способ и говорил автор.
Но человек упертый, только лозунги, никаких доказательств.
