Здравствуйте, 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 книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
Здравствуйте, MisterIsk, Вы писали:
MI>Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC
В том же .net2 GC уже более умный, по сравнению с первым. MI> жирные (чересчур)высокоуровневые конструкции для всего на свете
Если вы имеете в виду синтаксис — то он практически полностью совпадает с С++. MI> низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем.
Проблема не языка, а фирм, которые нанимают неквалифицированных программистов. MI> С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
Сейчас компьютер стоит дешевле, чем программист. Поэтому экономить выгоднее не на мощных компьютерах, а на первоклассных программистах. На C# писать легче — поэтому можно брать программиста с более низкой квалификацией (но адекватной, а не "мастера", о котором Вы писали выше). MI>У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
С++ предоставляет доплонительные возможности для совершения ошибок, от которых не застрахованы даже профессионалы. Тот же переход в свитче по умолчанию к следующей ветке не выглядит сложным и редко опытный программист в этом ошибается, но никто не застрахован от таких глупых ошибок на 100%, и с повышением квалификации программиста увеличивается уже не блестящее синтаксиса языка (оно уже предполагается), а знание библиотек, хороших решений для разных задач, умение проектировать и т.д.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Andrbig, Вы писали: A>>И какой командой на C++ можно проанализировать этот самый "флаг переноса"?
А>естественно никакой. т.к. это платформенно-зависимый код. (под С++ подразумевается стандарт)
а вот в C# проанализировать можно...
сравни:
byte a;
a = 255;
checked { a++; }
и
byte a;
a = 255;
unchecked { a++; }
разница в выполнении есть?
Тот кто говорит не знает, тот кто знает не говорит.
Я бы не спешил с выводами и очевидностью. Я на втором Framework писал тест производительности относительно с++, так вот .net даже меня удивил — алгоритмы были один в один, и при этом .net без каких либо оптимизаций проигрывал с++ в среднем в 20 раз. С оптимизациями ситуация улучшалась где-то до тормознутости дотнета от 1.5 до 3 раз. Алгоритм просто перемножал матрицы из float. Всё это есть на gamedev.ru, включая обсуждение и попытки выжать пефоманс.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, 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 оптимизациями десятилетней давности...
Я бы не спешил с выводами и очевидностью. Я на втором Framework писал тест производительности относительно с++, так вот .net даже меня удивил — алгоритмы были один в один, и при этом .net без каких либо оптимизаций проигрывал с++ в среднем в 20 раз. С оптимизациями ситуация улучшалась где-то до тормознутости дотнета от 1.5 до 3 раз. Алгоритм просто перемножал матрицы из float. Всё это есть на gamedev.ru, включая обсуждение и попытки выжать пефоманс.
ыы если руки кривые то можно написать хуже еще в 20 раз
Предыдущей пост относиться к Аноним: >>> Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC, жирные (чересчур)высокоуровневые конструкции для всего на свете, низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем. С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
ржу нимагу хороший пост. Но хочу не согласится про скорость работы C# vs C++, если писали мастера с обоих сторон разница будет не велика. За одним исключением на 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 не компилятор. Баба не человек...
