Здравствуйте, Thornik, Вы писали:
T>А! Понятно. Уважаемый, тогда вас надо отсылать не то что вверх, а вообще куда-то туда.. T>Видите, как всё завязано: все кругом флеймят — то у них C# крутой, то Хаскель, а на самом деле без ассемблера — никуда.
Неважно, КАКОЙ КОНКРЕТНО транслятор лучше. Здесь речь о том, что есть абстрактный компилятор, который переводит исходный код в МАШИННЫЕ КОМАНДЫ. Есть другой транслятор, который переводит этот же исходник в команды IL (тут уже конкретный мелкомягкий продукт). Кстати, какой-то умник выше продолжает талдычить, что IL — это вовсе не ассемблер. Отсылаю его сюда: http://se.math.spbu.ru/Courses/dotNET/Examples/CSharp_1.html дабы он окончательно убедился в своей некомпетентности.
Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), то мы увидим очевидное преимущество native компилятора — он может использовать архитектурные особенности процессора, вместо того, чтобы поддерживать "обобщённую виртуальную машину".
Здравствуйте, _d_m_, Вы писали:
___>Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?
ИМХО ты сильно переоцениваешь время которое сожрет болие умная оптимизация.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
P>А чего плохого в том, чтобы подождать 15 сек пока программа загрузится? Photoshop сколько грузится? И ничего, все ждут
Это не было бы так плохо, если бы не было с чем сравнивать. Старт Volkov Commander, который загружается сам, СЧИТЫВАЕТ КОНФИГУРАЦИЮ КОМПА, список каталогов, да ещё отрисовывает это на экране, занимает такие доли секунды, что просто не успеваешь сосчитать! Спрашивается, за каким Х нам программы, которые тратят ДЕСЯТКИ СЕКУНД на всякую лабуду, по вине раздолбаев-архитекторов?
Здравствуйте, Thornik, Вы писали:
T>Спрашивается, за каким Х нам программы, которые тратят ДЕСЯТКИ СЕКУНД на всякую лабуду, по вине раздолбаев-архитекторов?
А за тем, что за все нужно платить. Представьте, что вы разрабатываете утилиту на с++ в течение года. Она замечательно работает, практически мгновенно грузится. Вы выходите с ней на рынок и обнаруживаете, что уже есть утилита на C#, которая делает все тоже самое, но ГРУЗИТСЯ 10 секунд. И что самое страшное, на ее разработку ушел 1 месяц. И она уже успешно продается в течение 11 месяцев. Вашу утилиту никто не купит, потому что, если вы ее год ваяли, то на добавление фичи у вас уйдет месяц или два. А у ваших конкурентов неделя от силы. + возможная кроссплатформенность. Неговоря уже о стоимости разработки.
Здравствуйте, Thornik, Вы писали:
T>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
K> Представьте, что вы разрабатываете утилиту на с++ в течение года...
Ну если "год", то не такая уж это и "утилита"
Вы, видимо, несколько переоцениваете "ускоряющие" возможности C#. Скажу больше: ни ООП, ни ФП, ни прочие мозгозавихрения НЕ УСКОРЯЮТ разработки. Парадигма — это всего лишь ВЗГЛЯД на архитектуру программы. Если программа создаётся, она должна делать что-то НОВОЕ. И это новое НАДО ПИСАТЬ — хоть на чём, неважно.
Т.е. у программы всегда есть некий объективный минимум, быстрее которого просто НЕВОЗМОЖНО написать код. А в случае C# и C++ — вообще смех сравнивать, это почти одно и то же.
> ... то на добавление фичи у вас уйдет месяц или два. А у ваших конкурентов неделя от силы
Неверно, см. аргументацию выше.
По идее, "добавление фичи" зависит только от грамотности изначальной архитектуры.
> возможная кроссплатформенность
Не делайте мне смешно! Мелкомягкие заинтересованы ТОЛЬКО в Винде. Как максимум — использование своих утилит в Линуксе. В идеале — умерщвление Линукса.
T>>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
OE>ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
Да неважно! Факт тот, что на вход JIT подаётся не программа, а уже скомпилированная под "универсальный псевдопроцессор" куча команд.
Здравствуйте, Thornik, Вы писали:
T>>>Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.
OE>>ты не забыл, что IL перед выполнением тоже компилируется в машинные коды, причем под конкретный процессор данной конкретной машины, а не под обобщенный Pentium?
T>Да неважно! Факт тот, что на вход JIT подаётся не программа, а уже скомпилированная под "универсальный псевдопроцессор" куча команд.
А в чем принципиальная разница? Сколько себя помню, я всегда считал что компилятор оптимизирует код на каком-то более позднем этапе, когда вся "программа", как ты ее называешь, разбита на множество элементарных действий. Чем она в этот момент отличается от кода, подаваемого на вход Jit я не понимаю.
Здравствуйте, 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.
T>>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД. WH> Ну и упертый же ты. Гугли "трехадресный код" и читай до просветления. IL за однин проход преобразуется в трехадресный код.
Wolf, ты вообще в теме или так, попИсать вышел? Какой в ... трехадресный код? Мы говорим об оптимизации.
T>>А как только ещё один товарищ разберётся, что же такое CF (мля, я бы постыдился такое не знать), WH>При этом тебе не стыдно говорить об оптимизаторах не зная как они работают даже в общих чертах.
Ну естественно! Если нечего сказать, остаётся закидать шапками. Вы, наверное, здесь самый главный по оптимизаторам? Тогда непонятно, почему ваш флейм никак не перерастает в качественное обсуждение. Наверное, вы всё же больше трепло, м?
T>>то мы увидим очевидное преимущество native компилятора — он может использовать архитектурные особенности процессора, вместо того, чтобы поддерживать "обобщённую виртуальную машину". WH>Осталось только доказать что JIT не может это делать.
А тут доказывать не надо: ТЕОРЕТИЧЕСКИ можно оптимизировать всё что угодно. Практически — дело не идёт дальше десятка паттернов, которые (в реализации мелкомягких) ещё и умудряются испоганить оптимизированный код. Я уже привёл пример со SWAP — да, ПОТЕНЦИАЛЬНО и эту команду можно распознавать. Но есть ещё тонны других, менее тривиальных случаев.
Здравствуйте, 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?
