ответ на вопрос: Почему новые программы работают меделнно - Компьютерные священные войны

Здравствуйте, Andrey.V.Lobanov, Вы писали:

AVL>Здравствуйте, Pavel Dvorkin, Вы писали:

AVL>>>ой, ну опять ))) а вот сидит во второй фазе whole program optimization, тут и именно компиляция, и вообще объём собственно исходников уже бесконечно мал по сравнению с тем, что будет ворочаться.
PD>>Хм. Насколько я помню, вторая фаза (C2.DLL) доступа к исходникам не имеет. Вызывается она из линкера, так что не об этом вообще речь. Я говорил о потребности в памяти cl.exe.
AVL>это всё теоретические сведения, порядком устаревшие. да и обсуждали всё это как-то вроде.

Что именно устарело ? Можно откомпилировать первой фазой (cl.exe), получить *.obj, потом удалить исходники и вызвать link.exe (а он вызовет c2.dll) ? Вроде как можно.

>компилятор, при вызове из линкера, как начнёт работать со сваленными в кучу всеми obj, да ещё пройдёт агрессивный инлайн — это адский ад будет.

Да так он и работает (только из линкера вызывается все же не компилятор, а лишь его вторая фаза, не имеющая доступа к исходникам), и вроде как получается ?

PD>>>А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику.

M>>

НС>>>Не сочти за наезд — ты сколько компиляторов написал и каких?

M>>Естественно, я их не писал,

PD>Вполне в твоем стиле — вырывать фразы из контекста и перевирать. Вот полный текст, из которого ясно, о чем именно я говорил

Вполне в твоем стиле рассказывать сказки. Если ты не занимался построением компиляторов, ты не можешь с уверенность говорить про то, что происходит в процессе парсинга. Про что тебе тут рядом уже рассказали.

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

PD>>>Мегабайты хидеров сейчас при каждой компиляции не всасывают, есть predcompiled headers.
F>> Если прочитать чуть-чуть внимательнее, то я говорил о clean build — т.е. precompiled headers в 99% идут лесом.

PD>Не совсем все же ясно, почему нужно измерять время именно для clean build. Для него, м.б., да, но почему их не вернуть из леса и не использовать ? Это же часть схемы компиляции нынешнего компилятора, зачем же без них ?

Ну да, ну да, а precompiled header'ы нам магическим образом нарисуют одномегабайтные пони.

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

F>> Если прочитать чуть-чуть внимательнее, то я говорил о clean build — т.е. precompiled headers в 99% идут лесом.
PD>Не совсем все же ясно, почему нужно измерять время именно для clean build. Для него, м.б., да, но почему их не вернуть из леса и не использовать ? Это же часть схемы компиляции нынешнего компилятора, зачем же без них ?
Потому что кодобаза обновляется довольно часто, и в разных подсистемах — от тех кто ближе к top-level — почти ничего не зависит, а некоторые которые ближе к base — вызывают волну перекомпиляций. А если ориентироваться на ревизии которые прошли тесты — то это время будет на практике равно clean build. Только, в clean build мы гарантированно не имеем багов, потому как иногда таки что-нибудь "путается", увы.
В разработке — разумеется постоянно клин билд юзать не нужно, напротив обычный билд очень ускоряет "компиляцию", потому как реально перекомпилируются только зависимости и изменённый .obj.
Только жаловался я на линковку. И никаких там WPO нет (в смысле с WPO или без него — это происходит всё равно крайне долго).

А построение прекомпилед хидеров — тоже как бы свою цену имеет. Кроме того, нормальный код включает только нужные ему зависимости, — учитывая то, что код много где кросс-платформенный, а p/impl широко используется — монстры вроде windows.h повсеместно не так часто и нужны. Гораздо бОльший эффект приносит, то, что вызов компилятора отлично распараллеливается, даже в рамках одного проекта.
Типичный размер собранных символов в дебаге (.pdb) — ~800Mb, в релизе — раз в 10 меньше, но mspdbsrv разрывается, в обоих случаях. — тоже часть схемы компиляции нынешнего компилятора.

А на линуксе 32-х битный ld в дебаге — тупо крэшится. Спасаются gold linker-ом (который тоже не без своих тараканов) ну и x64.

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

Т>>Там работает стадия WPO, аналог суперкомпиляции. Вырубите WPO и всё станет летать и жрать в разы меньше.
F> Ой ли.

Я практически в этом уверен.

... << RSDN@Home>>

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

MM>Да какой там еще юникод. Он поведение продумывает, не мешай ему. Нам лохам не понять. Нас бесконечная память развратила.

Точно, думать не нужно, главное клепать. Это случайно не твою программу для UPS на 800М недавно обсуждали?

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

Ops>Точно, думать не нужно, главное клепать. Это случайно не твою программу для UPS на 800М недавно обсуждали?
Прикольно, что ты не отвечаешь за свои слова, да еще и размениваешься на такие беспонтовые уколы, пытаясь навесить на меня чужие ошибки. Позиционируешь себя знатоком, а в итоге демонстрируешь неумение прочитать текст и углубиться в суть решений, принятых в менеджед языках. Только детсадовские каменты про клепание и неумение думать, выдающие лишь отсутствие каких либо весомых аргументов.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>При жестком лимите памяти это напрямую связанные параметры. Именно из-за того, что ТурбоПаскаль был специально сдизайнен однопроходным и удалось добиться такой фантастической скорости компиляции.

Си тоже был задезайнен однопроходным, но долго компиллировался. Дело не только в однопроходности, но и в представлении библиотек/компонент. В паскале этот момент самый эффективный и его никто пока не переплюнул, ни библиотеки типов OLE, ни метаинформация .Net.

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

E__>Компилятор джавы, к слову, однопроходный(в отличие от той же скалы)

Он не может быть однопроходным в принципе. Однопроходный компилятор не скомпилирует код вида:

void a()
{
  b();
}

void b()
{
  a();
}

E__>Но сравнивать жабовский байткод и нативу — странно.

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

E__>, и даже если они недоступны при компиляции, рантайм легко может отработать без проблем

Да при чем тут рантайм? Статически типизированный компилятор не может работать без сигнатуры в принципе, неважно что там будет в рантайме. Скомпилировать неизвестно какой вызов метода он не способен. А вот С# 4 способен, если это динамик, но это уже совсем другой разговор.

Здравствуйте, мыщъх, Вы писали:

М>минуточку. а в си++ имена какие? цифровые что ли? в obj -- текстовые. так что ругаться будет линкер и только в случае статической линковки и статической типизации. динамическая линковка или динамическая типизация -- в exe наблюдаем имена открытым текстом.

Но при всем при том прототипы функций все равно нужно описать в хидере.

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

PD>Мне это известно. А все же, можно объяснить, как тут возникает N^4.

В гугле не нашел, а мне расписывать с таким отношением лень. Одно дело если бы тебя действительно вопрос интересовал, а другое когда ты явно хочешь очередную пургу про криворуких программистов прогнать.

НС>>Это по существу и есть. В матрице ровно один тип узла, и организованы эти узлы в простейшую прямоугольную структуру. При этом никаких связей между узлами нет, там простые числа внутри. В случае компилятора имеем сотни типов узлов, объединенных в сложнейший сетевой граф, причем на первом этапе ссылки между ними символьные, неразресолвленные. Это именно что другой порядок сложности.

PD>Еще раз — давай числовые оценки.

Оплатишь работу? Потому что это не так то просто, тем более что непонятно, какие числовые оценки ты просишь.

НС>>Это который до 7.0 включительно? Чуть сложнее, но не принципиально.

PD>Он и в Delphi XE2 практически тот же.

Насколько я знаю — далеко не тот же, он по возможностям почти С# 3 догнал. Но спорить не буду, я в новомодных дельфях как свинья в апельсинах.

НС>>Нет. Но у него и характеристики компилятора не сильно отличались. К чему вопрос?

PD>К тому же. Потребности в памяти почему резко возросли.

С чего ты взял? Цифры есть?

PD> Для С++ почему ? Он вообще не менялся 10 лет

Язык потому что сложнее.

НС>>??? Добавили object, которого не было. class это уже Дельфи. Тут я уже хуже помню, но, вроде бы, в классическом Дельфи ничего принципиально в компиляторе не менялось.
PD>Object был в TP 6.0.

5.5.

НС>>Для компиляции — да. Что, собственно, и по скорости компиляции хорошо видно. А новый С++ вообще мама не горюй для тех, кто компиляторы делает. Погугли — информации на тему сложности разработки компиляторов С++ хватает.

PD>Новый опустим, ему чуть больше года.

Про старый тоже информации полно.

PD> А C++ времени VS 2008 почему намного больше памяти требует, чем из VS6 ?

А он требует? Я не про VS, я про cl.exe.

НС>>А ты сравни объемы спецификаций. C# читается проще, это да, но это не потому что сложность меньше, а потому что интуитивности больше внимания уделяли.

PD>Сложность на порядок(порядки) больше ?

Вопрос непонятен.

PD>>>А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику.
НС>>Ты ее совсем не знаешь.
PD>Ну разумеется. Проще всего сказать, что твой оппонент ничего не понимает...

Не проще. Но ты наглядно продемонстрировал свое непонимание. Одно сравнение обсчета матриц с компилятором и уверенность, что исходники пофайлово независимо компилируются уже о многом говорит.

HC>>К примеру, одна из самых первых обязательных стадий после парсинга — ресолвинг символов. В C# внутренняя ссылка может быть на любую public или internal декларацию в любом исходнике внутри одного проекта. Это буквально означает, что прежде чем ты приступишь к ресолвингу, тебе нужно отпарсить и частично отресолвить все декларации во всех исходниках проекта. Можно, конечно, АСТ отпарсенных исходников тут же выкидывать, а потом для каждого исходника парсить по новой с диска, но тогда мы конца компиляции не дождемся.

PD>Численные данные, пожалуйста. Что и сколько места занимает. А иначе это все слова.

Вопрос неконкретен. Какие конкретно численные данные ты хочешь получить?

PD>Спасибо, что просветил, я этого не знал

Очень хорошо, что ты знаешь. Теперь попробуй подумать, для чего в С понадобились хидеры. Вопрос непростой, но догадаться можно.

PD>В общем, пока что один аргумент я услышал — forward декларации.

Это не аргумент, это пример. Простейший. Для более сложных надо хоть немножко понимать в компиляторостроении либо читать что тебе пишут с целью понять, а не переспорить, чего у тебя не надблюдается.

PD> Вот и давай количественные оценки

Это требует конкретики (какая конструкция, какой исходник) и весьма дорогое удовольствие (т.е. бесплатно я тебе такие оценки делать не буду, это приличная работа). Есть интерес — я могу тебе описать информацию качественно. А за количественными — лезь в гугль или попробуй сам написать хотя бы простенький компилятор. Если же не интересно — нафига оно мне?

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

V>Си тоже был задезайнен однопроходным

Я про это и писал — при помощи хидеров. Та же forward декларация, по сути.

V>, но долго компиллировался

С — не особо долго. Медленнее ТурбоПаскаля, но однопроходность — не единственное, почем ТурбоПаскаль такой быстрый. Еще один из факторов — бинарные модули вместо текстовых хидеров, отсутствие препроцессора.

V>В паскале этот момент самый эффективный и его никто пока не переплюнул, ни библиотеки типов OLE, ни метаинформация .Net.

В каком смысле не переплюнул? Компилятор шарпа вполне сопоставим по перформансу с Дельфи последних версий, которые с лямбдами и выводом типов. А сравнивать с древним ТурбоПаскалем не интересно — сложность языков несопоставима.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, мыщъх, Вы писали:

М>>минуточку. а в си++ имена какие? цифровые что ли? в obj -- текстовые. так что ругаться будет линкер и только в случае статической линковки и статической типизации. динамическая линковка или динамическая типизация -- в exe наблюдаем имена открытым текстом.

НС>Но при всем при том прототипы функций все равно нужно описать в хидере.
Run-Time Type Information -- тип в райнтайме. на стадии компиляции о типе ничего не известно. как описать прототип в хидере, если тип динамический?

да и динамическая линковска с тем же dll -- никогда не знаешь какие там функции есть. допустим, в новой оси появилась новая фича. в старой dll такой функции нет. линкуем динамически

Здравствуйте, Ночной Смотрящий, Вы писали:

E__>>Компилятор джавы, к слову, однопроходный(в отличие от той же скалы)

НС>Он не может быть однопроходным в принципе. Однопроходный компилятор не скомпилирует код вида:
НС>

НС>void a()
НС>{
НС>  b();
НС>}

НС>void b()
НС>{
НС>  a();
НС>}
НС>

Легко. Но я не про джит. Я про компилятор джавы, который боле похож на банальный реплейсер(об Эклипсовском вообще молчу, это отдельный разговор). То есть, есть инструкция вызова метода а класса Б, количество и тип передаваемых параметров известны, тип возвращаемого значения тоже. Компилятор компилит это в invokevirtual(или invokestatic, если он статик) с соответствующими заборами со стека и установкой параметра возврата в стеке, даже не зная, есть такой метод, или нет. Я не помню параметры cmd в стандартном компилере, но если ты точно знаешь параметры вызова, то любая ide скомпилит любой метод, даже если она не видит определения класса, к которому он применен. Если в рантайме в класспути не окажется, то вылетит ClassNotFoundException. Если такой класс есть, но нет такого метода — MethodNotFoundException. Ровно то же вылетит, если после валидной компиляции из рантайма убрать нужные классы.

E__>>, и даже если они недоступны при компиляции, рантайм легко может отработать без проблем

НС>Да при чем тут рантайм? Статически типизированный компилятор не может работать без сигнатуры в принципе, неважно что там будет в рантайме. Скомпилировать неизвестно какой вызов метода он не способен. А вот С# 4 способен, если это динамик, но это уже совсем другой разговор.

Способен, еще и как. Технически — не проблема. Тип передаваемых параметров известен из кода. Тип возвращаемого значения или известен(присваивается), или не важен(Object). Имя метода и класс известен. IDE плюются и матерятся на ошибки в таких случаях, но код компиляют.

Здравствуйте, мыщъх, Вы писали:

М>да и динамическая линковска с тем же dll -- никогда не знаешь какие там функции есть. допустим, в новой оси появилась новая фича. в старой dll такой функции нет. линкуем динамически

В джаве вообще нет понятия статической линковки. Там всегда текстовая ссылка на класс и метод. Если он есть в загруженных(или пути для загрузки) — исполняем, нет — исключение. А учитывая, что исполняемые архивы — банальные zip, или просто папки с классами, удалить легко. Или подменить. Или добавить, если не хватает.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Оплатишь работу? Потому что это не так то просто, тем более что непонятно, какие числовые оценки ты просишь.

Нет, не оплачу. Ты выдвинул тезис — будь добр его защищать. А оценки простые — какие именно структуры используются и как их размер зависит от N

PD>>К тому же. Потребности в памяти почему резко возросли.

НС>С чего ты взял? Цифры есть?

Да, конечно. Да их и не сложно получить совсем. Мой недавний проект (конвертировал с Delphi на С++). Совсем небольшой, 150 Кб исходников. Во время компиляции cl.exe (причем в режиме Debug, так что об оптимизации речи нет) Task Manager показывает Working Set от 15 до 25 Мб.

PD>> Для С++ почему ? Он вообще не менялся 10 лет

НС>Язык потому что сложнее.

Сложнее, чем Borland C++ 5.5 ? C++ с тех пор и вплоть до VS2008 включительно вообще не менялся. А BC5.5 работал на машине с 32 Мб памяти.

PD>> А C++ времени VS 2008 почему намного больше памяти требует, чем из VS6 ?

НС>А он требует? Я не про VS, я про cl.exe.

См. выше.

НС>>>А ты сравни объемы спецификаций. C# читается проще, это да, но это не потому что сложность меньше, а потому что интуитивности больше внимания уделяли.

PD>>Сложность на порядок(порядки) больше ?

НС>Вопрос непонятен.

Сложность C# на порядок больше, чем C++ ?

НС>Не проще. Но ты наглядно продемонстрировал свое непонимание. Одно сравнение обсчета матриц с компилятором и уверенность, что исходники пофайлово независимо компилируются уже о многом говорит.

Сравнение обсчета матриц было просто в качестве примера задачи, когда можно строить данные в ОП, а можно и на диске

Что же касается пофайловой компиляции (в С++, конечно) — проделй простой эксперимент. Проведи только компиляцию, а потом только линковку. Перед линковкой доступ к исходникам запрети (удали их).
cl.exe компилирует файлы независимо, каждый по отдельности
link.exe не имеет доступа к исходникам, а работает только с obj и lib.
Странно даже, что это приходится объяснять.

HC>>>К примеру, одна из самых первых обязательных стадий после парсинга — ресолвинг символов. В C# внутренняя ссылка может быть на любую public или internal декларацию в любом исходнике внутри одного проекта. Это буквально означает, что прежде чем ты приступишь к ресолвингу, тебе нужно отпарсить и частично отресолвить все декларации во всех исходниках проекта. Можно, конечно, АСТ отпарсенных исходников тут же выкидывать, а потом для каждого исходника парсить по новой с диска, но тогда мы конца компиляции не дождемся.

PD>>Численные данные, пожалуйста. Что и сколько места занимает. А иначе это все слова.

НС>Вопрос неконкретен. Какие конкретно численные данные ты хочешь получить?

Пожалуйста.
Размер линейного массива есть O(N)
Двумерного — O(N^2)
Списка — O(N)
Дерева — O(N)
Графа — в пределе O(N^2) но если в нем каждый узел с каждым не связан, то может оказаться ближе к O(N)

И т.д.

Вопросы.
1. Что такое N в применении к задаче компиляции ? Число типов, переменных,... ? Иными словами, от каких входных размеров зависит потребность в памяти ?
2. Что за структура данных с O(N^4) используется ?

НС>Это требует конкретики (какая конструкция, какой исходник) и весьма дорогое удовольствие (т.е. бесплатно я тебе такие оценки делать не буду, это приличная работа). Есть интерес — я могу тебе описать информацию качественно. А за количественными — лезь в гугль или попробуй сам написать хотя бы простенький компилятор. Если же не интересно — нафига оно мне?

Нет, не требует никакой конкретики. Просто ответь на те два вопроса, что даны выше.

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

а в том проекте на делфе, который вы конвертировали, использовался делфячий RTTI?
металкассы?
виртуальные конструкторы?
делфячая диспетчеризация сообщений?
case в записях?
директива absolute?
строки в качестве буфера?
загрузка пакетов?

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

E__>На самом деле, если внимательно смотреть на профайлер среднего приложения, то потери производительности именно на этом моменте обычно и в микроскоп не видно(а если видно, то всегда можно соптимизировать). Выделение памяти и сборка молодого поколения мусора, как и блочное копирование — операции не такие уж тяжелые.

вчера набирал больной пост в эту тему, но повисла опера.
однако я нашёл лучшее продолжение этой темы:

http://www.rsdn.ru/forum/flame.comp/4017169.1.aspx
(дальше копипаста)

	Скрытый текст
	В этом сообщении я хочу обратиться к создателям онлайн мессенджеров и вообще всем программистам (под винду, сразу скажу). Джентельмены, вы охудуба, я бы даже сказал у ели. Какого лешего (пусть будет леший) новая б -го мерзкая (тоже неплохой эффемизм на букву б) аська (да покарает аллах ее создателей до 4 ее колена) жрет 100 (!) метров памяти. Да вы не ослышались джентльмены, 100! Какого хугла хром жрет 100 метров при 2 открытых вкладках (почта и новости). А я знаю какого! И вот сейчас я вам скажу. Вы заи...грались в абстракции и квадратные люки. Вот какого пиндоса, вы гордитесь тем что вы не знаете как устроен ваш инструмент, платформа или компилятор. Вы гордитесь тем, что у вас есть зеленые как моя рожа при виде вашего творения потоки. Вы гордитесь тем, что ваши язычки поддерживают ленивые вычисления. Это вы ленивые, ваш синема... тьфу, ваши высокоуровневые инструментики превратили вас в толпу ленивых мулов. Я понимаю, когда задачи на понимание ООП даются зубрам, которые умеют программировать, умеют рассчитывать сколько им нужно памяти и производительности , но пишут так, что 100 тысяч братьев понять не могут. Это для них полезно, это снижает понимаемость кода в братьях со 100.000 до 10.000 и в редких случаях 100 братьев. Но когда сопляк, который только-только памперсы снял и PHP свое подтер, выплюнув соску верещит -- "это велосипеды, это байтодрочерство, я не буду этим заниматься, есть более высокоуровневые вещи" мне хочется снять ремень и надавать по той абстракции, от которой отнаследовались мозги в его маленькой головке. А почему? А потому что пока ты (дада, именно ты!) не поежался года 3-4 с байтоложеством, не поэкономил битики, твоя жаба экономии не квакает на слишком большие буффера, то сиди и байтоложь! И не дай бог тебе, сопле очкастой, заикнуться про преждевременную оптимизацию и выскоуровневые абстракции, если ты не хочешь чтобы тебе оторвали твою писсимизацию и затолкали по самые низкие уровни твоей темной абстракции.

	От:	Andrey.V.Lobanov
	Дата:	22.06.12 08:34
	Оценка:

	От:	Pavel Dvorkin
	Дата:	22.06.12 09:50
	Оценка:

	От:	Pavel Dvorkin
	Дата:	22.06.12 09:54
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	22.06.12 09:56
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	22.06.12 09:59
Оценка:	+1

	От:	Трололоша
	Дата:	22.06.12 14:03
	Оценка:

	От:	Ночной Смотрящий
	Дата:	23.06.12 22:35
	Оценка:

От:	мыщъх	http://nezumi-lab.org
Дата:	23.06.12 22:49
Оценка:

	От:	newCL
	Дата:	24.06.12 02:40
	Оценка:

	От:	newCL
	Дата:	24.06.12 04:01
	Оценка:	3 (1)