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

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

PD>>>>Просто тех, кто писать не умеет, нехватка памяти приводит в ступор и они переквалифицируются в управдомы

P>Тех, кто не умеет писать, не спасет никакое количество памяти. А у остальных сильно возрастут накладные расходы.

Не понял. Те, кто не смогут писать при жестких ограничениях на память, ничего не напишут. Те, кто смогут — напишут. Без всяких накладных расходов. Просто у них (воспользуюсь своим старым примером) хватит ума не создавать транспонированную матрицу вызовом mT = m1.transform(), а вместо этого они просто обойдутся исходной матрицей, организовав к ней досткп со сменой порядка индексов.

PD>>А по существу — дай сейчас написать кому-нибудь компилятор с того же Паскаля да чтобы работал на 1 Мбайте памяти, и результат очевиден : напишут те, кто умеет работать, а все остальные просто ничего не сделают.

P>С Паскаля — наверное. А вот C++ перестало хватать одного мегабайта, начиная с версии Borland C++ 3.0. А его не кто попало писал.

Трудно сказать, перестало ли хватать или просто решили использовать тот факт, что объем памяти в это время перевалил через 1 Мб. ОС-то однопрограммная, поэтому не использовать всю имеющуюся память неразумно, а коль ее на машинах стало 2-4 Мб, то почему не использовать ?

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

PD>А по существу — дай сейчас написать кому-нибудь компилятор с того же Паскаля да чтобы работал на 1 Мбайте памяти, и результат очевиден : напишут те, кто умеет работать, а все остальные просто ничего не сделают.

Не, которые пишут компилятор паскаля с явно выделенными проходами в 2012 году — те точно работать не умеют (если только это не курсовая в институте). А современные языки в принципе не подходят для компиляции с фиксированным потреблением памяти из-за фич типа перекрестных ссылок без forward-деклараций, сложного синтаксического сахара (list, query comprehension) и т.п.

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

PD>Не понял. Те, кто не смогут писать при жестких ограничениях на память, ничего не напишут. Те, кто смогут — напишут. Без всяких накладных расходов. Просто у них (воспользуюсь своим старым примером) хватит ума не создавать транспонированную матрицу вызовом mT = m1.transform(), а вместо этого они просто обойдутся исходной матрицей, организовав к ней досткп со сменой порядка индексов.

Я говорил о несколько иных накладных расходах. Ты как-то сказал следующее:

Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь

Контекст несколько иной был (там динамические языки обсуждались). Ну да ладно.
В таких условиях я реально работал. 64К оперативы, 200 (или чуть больше) переменных и крутись, как хочешь. Все переменные, помимо всего прочего, глобальные. Что со стеком — не помню. Может, урезали с 512 до 256 байт, чтобы что-то отдать основной памяти. Добавляю строку в программу, а у самого руки трясутся: каждое мгновение можно было выскочить за пределы.
Накладные расходы, и немалые, возникают, потому что программист должен постоянно отслеживать каждую переменную: так ли она используется, по назначению ли. Даже специальные таблицы заводили, чтобы знать, где хранится итог, что используется в качестве параметров подпрограммами. На это уходило слишком много ресурсов. Собственно, я как-то писал об этом.

PD>Трудно сказать, перестало ли хватать или просто решили использовать тот факт, что объем памяти в это время перевалил через 1 Мб. ОС-то однопрограммная, поэтому не использовать всю имеющуюся память неразумно, а коль ее на машинах стало 2-4 Мб, то почему не использовать ?

Далеко не у всех тогда такие машинки были, особенно если не в столице. 1 МБ перестало хватать, когда в C++ появились шаблоны. BC++ 2.0 еще умещался в 1 МБ.

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

E__>Это позволяет сделать иммутабельные строки, что само по себе очень хорошо.
А что в этом такого хорошего? Ну, кроме копирования на каждый чих.
E__>И, кстати, теряя в переводе массив байт <-> строка, мы получаем очень дешевую и безопасную операцию substring, по сравнению с традиционными c-строками.
Угумс. Есть строка на 100500 символов, нашли подстроку из 10, первая больше не нужна — сколько отожрано памяти?

PD>>>Я думаю, что все же там было что-то иное. Простой нехваткой памяти в 3 кольце BSOD не сотворишь. Или там была ошибка в ядре. Но от ошибок никто не застрахован.

M>>Без разницы. А выделенное — ключевое.

PD>Ну уж нет. Ядро Windows писали грамотные специалисты. Ну допустили ошибку, и что ? Ты их никогда не допускал ? Не надо из того факта, что был BSOD где-то когда-то, делать далеко идущие выводы.

Далеко идущие выводы делаешь только ты.

M>>>>В общем, не надо рассказывать сказки про то, как ограниченные ресурсы моментально делают из программистов безгрешных гениев — тошнит уже

PD>>>А этого я и не утверждал. Просто тех, кто писать не умеет, нехватка памяти приводит в ступор и они переквалифицируются в управдомы

M>>Не надо рассказывать эти басни.

PD>Оставь себе и сказки, и басни. В качестве аргумента они не годятся.

Ну да. В качестве аргумента годится только бредятина типа

M>А от идиотов никакая память не спасет.
От идиотов спасает только ее нехватка.

Это, видать, верх аргументации

PD>А по существу — дай сейчас написать кому-нибудь компилятор с того же Паскаля да чтобы работал на 1 Мбайте памяти, и

Ди иди ты уже в пень со своим Паскалем. Ни он, ни его компилятор в один мегабайт сейчас не нужны даже даром. То, что его компилятор работал в одном мегабайте, ен значило, что программы, написанные на нем, не будут вылетать с ООМ. И вылетали.

Если нужен маленький быстрый язык, его делают. См. Луа и т.п.

PD>результат очевиден : напишут те, кто умеет работать, а все остальные просто ничего не сделают.

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

PD>>А по существу — дай сейчас написать кому-нибудь компилятор с того же Паскаля да чтобы работал на 1 Мбайте памяти, и результат очевиден : напишут те, кто умеет работать, а все остальные просто ничего не сделают.

НС>Не, которые пишут компилятор паскаля с явно выделенными проходами в 2012 году — те точно работать не умеют (если только это не курсовая в институте). А современные языки в принципе не подходят для компиляции с фиксированным потреблением памяти из-за фич типа перекрестных ссылок без forward-деклараций, сложного синтаксического сахара (list, query comprehension) и т.п.

Хочешь узнать классический ответ Дворкина? Цитирую по памяти, но практически дословно:

Но Паскаль же помещался!!! В один!!!!!! Мегабайт!!!!!!!!! Сейчас что так не умеют?!!!!!!!!!!!!!!!!!!!!

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

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

E__>>>Это позволяет сделать иммутабельные строки, что само по себе очень хорошо.
Ops>>А что в этом такого хорошего? Ну, кроме копирования на каждый чих.
MM>Копирования на каждый чих нет. Почитай посты в этой теме: рассмотренно множество положительных аспектов иммутабельности строк.
90% покрывает константность/константные ссылки. Остальное да, надо тратить время, продумывая поведение. Зато можно дешево if(s[0]=='a') s[0]='b';

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

MM>>Копирования на каждый чих нет. Почитай посты в этой теме: рассмотренно множество положительных аспектов иммутабельности строк.
Ops>90% покрывает константность/константные ссылки. Остальное да, надо тратить время, продумывая поведение. Зато можно дешево if(s[0]=='a') s[0]='b';
Не покрывается даже половины, если читать внимательно и думать. И не стоит называть борьбу с ветряными мельницами "продумыванием поведения".

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

Ну, с этими крутыми строками в C++ я не так давно избавил один фреймворк от тройного!!! не только копирования но и преобразования (UTF16->UTF8->UTF16). Почему оно получилось? Да язык этот ваш (C++) к этому просто способствует. Это не то, что бы недостаток, — если бы фреймворк бы считал строки мутабельными — это бы было вообще ховайся. Однако даже в C++ мире как-то часто предпочитают думать о строках, как о нечто иммутабельном. И тем не менее из-за зоопарка типов одной размерности того грядишь — и проскочит std::string который испортит всё. Практически всегда где нужны мутабельные строки — это где-то близко к StringBuilder. Мутабельность строк и буффер символов — реально путают. Да, если взять .NET — то из StringBuilder, не получишь строку без копирования. Тем не менее на практике это всё ерунда. Даже если взять передачу в Java/.NET по ссылке не заботясь о том кто владелец и кто её высвободит — это может очень сильно упростить и код и зоны ответственности и даже скорость. Ещё не видел вменяемых API которые бы на вход строки не принимали бы by val (копируя их внутри) — потому что не копирование — доступно только для сред с иммутабельнными строками. Чую глупость написал. Имеется ввиду — для сред — с единым владельцем объектов. Эм. Ну короче для строк — мы их получаем, но никто их нас их не освобождает. Строки это такая бяка на которой в правильных задачах просадку можно получить — а Java и .NET — отлично с ними справляются. Ых же ж!

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

PD>Оставь себе и сказки, и басни. В качестве аргумента они не годятся.
PD>А по существу — дай сейчас написать кому-нибудь компилятор с того же Паскаля да чтобы работал на 1 Мбайте памяти, и результат очевиден : напишут те, кто умеет работать, а все остальные просто ничего не сделают.

Знаешь, когда надо — и в 64К памяти укладываешься. Это был не компилятор, но все-таки: нужно было спроцессить несколько мегабайт данных при 64К оперативы, и уложить их в некую структуру в памяти, с которой в дальнейшем работать. Совсем недавно было, года 3 назад, т.е. уже когда типа привык к гектарам. Ну девайс такой — слабенький.
Все не так сложно, но, понятно, от некоторых функций "большого компа" пришлось банально отказаться — их никак не упихать в этот девайс за приемлимое время(да и многопоточность, которой там изначально нет, врукопашную делать не хотелось, хотя я вроде-бы понимаю, как). Но вот мне, жависту, не составило большого труда написать на сях 90% функционала от "большой проги", хоть и в упрощенном виде, на очень слабом девайсе.
Но — _упрощенно_. Никаких свистелок и перделок, все только по делу.

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

E__>>Это позволяет сделать иммутабельные строки, что само по себе очень хорошо.
Ops>А что в этом такого хорошего? Ну, кроме копирования на каждый чих.
E__>>И, кстати, теряя в переводе массив байт <-> строка, мы получаем очень дешевую и безопасную операцию substring, по сравнению с традиционными c-строками.
Ops>Угумс. Есть строка на 100500 символов, нашли подстроку из 10, первая больше не нужна — сколько отожрано памяти?

100500. Но нужно же понимать, что мы делаем, верно? Если вдруг нам нужно по 10 символов из тысяч строк по 10 мегабайт, то всегда можно сделать new для каждой, и будет копирование, а прежние строки отойдут силами ГЦ в мир иной. Хотя обычно задача другая — из одной строки навычленять токенов. Но это неважно.

Самое главное — понимать, как в твоем текущем инструменте организованы структуры данных, и использовать их максимально эффективно. А то ведь можно сильно погореть на постоянных сабстрингах и вычислениях длины С-строк(нуллованных, изменяемых), или на неправильной работе с иммутабельными(тут тоже нюансов дочерта). Главное — знать. А так — создать иммутабельную строку в С++, или мутабельную в жабошарпе — нетрудно. Вопрос в том, когда это реально нужно, когда это применить.

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

НС>Не, которые пишут компилятор паскаля с явно выделенными проходами в 2012 году — те точно работать не умеют (если только это не курсовая в институте). А современные языки в принципе не подходят для компиляции с фиксированным потреблением памяти из-за фич типа перекрестных ссылок без forward-деклараций, сложного синтаксического сахара (list, query comprehension) и т.п.

Хм...
Вообще-то потребление памяти всегда имеет предел (фиксировано). Вопрос лишь , чему он равен.

А вообще объем памяти, грубо говоря, это объем кода плюс объем данных. Если речь идет о компиляторе, то объем данных фиксирован, так как исполнения нет. Какие бы там ни потребовалось структуры построить при компиляции, их объем чем-то да определяется. Речь идет , естественно, не об объеме данных времени исполнения, а об объеме данных внутренних структур эпохи компиляции. На выходе в любом случае очень и очень мало (obj-файлы или dll или что-то еще) Объем кода сравнительно мал, так что весь вопрос — какие именно структуры данных там строятся.
Интерпретатор — другое дело. Там объем данных определяется в рантайме (компиляция совмещена с исполнением), так что он зависит не только от текста программы и внутренних структур эпохи компиляции, но и от объема данных эпохи рантайма.

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

P>Контекст несколько иной был (там динамические языки обсуждались). Ну да ладно.
P>В таких условиях я реально работал. 64К оперативы, 200 (или чуть больше) переменных и крутись, как хочешь. Все переменные, помимо всего прочего, глобальные. Что со стеком — не помню. Может, урезали с 512 до 256 байт, чтобы что-то отдать основной памяти. Добавляю строку в программу, а у самого руки трясутся: каждое мгновение можно было выскочить за пределы.
P>Накладные расходы, и немалые, возникают, потому что программист должен постоянно отслеживать каждую переменную: так ли она используется, по назначению ли. Даже специальные таблицы заводили, чтобы знать, где хранится итог, что используется в качестве параметров подпрограммами. На это уходило слишком много ресурсов. Собственно, я как-то писал об этом.

Мне тоже жоводилось, хоть и не так жестко.

PD>>Трудно сказать, перестало ли хватать или просто решили использовать тот факт, что объем памяти в это время перевалил через 1 Мб. ОС-то однопрограммная, поэтому не использовать всю имеющуюся память неразумно, а коль ее на машинах стало 2-4 Мб, то почему не использовать ?

P>Далеко не у всех тогда такие машинки были, особенно если не в столице. 1 МБ перестало хватать, когда в C++ появились шаблоны. BC++ 2.0 еще умещался в 1 МБ.

Когда BC++ 3.1 появился, машины под него были уже в достаточном количестве. У нас в университете мы его сразу поставили. Собственн, любая 386 годилась — их ИМХО меньше чем с 2 Мб не выпускали.

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

M>Далеко идущие выводы делаешь только ты.
M>>>Не надо рассказывать эти басни.
M>Ну да. В качестве аргумента годится только бредятина типа
M>Ди иди ты уже в пень со своим Паскалем.

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

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

P>>Накладные расходы, и немалые...

PD>Мне тоже жоводилось, хоть и не так жестко.

Значит, накладные расходы существуют, и они непосредственно связаны с разработкой. Снизить их помог переход на PC, у которых был целый мегабайт оперативы и нормальная файловая система. Оказалось, что переменные бывают не только глобальные, и вагон проблем, имеющий место при разработке в условиях жестких ограничений, просто не существует.
Разумеется, когда говорят, что на 2 гигах сражаются за каждый байт, у меня это вызывает улыбку. Но только потому, что за каждый байт мне приходилось сражаться в упомянутом мною проекте, да еще при написании резидентов в MS DOS. А так, кто знает, может, и есть такие задачи.

PD>Когда BC++ 3.1 появился, машины под него были уже в достаточном количестве. У нас в университете мы его сразу поставили. Собственн, любая 386 годилась — их ИМХО меньше чем с 2 Мб не выпускали.

Я в конце 90-х работал на 286 с 1 Мб памяти. Что в конторе стояло, тем и пользовался. Дома, правда, Пень уже стоял.

Да, PL/1 работал в 96 Кб.

M>>Далеко идущие выводы делаешь только ты.
M>>>>Не надо рассказывать эти басни.
M>>Ну да. В качестве аргумента годится только бредятина типа
M>>Ди иди ты уже в пень со своим Паскалем.

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

Еще ращ повторю. Моя аргументация — ровно такая же, как твоя. Хотя нет, лучше. Она не является бреднями.

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

PD>Хм...
PD>Вообще-то потребление памяти всегда имеет предел (фиксировано). Вопрос лишь , чему он равен.

Ликбез — компиляторы времен 1 мегабайта (а точнее 600 килобайт) должны были уметь компилировать исходники объемом больше одного мегабайта. Это принципиальное требование для любого промышленного компилятора. И именно поэтому существовала такая характеристика, как количество проходов, так как держать в памяти всю программу (весь модуль компиляции) было нельзя. И еще были всякие хитрозадые костыли для компиляции программы по кусочкам, так как таблицы символов все равно надо было держать в памяти целиком.
Сейчас так компиляторы не пишут, сейчас формируют в памяти AST, а потом делают по нему кучу проходов и трансформаций (десятки). Это сильно развязало руки разработчикам языков, но требует, чтобы памяти было в разы больше, чем это самое AST, пусть и с подкачкой.

PD>Если речь идет о компиляторе, то объем данных фиксирован, так как исполнения нет.

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

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

PD>>Вообще-то потребление памяти всегда имеет предел (фиксировано). Вопрос лишь , чему он равен.

НС>Ликбез — компиляторы времен 1 мегабайта (а точнее 600 килобайт) должны были уметь компилировать исходники объемом больше одного мегабайта. Это принципиальное требование для любого промышленного компилятора.

Безусловно.

>И именно поэтому существовала такая характеристика, как количество проходов, так как держать в памяти всю программу (весь модуль компиляции) было нельзя. И еще были всякие хитрозадые костыли для компиляции программы по кусочкам, так как таблицы символов все равно надо было держать в памяти целиком.

Все верно. Тем не менее объем данных при размере файла в один Мб (а мне доводилось работать с компилятором, который работал не на 1 Мб, а на 64 Кб) чему-то равен. Да, их можно разместить в ОП, если ее много, или же на диске, если нет. Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.

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

В разы — не спорю. Но между 1 Мб и 100 Мб не разы , а порядки.

PD>>Если речь идет о компиляторе, то объем данных фиксирован, так как исполнения нет.

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

Естественно, я их не писал, так что вопрос твой риторический. Но аналогичную вещь я писал. Математическую статистику при том, что исходные данные в ОП не помещались. Да, там было несколько проходов с хранением строк матрицы на диске и обращениями к ним по ходу работы. Разумееется, сейчас я бы не стал этого делать, а сохранил бы матрицу целиком в ОП. Только вот объем данных от этого никак бы не изменился.

Что же касается того, сколько там проходов — вопрос не в числе проходов, а в скорости компиляции. Само по себе число проходов мало кого интересует. А вот скорость компиляции (строк/секунду) у того же ТурбоПаскаля была ничуть не хуже, чем у нынешних компиляторов, при том, что тактовая частота была на 2 порядка меньше.

И последнее. Исходник размером в 1 Мб — это и сейчас экзотика. В большинстве случаев размеры исходников — десятки или сотни Кб. То, что файлы компилируются независимо, надеюсь, объяснять не надо. Я не исключаю, что при размере исходника в 1Мб или более скорость работы ТурбоПаскаля резко бы замедлилась (просто не пробовал), но это не мешало ему работать быстро при обычных размерах.

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

PD>Все верно. Тем не менее объем данных при размере файла в один Мб (а мне доводилось работать с компилятором, который работал не на 1 Мб, а на 64 Кб) чему-то равен.

Главное — он либо не зависит или слабо зависит от размера исходников, что раньше и было (зависимость < O(N)), либо зависит сильно, что сейчас встречается чаще. Причем бывают очень тяжелые случаи, типа вложенных лямбд в шарпе, для которых алгоритм без эвристик, емнип, O(N^4). В эпоху 1 мегабайта таких фич не было в промышленных языках.

PD>Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.

Где я такое утверждал?

PD>В разы — не спорю. Но между 1 Мб и 100 Мб не разы , а порядки.

Ты сам придумал 100 Мб и теперь сам с собой споришь.

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

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

А я — писал.

PD>так что вопрос твой риторический

Вовсе нет.

PD>. Но аналогичную вещь я писал. Математическую статистику

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

PD>Что же касается того, сколько там проходов — вопрос не в числе проходов, а в скорости компиляции

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

PD>А вот скорость компиляции (строк/секунду) у того же ТурбоПаскаля была ничуть не хуже, чем у нынешних компиляторов, при том, что тактовая частота была на 2 порядка меньше.

Сложность тоже на 2 порядка меньше того же шарпа. Интерпретатор Паскаля у нас был на курсовой на 3 ил 4 курсе, за интерпретатор современного шарпа я и сейчас в одиночку не возьмусь.

PD>И последнее. Исходник размером в 1 Мб — это и сейчас экзотика

У кого как.

PD>В большинстве случаев размеры исходников — десятки или сотни Кб.

Это какие то игрушечные проекты, неделя работы.

PD> То, что файлы компилируются независимо, надеюсь, объяснять не надо.

Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.

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

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

На этом месте разговор с ним можно прекращать, на самом деле

Ops>90% покрывает константность/константные ссылки. Остальное да, надо тратить время, продумывая поведение. Зато можно дешево if(s[0]=='a') s[0]='b';

Только вот даром эта дешевость никому не нужна. Потому что все давно живут в эпоху юникода и s[0] == 'ö' уже не прокатит.

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

PD>>Все верно. Тем не менее объем данных при размере файла в один Мб (а мне доводилось работать с компилятором, который работал не на 1 Мб, а на 64 Кб) чему-то равен.

НС>Главное — он либо не зависит или слабо зависит от размера исходников, что раньше и было (зависимость < O(N)), либо зависит сильно, что сейчас встречается чаще. Причем бывают очень тяжелые случаи, типа вложенных лямбд в шарпе, для которых алгоритм без эвристик, емнип, O(N^4). В эпоху 1 мегабайта таких фич не было в промышленных языках.

Объем данных N^4 ? Что за структуры такие ? Четырехмерные массивы строятся ?

PD>>Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.

НС>Где я такое утверждал?

Я и не говорю, что ты утверждал. Я просто спрашиваю — зачем при размере исходников в 1 Мб нужны промежуточные структуры размером в 100 Мб ?

PD>>В разы — не спорю. Но между 1 Мб и 100 Мб не разы , а порядки.

НС>Ты сам придумал 100 Мб и теперь сам с собой споришь.

Вот уж нет. Я говорю о памяти, занимаемой компилятором. Если ты утверждаешь, что ему 100 Мб не надо — тогда о чем спор ? На 10 Мб я вполне согласен, я же не требую, чтобы он в 1 Мб и сейчас укладывался.

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

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

НС>А я — писал.

Ну что же...

PD>>так что вопрос твой риторический

НС>Вовсе нет.

PD>>. Но аналогичную вещь я писал. Математическую статистику

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

Давай по существу, а то как-то беспредметно получается. Ты утверждаешь, что там может понадобиться N^4 памяти. Что за структура такая ?

PD>>Что же касается того, сколько там проходов — вопрос не в числе проходов, а в скорости компиляции

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

Что-то я не пойму. А когда памяти стало больше, то что ? Появилась необходимость делать не-однопроходной ? Или стало невозможным добиться этой же как минимум скорости компиляции ?

PD>>А вот скорость компиляции (строк/секунду) у того же ТурбоПаскаля была ничуть не хуже, чем у нынешних компиляторов, при том, что тактовая частота была на 2 порядка меньше.

НС>Сложность тоже на 2 порядка меньше того же шарпа. Интерпретатор Паскаля у нас был на курсовой на 3 ил 4 курсе, за интерпретатор современного шарпа я и сейчас в одиночку не возьмусь.

А Object Pascal ? Он тоже на 2 порядка сложнее Turbo Pascal ? Естественно, я не о библиотеках говорю, а о языке самом. Заменили object на class, изменили модель на ссылочную и сразу на 2 порядка сложность возросла ? А С++ ? Он тоже на 2 порядка сложнее С ? В несколько раз сложнее, да, но не в 100. Да и шарп (без LinQ) , скорее всего, не сложнее, а проще С++ : он логичнее его.

PD>>И последнее. Исходник размером в 1 Мб — это и сейчас экзотика

НС>У кого как.

Не у кого как, а в большинстве случаев. Не принято сейчас делать исходники больших размеров. В Яве так вообще рекомендация Sun не более 2000(?) строк. А в С++ и C# никто не мешает их разбивать на части даже без изменения структуры классов.

PD>>В большинстве случаев размеры исходников — десятки или сотни Кб.

НС>Это какие то игрушечные проекты, неделя работы.

Ты меня не понял. Я имею в виду ОДИН файл исходника.

PD>> То, что файлы компилируются независимо, надеюсь, объяснять не надо.

НС>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.

А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику. Файлы исходников C++ компилируются независимо, и создаются .obj. Убедиться в этом очень просто — посмотри лог компилятора. А вот после этого уже из линкера вызывается вторая фаза (c2.dll), которая, однако, к исходникам доступа не имеет, а работает только с .obj. Я же говорил именно о компиляции.

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

PD>Что за структуры такие ? Четырехмерные массивы строятся ?

Долго объяснять, особенно без опыта.

PD>>>Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.
НС>>Где я такое утверждал?
PD>Я и не говорю, что ты утверждал.

Круто.

PD> Я просто спрашиваю — зачем при размере исходников в 1 Мб нужны промежуточные структуры размером в 100 Мб ?

Сам придумал — сам и отвечай. Зачем собаке пятая нога, ответь мне.

НС>>Ты сам придумал 100 Мб и теперь сам с собой споришь.
PD>Вот уж нет.

А кто придумал?

PD> Я говорю о памяти, занимаемой компилятором. Если ты утверждаешь, что ему 100 Мб не надо — тогда о чем спор ?

О том, что памяти при сравнимых объемах современные компиляторы потребляют больше, так как некоторые языковые фичи требуют удерживать в памяти большие объемы данных. Ты же тут фокусника изображаешь, высовывая из кармана какие то левые числа и требуя от меня объеснения, что это за числа.
Если ты утерял нить логики, кратко переформулирую: при разработке языков и компиляторов в эпохе одного мегабайта языки дизайнились специальным образом, дабы можно было в скромных объемах памяти и медленном диске скомпилировать большую программу за приемлемое время. Сейчас такой потребности нет.
Давай более простой пример приведу: в турбопаскале, если ты хочешь использовать функцию, которая будет объявлена позже, нужно описать сигнатуру этой функции в виде т.н. forward declaration. Это позволяет компилятору в один проход иметь гарантию того, что в его таблицах символов уже будет на момент вызова полная информация о сигнатуре. Если же посмотрим на какую нибудь джаву, то увидим, что там такого требования уже нет, потому что компилятор поднимает в память все АСТ модуля компиляции (для джавы это класс и все вложенные в него) и первым проходом собирает только декларации типов. Для C# ситуация еще веселее, так как модуль компиляции там — сборка, и может содержать большое количество исходников. Итого — ужор памяти компиляторов современных языков будет сильно сильно больше паскаля, но это не означает, что авторы компиляторов пишут плохой код.

НС>>А я — писал.
PD>Ну что же...

Придется верить мне на слово

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

PD>Давай по существу, а то как-то беспредметно получается

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

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

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

НС>>Сложность тоже на 2 порядка меньше того же шарпа. Интерпретатор Паскаля у нас был на курсовой на 3 ил 4 курсе, за интерпретатор современного шарпа я и сейчас в одиночку не возьмусь.

PD>А Object Pascal ?

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

PD> Он тоже на 2 порядка сложнее Turbo Pascal ?

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

PD> Естественно, я не о библиотеках говорю, а о языке самом. Заменили object на class

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

PD>, изменили модель на ссылочную и сразу на 2 порядка сложность возросла ?

Нет.

PD> А С++ ? Он тоже на 2 порядка сложнее С ?

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

PD>Да и шарп (без LinQ) , скорее всего, не сложнее, а проще С++ : он логичнее его.

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

PD>Не принято сейчас делать исходники больших размеров. В Яве так вообще рекомендация Sun не более 2000(?) строк. А в С++ и C# никто не мешает их разбивать на части даже без изменения структуры классов.

Так, еще раз — неважно сколько файлов исходников. Важно сколько исходников в одном модуле компиляции. В случае джавы да — там модуль очень маленький. А вот в случае С# и С++ все намного печальнее.

НС>>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.

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

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

PD> Файлы исходников C++ компилируются независимо, и создаются .obj.

Потому что С++ достаточно древний и там есть такой костыль как хидер-файлы. Получившуюся в результате скорость компиляции оценить не сложно. Зато на 1 мегабайте когда то работало. В С# хидеров нет.

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

Ops>>90% покрывает константность/константные ссылки. Остальное да, надо тратить время, продумывая поведение. Зато можно дешево if(s[0]=='a') s[0]='b';
M>Только вот даром эта дешевость никому не нужна. Потому что все давно живут в эпоху юникода и s[0] == 'ö' уже не прокатит.
Да какой там еще юникод. Он поведение продумывает, не мешай ему. Нам лохам не понять. Нас бесконечная память развратила.

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

PD>А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику. Файлы исходников C++ компилируются независимо, и создаются .obj. Убедиться в этом очень просто — посмотри лог компилятора. А вот после этого уже из линкера вызывается вторая фаза (c2.dll), которая, однако, к исходникам доступа не имеет, а работает только с .obj. Я же говорил именно о компиляции.
ой, ну опять ))) а вот сидит во второй фазе whole program optimization, тут и именно компиляция, и вообще объём собственно исходников уже бесконечно мал по сравнению с тем, что будет ворочаться.

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

НС>>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.
PD>А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику. Файлы исходников C++ компилируются независимо, и создаются .obj. Убедиться в этом очень просто — посмотри лог компилятора. А вот после этого уже из линкера вызывается вторая фаза (c2.dll), которая, однако, к исходникам доступа не имеет, а работает только с .obj. Я же говорил именно о компиляции.
И нахрен такая компиляция? "Линковка", Хромиума, например, с нуля — это часы при сборке в релизе (в дебаге — ещё дольше), если на тачке всего 2GB RAM. Рекомендуют 8-16Gb, 4 ядра и SSD, что бы с этим можно было вменяемо работать. link.exe — отжирает ~1Gb RAM по таскменеджеру, а на самом деле всё это сборочное хозяство в коммите держит >3.5Gb, ну т.е. на деле — около 2.5Gb и часов работы посвященных именно этой крутой "независимой" компиляции. Разумеется та стадия "парсинга" и всасывания мегабайтов хидеров — тоже занимает время. C#-у и им подобным, на разумных (не искусственных) задачах — такого же потребления памяти и ресурсов — добиться нереально.
PS: И не смотря на то, что у разработчиков хрома очень нехилые машины по всей видимости — они всё равно очень озадачились сборкой с динамическими либами, преодолевая миллиарды надуманных проблем. Преодолели — реально гораздо удобнее. Но фактически только для дебага.

НС>>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.

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

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

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

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

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

Компилятор джавы, к слову, однопроходный(в отличие от той же скалы). Особенно если брать эклипсовкий, который компилит в любом случае, даже если в коде есть ошибки(т.е. недоступен какой-то класс в данное время). Но сравнивать жабовский байткод и нативу — странно. В жабе изначально имена внешних классов текстовые, и даже если они недоступны при компиляции, рантайм легко может отработать без проблем, если нужную либу подкинули(для компиляции она особо и не нужна, хотя IDE будет матюкаться на ее отсутствие, но код скомпиляет). Реальный компилятор пройдется уже по рантайму, но это другой вопрос.

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

НС>>>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.
PD>>А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику. Файлы исходников C++ компилируются независимо, и создаются .obj. Убедиться в этом очень просто — посмотри лог компилятора. А вот после этого уже из линкера вызывается вторая фаза (c2.dll), которая, однако, к исходникам доступа не имеет, а работает только с .obj. Я же говорил именно о компиляции.

F> И нахрен такая компиляция? "Линковка", Хромиума, например, с нуля — это часы при сборке в релизе (в дебаге — ещё дольше), если на тачке всего 2GB RAM. Рекомендуют 8-16Gb, 4 ядра и SSD, что бы с этим можно было вменяемо работать. link.exe — отжирает ~1Gb RAM по таскменеджеру, а на самом деле всё это сборочное хозяство в коммите держит >3.5Gb, ну т.е. на деле — около 2.5Gb и часов работы посвященных именно этой крутой "независимой" компиляции.
Там работает стадия WPO, аналог суперкомпиляции. Вырубите WPO и всё станет летать и жрать в разы меньше.

... << RSDN@Home>>

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

НС>Долго объяснять, особенно без опыта.
НС>Круто.
НС>Сам придумал — сам и отвечай. Зачем собаке пятая нога, ответь мне.
НС>А кто придумал?
HC>Ты же тут фокусника изображаешь, высовывая из кармана какие то левые числа и требуя от меня объеснения, что это за числа.
НС>Если ты утерял нить логики

М-да. Обычно такие аргументы используют, когда нечего сказать по существу.

НС>Если ты утерял нить логики, кратко переформулирую: при разработке языков и компиляторов в эпохе одного мегабайта языки дизайнились специальным образом, дабы можно было в скромных объемах памяти и медленном диске скомпилировать большую программу за приемлемое время. Сейчас такой потребности нет.
НС>Давай более простой пример приведу: в турбопаскале, если ты хочешь использовать функцию, которая будет объявлена позже, нужно описать сигнатуру этой функции в виде т.н. forward declaration. Это позволяет компилятору в один проход иметь гарантию того, что в его таблицах символов уже будет на момент вызова полная информация о сигнатуре. Если же посмотрим на какую нибудь джаву, то увидим, что там такого требования уже нет, потому что компилятор поднимает в память все АСТ модуля компиляции (для джавы это класс и все вложенные в него) и первым проходом собирает только декларации типов. Для C# ситуация еще веселее, так как модуль компиляции там — сборка, и может содержать большое количество исходников. Итого — ужор памяти компиляторов современных языков будет сильно сильно больше паскаля, но это не означает, что авторы компиляторов пишут плохой код.

Мне это известно. А все же, можно объяснить, как тут возникает N^4. Пусть ФСТ, пусть тысячи типов , пусть. Сколько под тысячу (одну тысячу) типов надо памяти. С АСТ, с чем кгодно. А то я пока только вижу попытки демагогии и никаких конкретных, пусть хотя бы прикидочных, данных. Вот приведешь их — тогда и будет о чем говорить. А пока не о чем.

НС>>>А я — писал.
PD>>Ну что же...

НС>Придется верить мне на слово

Нет, без данных я верить тебе на слово не обязан.

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

PD>>Давай по существу, а то как-то беспредметно получается

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

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

PD>>А Object Pascal ?

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

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

PD>> Он тоже на 2 порядка сложнее Turbo Pascal ?

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

К тому же. Потребности в памяти почему резко возросли. Для С++ почему ? Он вообще не менялся 10 лет, с VS6 по VS2008 никаких серьезных изменений.

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

Object был в TP 6.0.

PD>>, изменили модель на ссылочную и сразу на 2 порядка сложность возросла ?

НС>Нет.

PD>> А С++ ? Он тоже на 2 порядка сложнее С ?

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

Новый опустим, ему чуть больше года. А C++ времени VS 2008 почему намного больше памяти требует, чем из VS6 ?

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

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

PD>>Не принято сейчас делать исходники больших размеров. В Яве так вообще рекомендация Sun не более 2000(?) строк. А в С++ и C# никто не мешает их разбивать на части даже без изменения структуры классов.

НС>Так, еще раз — неважно сколько файлов исходников. Важно сколько исходников в одном модуле компиляции. В случае джавы да — там модуль очень маленький. А вот в случае С# и С++ все намного печальнее.

НС>>>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.

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

НС>Ты ее совсем не знаешь.

Ну разумеется. Проще всего сказать, что твой оппонент ничего не понимает...

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

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

PD>> Файлы исходников C++ компилируются независимо, и создаются .obj.

НС>Потому что С++ достаточно древний и там есть такой костыль как хидер-файлы. Получившуюся в результате скорость компиляции оценить не сложно. Зато на 1 мегабайте когда то работало. В С# хидеров нет.

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

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

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

AVL>ой, ну опять ))) а вот сидит во второй фазе whole program optimization, тут и именно компиляция, и вообще объём собственно исходников уже бесконечно мал по сравнению с тем, что будет ворочаться.

Хм. Насколько я помню, вторая фаза (C2.DLL) доступа к исходникам не имеет. Вызывается она из линкера, так что не об этом вообще речь. Я говорил о потребности в памяти cl.exe.

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

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

M>

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

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

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

//////////////

НС>Файлы исходников? Конечно зависимо, очень странно что это для тебя новость. Независимо они только парсятся (и то в случае С++ тут не все так просто), но это 1% общей работы.

А вот такие вещи говорить не надо, так как я достаточно хорошо знаю эту тематику. Файлы исходников C++ компилируются независимо, и создаются .obj. Убедиться в этом очень просто — посмотри лог компилятора. А вот после этого уже из линкера вызывается вторая фаза (c2.dll), которая, однако, к исходникам доступа не имеет, а работает только с .obj. Я же говорил именно о компиляции.

//////////////

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

F> И нахрен такая компиляция? "Линковка", Хромиума, например, с нуля — это часы при сборке в релизе (в дебаге — ещё дольше), если на тачке всего 2GB RAM. Рекомендуют 8-16Gb, 4 ядра и SSD, что бы с этим можно было вменяемо работать. link.exe — отжирает ~1Gb RAM по таскменеджеру, а на самом деле всё это сборочное хозяство в коммите держит >3.5Gb, ну т.е. на деле — около 2.5Gb и часов работы посвященных именно этой крутой "независимой" компиляции. Разумеется та стадия "парсинга" и всасывания мегабайтов хидеров — тоже занимает время. C#-у и им подобным, на разумных (не искусственных) задачах — такого же потребления памяти и ресурсов — добиться нереально.

Это как раз неудивительно. В C# оптимизация во время компиляции совсем не та, что в С++ , предполагается, что ей займется JIT на target машине. Поэтому и скорость компиляции больше, и потребность в памяти меньше. На оптимизацию, да еще кроссмодульную, время действительно нужно.

Мегабайты хидеров сейчас при каждой компиляции не всасывают, есть predcompiled headers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 с байтоложеством, не поэкономил битики, твоя жаба экономии не квакает на слишком большие буффера, то сиди и байтоложь! И не дай бог тебе, сопле очкастой, заикнуться про преждевременную оптимизацию и выскоуровневые абстракции, если ты не хочешь чтобы тебе оторвали твою писсимизацию и затолкали по самые низкие уровни твоей темной абстракции.

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

CL>Какого лешего (пусть будет леший) новая б -го мерзкая (тоже неплохой эффемизм на букву б) аська (да покарает аллах ее создателей до 4 ее колена) жрет 100 (!) метров памяти. Да вы не ослышались джентльмены, 100! Какого хугла хром жрет 100 метров при 2 открытых вкладках (почта и новости).

Извини, я чуть заземлю твой пафос. Вопрос: о какой именно памяти идёт речь?

Я тут недавно разбирался с чудовищным потреблением "памяти" своей программой. Например, при старте она, согласно показаниям системных средств, "потребляет" около 2.5GB и дальше не сокращается. Казалось бы, страшная цифра. Но вот что оказалось:
1) На каждый тред по умолчанию аллоцируется 8MB адресов в пространстве процесса.
2) glibc malloc аллоцирует по умолчанию по 8 64-мегабайтных "арен" на каждое ядро среды выполнения, хотя делает это своеобразно (вначале — по одной арене на тред).
Обе этих аллокации просто отводят адресный диапазон, но не коммитят.

Когда мы начали считать раздельно три цифры
* объём аллоцированной хоть под что-то виртуальной памяти
* суммарный объём грязных страниц
* суммарный объём резидентных страниц
то все эти страшные цифры потребления остались только в первом из них, и измеренеие плоезных цифр (для нас это в первую очередь sum_dirty) свежезапущенного процесса вместо ~2.5GB стало реально показывать 30 MB — это уже для данной программы вполне нормально.

Это я к тому, что рассказывая про страшные цифры, каждый должен знать, что именно эта цифра отражает. Если это объём виртуальной памяти процесса, то это вообще ничего не значит. Ты вспомнил хром? Мой текущий хром (на дебиане) имеет 310M виртуалки, 47MB резидентной памяти, но только 30MB грязных страниц.

[...]

CL> Но когда сопляк, который только-только памперсы снял и PHP свое подтер, выплюнув соску верещит -- "это велосипеды, это байтодрочерство, я не буду этим заниматься, есть более высокоуровневые вещи" мне хочется снять ремень и надавать по той абстракции, от которой отнаследовались мозги в его маленькой головке. А почему? А потому что пока ты (дада, именно ты!) не поежался года 3-4 с байтоложеством, не поэкономил битики, твоя жаба экономии не квакает на слишком большие буффера, то сиди и байтоложь! И не дай бог тебе, сопле очкастой, заикнуться про преждевременную оптимизацию и выскоуровневые абстракции, если ты не хочешь чтобы тебе оторвали твою писсимизацию и затолкали по самые низкие уровни твоей темной абстракции.

Какой слог. Даже жалко, что автор тут не присутствует.
Но всё-таки: что именно он мерял?

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

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

если о типе во время компиляции ничего не известно, то RTTI бесполезен (не нужен).
нужно знать базовый класс и уметь работать с объектом базового класса.

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

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

Динамический тип в С? О чем ты?

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

Все функции в dll описываются в хидере.

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

E__>Легко.

Ну расскажи, как это сделать в один проход.

E__>То есть, есть инструкция вызова метода а класса Б, количество и тип передаваемых параметров известны, тип возвращаемого значения тоже.

Откуда они известны, если у тебя ровно один проход?

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

E__>Способен, еще и как.

Нет.

E__> Технически — не проблема.

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

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

N>Это я к тому, что рассказывая про страшные цифры, каждый должен знать, что именно эта цифра отражает. Если это объём виртуальной памяти процесса, то это вообще ничего не значит.

Не значит только пока ее хватает. А потом начинает значит со страшной силой. Но я тебе больше скажу — объем даже реально используемой физической памяти тоже нифига не значит, пока ее хватает.

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

PD>>> Для С++ почему ? Он вообще не менялся 10 лет
НС>>Язык потому что сложнее.
PD>Сложнее, чем Borland C++ 5.5 ? C++ с тех пор и вплоть до VS2008 включительно вообще не менялся. А BC5.5 работал на машине с 32 Мб памяти.

Оставлю, например, это здесь:
http://en.wikipedia.org/wiki/Compiler_optimization
http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860
http://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/loops.pdf

Но без шансов на понимание.

Помнится, еще в конце 90-х начале 00-х для получения максимальной производительности (например в играх) рекомендовалось делать ассемблерные вставки. Уже где-то с 2003-го рекомендации поменялись на «не заниматься такой фигней, сложно тягаться с компилятором по эффективности генерируемого кода».

Можно было бы, например, посмотреть описание оптимизаций, доступных в GCC, компиляторах Intel'я или Microsoft'а. Но зачем? Это же все магия, доступная в виде гномиков, которые позволят это все делать быстро и незаметно — ну как в Паскале, в пределах 1 мегабайта!

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

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

PD>>>> Для С++ почему ? Он вообще не менялся 10 лет
НС>>>Язык потому что сложнее.
PD>>Сложнее, чем Borland C++ 5.5 ? C++ с тех пор и вплоть до VS2008 включительно вообще не менялся. А BC5.5 работал на машине с 32 Мб памяти.

M>Оставлю, например, это здесь:
M>http://en.wikipedia.org/wiki/Compiler_optimization
M>http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860
M>http://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/loops.pdf

M>Но без шансов на понимание.

M>Помнится, еще в конце 90-х начале 00-х для получения максимальной производительности (например в играх) рекомендовалось делать ассемблерные вставки. Уже где-то с 2003-го рекомендации поменялись на «не заниматься такой фигней, сложно тягаться с компилятором по эффективности генерируемого кода».

M>Можно было бы, например, посмотреть описание оптимизаций, доступных в GCC, компиляторах Intel'я или Microsoft'а. Но зачем? Это же все магия, доступная в виде гномиков, которые позволят это все делать быстро и незаметно — ну как в Паскале, в пределах 1 мегабайта!

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

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

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

CL>а в том проекте на делфе, который вы конвертировали, использовался делфячий RTTI?
CL>металкассы?

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

CL>case в записях?

Или я что-то не понял, но ИМХО это добро было еще в TurboPascal.

CL>директива absolute?

Может, я опять не понял, но описание переменной с absolute было еще опять же в TurboPascal. Мы таким образом к видеобуферу добирались в MS-DOS

var
VideoBuffer: Pointer absolute $b800:$0000; // пишу по памяти, так что сорри, если не совсем так

Кроме того, в 1999 году под Delphi 5 я участвовал в проекте, где были (мы их сами использовали)

метаклассы
виртуальные конструкторы

Насчет "делфячая диспетчеризация сообщений" — не в курсе, о чем речь идет. Сообщения Windows и их обработка в Delphi ? Если да — конечно была, там был серьезный GUI. Если что-то иное — значит, я не в курсе.

CL>строки в качестве буфера?

Это просто не понял. AnsiString были, конечно.

Машина 1999 года — Pentium -1, 166 MHz, 32 Mb.

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

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

Описанные мной политики glibc это случай 64 бит. Мне сложно себе представить, чем там исчерпать виртуальные адреса.
Аналогично, стартовые затраты типа 100MB, если это просто адресное пространство — фигня даже в 32 битах.

НС> Но я тебе больше скажу — объем даже реально используемой физической памяти тоже нифига не значит, пока ее хватает.

Это несерьёзная постановка вопроса. Реально используемая физическая (она же резидентная) память, в отличие от собственной виртуальной процесса, отжирает место и у других процессов, и у кэшей.

M>>Оставлю, например, это здесь:
M>>http://en.wikipedia.org/wiki/Compiler_optimization
M>>http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860
M>>http://www.cs.princeton.edu/courses/archive/spr03/cs320/notes/loops.pdf

M>>Но без шансов на понимание.

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

Плевать. Можешь использовать эти ссылки на ответ на любой твой «ах, пачиму канпилятар паскаля работаит в 1 Мб, а саврименныи канпиляторы С++ ни умеют».

Современный C++ даже Edit & Continue уже умеет. Но это достигается искючительно магией, ага.

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

НС>В каком смысле не переплюнул?

В смысле организации метаинформации. Я ее когда-то давно ковырял — очень эффективно можно заливаеть в память нужную область файла целиком (АПИ модуля) и потом только индексы расставлять.

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

НС>С — не особо долго. Медленнее ТурбоПаскаля

Медленне раз в 10-20 для программ в десяток тыщ строк. Для более больших — еще больше разница. Успел покомпилять на IBM XT...

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

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

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

[...]

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

Проблема в том, что компиляция в debug (с выключенными оптимизациями) или в release — это не два разных компилятора. Это один и тот же, у которого строится одинаковое дерево разбора, но в случае release сборки на него напускается значительно больше разных действий. По крайней мере так у gcc, clang и тех, кого я хоть как-то рассматривал в деталях.
Поэтому те замеченные тобой 15-25MB (даже если у них заметная часть это аллоцированная, но не закоммиченная память) это результат разбора совсем другими технологиями, чем те, что использовались во времена одномегабайтных машин. Да, это цена за возможность использования тех средств, которые ты в случае debug не используешь.

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

N>Проблема в том, что компиляция в debug (с выключенными оптимизациями) или в release — это не два разных компилятора. Это один и тот же, у которого строится одинаковое дерево разбора, но в случае release сборки на него напускается значительно больше разных действий. По крайней мере так у gcc, clang и тех, кого я хоть как-то рассматривал в деталях.
N>Поэтому те замеченные тобой 15-25MB (даже если у них заметная часть это аллоцированная, но не закоммиченная память)

Это Working set, а сколько там аллоцировано и закомичено — я не смотрел. Надо полагать, больше. Сейчас проверить не могу.

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

N>>Проблема в том, что компиляция в debug (с выключенными оптимизациями) или в release — это не два разных компилятора. Это один и тот же, у которого строится одинаковое дерево разбора, но в случае release сборки на него напускается значительно больше разных действий. По крайней мере так у gcc, clang и тех, кого я хоть как-то рассматривал в деталях.
N>>Поэтому те замеченные тобой 15-25MB (даже если у них заметная часть это аллоцированная, но не закоммиченная память)

PD>Это Working set, а сколько там аллоцировано и закомичено — я не смотрел. Надо полагать, больше. Сейчас проверить не могу.

"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.

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

N>"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.

Это не абстракция. Это совершенно четкий параметр : количество страниц процесса, находящееся в данный момент в ОП.

Эти данные можно получить даже в юзермоде.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684946(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684949(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683478(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683239(v=vs.85).aspx

Подробности — у Соломона-Руссиновича.

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

N>>"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.
PD>Это не абстракция. Это совершенно четкий параметр : количество страниц процесса, находящееся в данный момент в ОП.

А. То есть это resident set. А не какой-то абстрактный working set.

PD>Подробности — у Соломона-Руссиновича.

Я, конечно, понимаю стремление MS всё обозвать по-своему, но потом приходится бороться с последствиями этого.

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

N>А. То есть это resident set. А не какой-то абстрактный working set.

Называй как хочешь. Я привык к понятию working set (рабочее множество, рабочий набор).

N>Я, конечно, понимаю стремление MS всё обозвать по-своему, но потом приходится бороться с последствиями этого.

Вот тут ты не прав. Я этот термин знал раньше, чем узнал о существовании MS

. Вроде как здесь прочитал

Дейтел Г. Введение в операционные системы. М.: Мир. 1987.

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

См. еще тут

http://cs.mipt.ru/docs/courses/osstud/10/ch10.htm

N>>>"Working set" — это Обстракция. Это термин, который каждый понимает по-разному. Я бы его не использовал.
PD>>Это не абстракция. Это совершенно четкий параметр : количество страниц процесса, находящееся в данный момент в ОП.

N>А. То есть это resident set. А не какой-то абстрактный working set.

Заметь, как всего за 2 сообщения он легко и изящно ушел с обсуждаемой темы. А ты повелся. Аяяяй

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

N>А. То есть это resident set. А не какой-то абстрактный working set.
Термин Working Set это устоявшийся термин, если чо.

... << RSDN@Home>>

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

N>>А. То есть это resident set. А не какой-то абстрактный working set.
M>Заметь, как всего за 2 сообщения он легко и изящно ушел с обсуждаемой темы. А ты повелся. Аяяяй

Щас вернём!

... << RSDN@Home>>

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

НС>>Главное — он либо не зависит или слабо зависит от размера исходников, что раньше и было (зависимость < O(N)), либо зависит сильно, что сейчас встречается чаще. Причем бывают очень тяжелые случаи, типа вложенных лямбд в шарпе, для которых алгоритм без эвристик, емнип, O(N^4). В эпоху 1 мегабайта таких фич не было в промышленных языках.

PD>Объем данных N^4 ? Что за структуры такие ? Четырехмерные массивы строятся ?

Re: [5.0] Сильно тормозит на вложенных лямбдах

Вложенные лямбды + overload resolution потенциально могут давать экспоненциальную сложность по времени и по памяти.

Re[3]: [Этюд, C#] Overload resolution

Кстати, интересно, что если лямбда содержит вложенные лямбды, то это процесс может вызываться рекурсивно. Я, кажется, когда-то приводил пример, когда это вызывает комбинаторный взрыв:
using System;

class Program
{
    static void Main()
    {
        Foo(a => Foo(b => Foo(c => Foo(d => Foo(e => Foo(f => Foo(g => Foo(h => a))))))));
    }

    static string Foo(Func<byte, byte> f) { return null; }
    static string Foo(Func<short, short> f) { return null; }
    static string Foo(Func<int, int> f) { return null; }
    static string Foo(Func<long, long> f) { return null; }
    static string Foo(Func<string, string> f) { return null; }
}

А вот другой пример, в котором программа в 62 байта напрягает компилятор шарпа так, что современный процессор жжет кислород около минуты
Re[6]: [Этюд, C#] Долгая компиляция

class X<A,B,C,D,E>{class Y:X<Y,Y,Y,Y,Y>{Y.Y.Y.Y.Y.Y.Y.Y.Y y;}}

PD>Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.

Вот последний пример, кроме долгой компиляции, порождает сборку размером почти в 28 Мб.

И, как уже сказали, паскаль из 90-х, который работал при 1 Мб и современный компилятор вещи отнюдь не аналогичные, у них сложность структуры обрабатываемых данных совершенно другого порядка.

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

А я на подобные "уводы" реагирую просто как на отсутствие ответа. У меня нет цели "зафиксировать" какое-то незнание или другое качество собеседника, и так понятно, какой результат.

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

CL>http://stackoverflow.com/questions/472906/net-string-to-byte-array-c-sharp

CL>И так повсюду: везде и всюду такты и байты расходуются ниначто, т.е. выделяется память там, где её выделять не нужно, и делается то, что делать не нужно.

Согласен, вопрос что делать и кому?

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

Я вполне допускаю, что на вложенных лямбдах все может сильно тормозить. Более того, если дело дойдет до LinQ, то тормозить уже может не только компилятор, а и рабочая программа, причем так, что и в кошмарном сне не приснится

http://rsdn.ru/forum/flame.comp/4098976.1.aspx

Только вот в С++ до VS2010 не было лямбд никаких вообще. В моей программе, о которой я говорил, что для ее трансляции нужно 15-25 Мб, их, естественно, тоже нет.

Так что с вложенными лямбдами пусть хоть экспонента по памяти. Почему без лямбд N^4 ?

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

N>>А. То есть это resident set. А не какой-то абстрактный working set.
PD>Называй как хочешь. Я привык к понятию working set (рабочее множество, рабочий набор).
N>>Я, конечно, понимаю стремление MS всё обозвать по-своему, но потом приходится бороться с последствиями этого.
PD>Вот тут ты не прав. Я этот термин знал раньше, чем узнал о существовании MS

. Вроде как здесь прочитал

В VMS, судя по рассказам её поклонников, это значит все аллоцированные страницы процесса. Что логичнее.
И отсутствие этого термина в современных Unix наводит на мысли, что от него избавились.

PD>Дейтел Г. Введение в операционные системы. М.: Мир. 1987.

Одного автора недостаточно.

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

PD>Я вполне допускаю, что на вложенных лямбдах все может сильно тормозить.

Я примеры привел не только с лямбдами, там еще есть дженерики.

PD>Более того, если дело дойдет до LinQ, то тормозить уже может не только компилятор, а и рабочая программа, причем так, что и в кошмарном сне не приснится

PD>http://rsdn.ru/forum/flame.comp/4098976.1.aspx

О да, помню, помню. Взять для примера крайне неоптимальную структуру данных, использовать неоптимальный алгоритм, а потом удивляться проседанию производительности на несколько порядков, в чем конечно же повинен только линк! Странно, что в том примере БД не использовали поверх WCF запущенной на каком-нибудь эмуляторе устройств в виртуальной машине в сетке с пингом до нескольких секунд и скоростью в 9600 бод!

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

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

) с тем, что в примере ниже 1 вариант понятен даже не напрягая извилины в отличие от второго, в котором желание автора кода еще нужно с уметь распарсить.

for (int i = 0; i < size; i++)
    a[i] = i + 1;
    
vs

var result = a.Aggregate(
    empty,
    (acc, res) =>
        acc.Count() == 0
            ? new[] { res }
            : acc.Concat(new[] { res + acc.Last() }));

Но это же не значит, что теперь линк не нужен, ибо вот пример, иллюстрирующий обратное, его не только писать быстрее, но и читать, что более важно:

var sum = 0
for (var i = 0; i < a.Length; i++)
    sum += a[i];
    
vs

var sum = a.Sum();

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

int cOwnSeen = 0;
for (item : items)
    if (item.owner != myself || cOwnSeen++ < limit)
        processItem(item);

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

Ну так вот, я отвлекся, по поводу использования линка. Он используется там, где его декларативность заруливает в минуса императив (верно и наоборот!). Вот здесь Игорь привел пример использования линка Re[10]: Давайте поговорим о c# 3.0. Оцени, код на линке почти в 4 раза меньше императивного, при этом, что очень важно, он понятен в отличие от своего императивного собрата, который даже в один экран не влезает.

PD>Только вот в С++ до VS2010 не было лямбд никаких вообще. В моей программе, о которой я говорил, что для ее трансляции нужно 15-25 Мб, их, естественно, тоже нет.

О какой программе идет речь, и где ты об этом говорил?

PD>Так что с вложенными лямбдами пусть хоть экспонента по памяти. Почему без лямбд N^4 ?

А где сказано, что без лямбд потребление памяти N^4? Я такого в тексте нигде не вижу. Про N^4 речь шла именно о вложенных лямбдах.
Re[13]: ответ на вопрос: Почему новые программы работают меделнно

Причем бывают очень тяжелые случаи, типа вложенных лямбд в шарпе, для которых алгоритм без эвристик, емнип, O(N^4).

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>Я вполне допускаю, что на вложенных лямбдах все может сильно тормозить. Более того, если дело дойдет до LinQ, то тормозить уже может не только компилятор, а и рабочая программа, причем так, что и в кошмарном сне не приснится

PD>http://rsdn.ru/forum/flame.comp/4098976.1.aspx

А Ikemefula то, как в воду глядел! Надо бы набросать здесь еще какой-нибудь дебильный код, чтобы на следующие два года был говно-пример.

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

MM>Надо бы набросать здесь еще какой-нибудь дебильный код, чтобы на следующие два года был говно-пример.
Лучше бы нормальный пример сразу приводили.
А то фиг вас знает, может вы там все именно так и пишете, а когда выяснилось что говнокод то стали оправдываться что это дескать шутка была.

... << RSDN@Home>>

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

R>О да, помню, помню. Взять для примера крайне неоптимальную структуру данных, использовать неоптимальный алгоритм, а потом удивляться проседанию производительности на несколько порядков, в чем конечно же повинен только линк! Странно, что в том примере БД не использовали поверх WCF запущенной на каком-нибудь эмуляторе устройств в виртуальной машине в сетке с пингом до нескольких секунд и скоростью в 9600 бод!

Нет. Там ниже по теме я задал вполне конкретный вопрос — что мне предпринять, чтобы гарантированно не попасть в эту ситуацию. Ответа на него не последовало. Можешь — дай его, пожалуйста. Нет — значит, что-то и впрямь неладно в Датском королевстве.

R>Неужели здравый смысл не подсказывает разобраться в том, что происходит на самом деле, прежде, чем набрасываться с обвинениями в чудовищно низкой производительности линка. Так как на чем ни реализуй алгоритм маляра Шлемиля, все равно в итоге будет получаться не эффективно. Там же по ссылке я переписал этот пример, заменив в нем только структуру данных, и в результате, буквально в одно мгновение, цифры уменьшились с нескольких порядков до 1.

Замечательно. Я и не утверждаю, что с линком нельзя написать более или менее неэффективно. Но вот без него написать столь неэффективно попросту нельзя. Поэтому еще раз задаю тот же вопрос.

R>Что касается использования самого линка, его, как и любую другую технологию или даже алгоритм, следует использовать там, где от него есть выгода. В твоем примере, от него нет никакой пользы, только вред, и не только в плане производительности, но и в понятности.

Пример не мой, его предложил кто-то, я лишь его протестировал.

R>Но это же не значит, что теперь линк не нужен, ибо вот пример, иллюстрирующий обратное, его не только писать быстрее, но и читать, что более важно:
R>

R>var sum = 0
R>for (var i = 0; i < a.Length; i++)
R>    sum += a[i];
    
R>vs

R>var sum = a.Sum();
R>

PD>>Только вот в С++ до VS2010 не было лямбд никаких вообще. В моей программе, о которой я говорил, что для ее трансляции нужно 15-25 Мб, их, естественно, тоже нет.

R>О какой программе идет речь, и где ты об этом говорил?

Да все о той же, для которой 15-25 Мб для компиляции требуется.

http://rsdn.ru/forum/flame.comp/4790728.1.aspx

PD>>Так что с вложенными лямбдами пусть хоть экспонента по памяти. Почему без лямбд N^4 ?

R>А где сказано, что без лямбд потребление памяти N^4? Я такого в тексте нигде не вижу. Про N^4 речь шла именно о вложенных лямбдах.

Ok, бог с ними, вложенными лямбдами. Без них — O(N^?) . Чему равен "?"

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

PD>>http://rsdn.ru/forum/flame.comp/4098976.1.aspx

MM>А Ikemefula то, как в воду глядел! Надо бы набросать здесь еще какой-нибудь дебильный код, чтобы на следующие два года был говно-пример.

Надо дать то, чего я еще тогда добивался и сейчас опять добиваюсь — правил, как избежать попадания в такую ситуацию. Иначе как мне узнать (без запуска) — дебильный будет код или нет ?
Для императивного кода в большинстве случаев можно сказать, что тут будет — O(N), O(NlgN), O(N^2), O(2^N)...
Вот и дай мне такой же способ оценить зависмость t=f(N) для линка. Тогда и вопросов не будет и дебильного кода тоже.

Читать так

Замечательно. Я и не утверждаю, что с линком нельзя написать более или менее эффективно.

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

Т>Лучше бы нормальный пример сразу приводили.
Да никто не стал бы использовать Linq. Какой нужно привести для этого пример?

Т>А то фиг вас знает, может вы там все именно так и пишете, а когда выяснилось что говнокод то стали оправдываться что это дескать шутка была.
Я в конце ветки объяснил, почему это был стеб изначально. Просто некоторым очень хочется убедить себя, что Linq — говно, вот они и видят то, что хотят.

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

Т>>Лучше бы нормальный пример сразу приводили.
MM>Да никто не стал бы использовать Linq. Какой нужно привести для этого пример?
Не надо было вообще писать того кода.

Т>>А то фиг вас знает, может вы там все именно так и пишете, а когда выяснилось что говнокод то стали оправдываться что это дескать шутка была.
MM>Я в конце ветки объяснил, почему это был стеб изначально.
Что было потом, никому уже не интересно. Народ ссылается на изначальное сообщение а там адЪ и угар.

MM>Просто некоторым очень хочется убедить себя, что Linq — говно, вот они и видят то, что хотят.
А он и есть говно, когда используется не к месту.
И именно пример такого использования был подогнан, но в ином контексте.
Теперь на него ссылаются.
Первый раз вижу чтоб так сами себя затроллили.

... << RSDN@Home>>

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

PD>Надо дать то, чего я еще тогда добивался и сейчас опять добиваюсь — правил, как избежать попадания в такую ситуацию. Иначе как мне узнать (без запуска) — дебильный будет код или нет ?
PD>Для императивного кода в большинстве случаев можно сказать, что тут будет — O(N), O(NlgN), O(N^2), O(2^N)...
А как ты это определяешь, сложность для императивного кода?

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

И охота тебе было. Все равно ж бесполезно.

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

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

PD>>Надо дать то, чего я еще тогда добивался и сейчас опять добиваюсь — правил, как избежать попадания в такую ситуацию. Иначе как мне узнать (без запуска) — дебильный будет код или нет ?
PD>>Для императивного кода в большинстве случаев можно сказать, что тут будет — O(N), O(NlgN), O(N^2), O(2^N)...
MM>А как ты это определяешь, сложность для императивного кода?

Не понял. Ты хочешь, чтобы я тебе лекцию прочитал о зависимости t=f(N) для разных алгоритмов, начиная с линейного поиска и кончая NP-полными задачами ? Так об этом столько понаписано...

Для той пресловутой задачи : линейный цикл, поэтому O(N).

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

PD>Не понял. Ты хочешь, чтобы я тебе лекцию прочитал о зависимости t=f(N) для разных алгоритмов, начиная с линейного поиска и кончая NP-полными задачами ? Так об этом столько понаписано...
Я хочу сказать, что оценка времени даже линейного цикла базируется на некотором знании о том, как этот цикл реализуется компилятором. То же самое и с Linq. Чтобы оценить сложность, нужно понимать, во что компилируются соответствующие методы. Как правило, имеем те же O(N). Более высокая сложность может получиться при наличии вложенных вызовов. В сущности, те же самые правила

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

PD>>Не понял. Ты хочешь, чтобы я тебе лекцию прочитал о зависимости t=f(N) для разных алгоритмов, начиная с линейного поиска и кончая NP-полными задачами ? Так об этом столько понаписано...
MM>Я хочу сказать, что оценка времени даже линейного цикла базируется на некотором знании о том, как этот цикл реализуется компилятором.

Никак не могу с этим согласиться. Компилятор, конечно, может реализовать его более или менее эффективно, но превратить его в двойной цикл он не сможет, если компилятор писали не идиоты (впрочем, сомневаюсь, что даже идиотам это удалось бы). Наоборот тоже. Зависимсть quicksort от N — NlgN, а умножения матриц — N^3, независимо от компилятора и даже (императивного) языка.

>То же самое и с Linq. Чтобы оценить сложность, нужно понимать, во что компилируются соответствующие методы. Как правило, имеем те же O(N). Более высокая сложность может получиться при наличии вложенных вызовов. В сущности, те же самые правила

Вот именно. Когда я вижу for(int i = 0; i < N; i++) я понимаю, во что это выльется, причем даже не обязан знать ассемблер. Тут как ни компилируй, а хуже O(N) быть не может. Как же мне определить , вот что выльется вызов Linq ? Более конкретно — что должно было броситься в глаза в том несчастном примере ? Что должно было сказать сразу — так писать категорически нельзя ? Каким правилам я должен следовать, чтобы такую чепуху не написать ?

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

PD>>Нет. Там ниже по теме я задал вполне конкретный вопрос — что мне предпринять, чтобы гарантированно не попасть в эту ситуацию. Ответа на него не последовало. Можешь — дай его, пожалуйста. Нет — значит, что-то и впрямь неладно в Датском королевстве.
MM>Гарантия такая же, как и во всем в программировании: наличие головы.

Это не ответ. Нужны какие-то правила, какие-то основания, чтобы эту голову применить. Для императивного кода они довольно просты — определите зависимость t=O(N) для вашего кода и подумайте, нельзя ли найти алгоритм с лучшей зависимостью. quicksort vs. bubble и т.д.

А здесь каким правилам следовать ?

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

Более тонкий вопрос. Предположим, написал я линейный цикл, и внутри тела цикла теперь ковыряюсь, меняя там одно на другое, но в двойной не превращаю. Я прекрасно понимаю, что этими изменениями я могу ускорить/замедлить работу в 5,10 раз, но не в N. Я совершенно уверен, что зависимость t=Cf(N) здесь не меняется, а меняется только C. Могу ли я быть уверенным в том, что изменяя linq-запрос я также не изменю вид этой зависимости ? А то ведь, чего доброго, добавишь один вызов — и на тебе!

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

PD>Нет. Там ниже по теме я задал вполне конкретный вопрос — что мне предпринять, чтобы гарантированно не попасть в эту ситуацию. Ответа на него не последовало. Можешь — дай его, пожалуйста. Нет — значит, что-то и впрямь неладно в Датском королевстве.

Тебе его не дали, потому как ответ очевиден. У тебя знания характеристик C++ врожденные? Нет. Гарантия как и везде — знание. Знаешь структуру данных, знаешь алгоритм, окружение — значит сможешь дать оценку.

R>>Неужели здравый смысл не подсказывает разобраться в том, что происходит на самом деле, прежде, чем набрасываться с обвинениями в чудовищно низкой производительности линка. Так как на чем ни реализуй алгоритм маляра Шлемиля, все равно в итоге будет получаться не эффективно. Там же по ссылке я переписал этот пример, заменив в нем только структуру данных, и в результате, буквально в одно мгновение, цифры уменьшились с нескольких порядков до 1.

PD>Замечательно. Я и не утверждаю, что с линком нельзя написать более или менее неэффективно. Но вот без него написать столь неэффективно попросту нельзя.

Да ну?! От отсутствия головы на плечах ни что не поможет. И потом, с чего вдруг эффективность стала определяться только скоростью выполняемой задачи? А как же читаемость? А где тестируемость? А что быть с временем, которое требуется для написания? А в разы меньшая цена внесения изменений — это эффективность или нет?

PD>Поэтому еще раз задаю тот же вопрос.

Ответ тот же самый.

PD>>>Так что с вложенными лямбдами пусть хоть экспонента по памяти. Почему без лямбд N^4 ?

R>>А где сказано, что без лямбд потребление памяти N^4? Я такого в тексте нигде не вижу. Про N^4 речь шла именно о вложенных лямбдах.

PD>Ok, бог с ними, вложенными лямбдами. Без них — O(N^?) . Чему равен "?"

Я вот все никак не пойму, откуда взялась формула O(N^?)? Сначала она была O(N^4), теперь вдруг O(N^?), хотя об этом никто и нигде не писал

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>>>Нет. Там ниже по теме я задал вполне конкретный вопрос — что мне предпринять, чтобы гарантированно не попасть в эту ситуацию. Ответа на него не последовало. Можешь — дай его, пожалуйста. Нет — значит, что-то и впрямь неладно в Датском королевстве.

MM>>Гарантия такая же, как и во всем в программировании: наличие головы.

PD>Это не ответ.

Нет, это ответ.

PD>Нужны какие-то правила, какие-то основания, чтобы эту голову применить.

Знание используемых алгоритмов и структур.

PD>Для императивного кода они довольно просты — определите зависимость t=O(N) для вашего кода и подумайте, нельзя ли найти алгоритм с лучшей зависимостью. quicksort vs. bubble и т.д.

Без знания используемых структур ничего они не просты. Не зная, чем отличается связный список от массива, или, например, что strlen(str) в C++ совсем не то же самое, что и str.Length в шарпе, ты не сможешь дать верную зависимость. Та же зависимость в quicksort на связном списке и массиве совсем не одно и то же.

PD>А здесь каким правилам следовать ?

Немного почитать про то, что собираешься использовать, нет?

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

Я тебе строчкой выше пример привел одного и того же кода, только в одном случае с чудовищниыми характеристиками, другой с более или менее терпимыми. Дай мне совет, чтобы я мог взглянуть на код и сказать — это пойдет, а так нельзя.

PD>Более тонкий вопрос. Предположим, написал я линейный цикл, и внутри тела цикла теперь ковыряюсь, меняя там одно на другое, но в двойной не превращаю. Я прекрасно понимаю, что этими изменениями я могу ускорить/замедлить работу в 5,10 раз, но не в N. Я совершенно уверен, что зависимость t=Cf(N) здесь не меняется, а меняется только C. Могу ли я быть уверенным в том, что изменяя linq-запрос я также не изменю вид этой зависимости ? А то ведь, чего доброго, добавишь один вызов — и на тебе!

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

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

R>>О какой программе идет речь, и где ты об этом говорил?

PD>Да все о той же, для которой 15-25 Мб для компиляции требуется.

PD>http://rsdn.ru/forum/flame.comp/4790728.1.aspx

Почему бы еще Turbo C++ 3.1 не вспомнить? Или всерьез считается, что в компиляторах с времен Borland C++ 5.5 ничего не изменилось?

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

>>То же самое и с Linq. Чтобы оценить сложность, нужно понимать, во что компилируются соответствующие методы. Как правило, имеем те же O(N). Более высокая сложность может получиться при наличии вложенных вызовов. В сущности, те же самые правила

PD>Вот именно. Когда я вижу for(int i = 0; i < N; i++) я понимаю, во что это выльется, причем даже не обязан знать ассемблер. Тут как ни компилируй, а хуже O(N) быть не может. Как же мне определить , вот что выльется вызов Linq ? Более конкретно — что должно было броситься в глаза в том несчастном примере ? Что должно было сказать сразу — так писать категорически нельзя ? Каким правилам я должен следовать, чтобы такую чепуху не написать ?

Например, правилам под названием мозг

var empty = Enumerable.Empty<int>();

        var result = a.Aggregate(
                    empty,
                    (acc, res) =>
                        acc.Count() == 0 ?
                          new[] { res }
                        : acc.Concat(new[] { res + acc.Last() }));

На что ты там жаловался? На то что аяяяй, при 3000 значениях медленно? Ну, никто и не будет гарантировать, что 3000*3=9000 вызовов методов и 3000*2=6000 выделений памяти будут работать быстро.

При том, что

for (int i = 0; i < size; i++)
            a[i] = i + 1;

почти наверняка будет заменено компилятором на весьма эффективные доступы к памяти или вообще на статически вычисленные значения.

О чем тебе уже было сказано, например, тут. Использование мозга в одном только месте даже этот кривой синтетический код разогнало в два раза.

Ну и повторю правдивые слова Ikemefula:

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

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

PD>>Нет. Там ниже по теме я задал вполне конкретный вопрос — что мне предпринять, чтобы гарантированно не попасть в эту ситуацию. Ответа на него не последовало. Можешь — дай его, пожалуйста. Нет — значит, что-то и впрямь неладно в Датском королевстве.

R>Тебе его не дали, потому как ответ очевиден. У тебя знания характеристик C++ врожденные? Нет. Гарантия как и везде — знание. Знаешь структуру данных, знаешь алгоритм, окружение — значит сможешь дать оценку.

Именно. Зная структуру данных и алгоритм, сделаю вывод. Увижу массив и линейный цикл — сделаю вывод, что O(N). На С++, Паскале, Фортране, Бейсике и т.д. От языка это не зависит.
Увижу linq вызов и... как определить ?

PD>>Замечательно. Я и не утверждаю, что с линком нельзя написать более или менее неэффективно. Но вот без него написать столь неэффективно попросту нельзя.

R>Да ну?!

Напиши в императивном стиле программу, которая вычисляет эти накопленные суммы со скоростью 15 сложений в секунду.

R>>>А где сказано, что без лямбд потребление памяти N^4? Я такого в тексте нигде не вижу. Про N^4 речь шла именно о вложенных лямбдах.

PD>>Ok, бог с ними, вложенными лямбдами. Без них — O(N^?) . Чему равен "?"

R>Я вот все никак не пойму, откуда взялась формула O(N^?)? Сначала она была O(N^4), теперь вдруг O(N^?), хотя об этом никто и нигде не писал

Странно, что ты не понял. Я задал вопрос — чему равен "?".

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

R>Без знания используемых структур ничего они не просты. Не зная, чем отличается связный список от массива, или, например, что strlen(str) в C++ совсем не то же самое, что и str.Length в шарпе, ты не сможешь дать верную зависимость. Та же зависимость в quicksort на связном списке и массиве совсем не одно и то же.

QuickSort на связном списке ? Ну-ну.

PD>>А здесь каким правилам следовать ?

R>Немного почитать про то, что собираешься использовать, нет?

Дай ссылку, где почитать. Только не общие сведения о линке, а конкретно — как определить O(N^?) для некоторого кода на линке и избежать того. что было в примере. Я уже давно этого добиваюсь, а в результате ничего.

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

Ответ простой. В принципе можно. Но добиться такрй чудовищной скорости — нет, не удастся.

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

M>На что ты там жаловался? На то что аяяяй, при 3000 значениях медленно? Ну, никто и не будет гарантировать, что 3000*3=9000 вызовов методов и 3000*2=6000 выделений памяти будут работать быстро.

Ты, часом, не на Спектруме до сих пор работешь ?

M>Был написан откровенно медленный код ради шутки — вместо цикла можно функциями все оформлять.

Я уже совсем тебя понимать перестал, да ты и сам, похоже, тоже. То ли это код для шутки, то ли и впрямь 9000 вызовов и 6000 выделений памяти должны работать минуты и часы. Ты уж с чем-то определись, а то совсем смешно получается.

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

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

НС>И охота тебе было. Все равно ж бесполезно.

К сожалению

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>Именно. Зная структуру данных и алгоритм, сделаю вывод. Увижу массив и линейный цикл — сделаю вывод, что O(N). На С++, Паскале, Фортране, Бейсике и т.д. От языка это не зависит.

PD>Увижу linq вызов и... как определить ?

В отношении линка что-то принципиально меняется?

PD>Напиши в императивном стиле программу, которая вычисляет эти накопленные суммы со скоростью 15 сложений в секунду.

Мне что-то принципиально этому мешает? Нет. Просто программу так никто не пишет, точно так же как не пишут и в декларативном. Или у нас программы написанные в императивном априори считается быстрыми?

Ну так вот, пожалуйста, программа более, чем в 300 раз медленнее, чем первоначальный нарочный пример на линке:

dtStart = DateTime.Now;
for (var i = 1; i < size; i++) {
        using (var connection = new OleDbConnection())
        using (var command = connection.CreateCommand()) {
                connection.ConnectionString = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\Northwind.mdb;User Id=admin;Password=;";
                connection.Open();
                command.CommandText = "select @f + @s as result";
                command.Parameters.Add("@f", OleDbType.Integer).Value = a[i];
                command.Parameters.Add("@s", OleDbType.Integer).Value = a[i-1];
                a[i] = Convert.ToInt32(command.ExecuteScalar());
        }
}
Console.WriteLine(DateTime.Now - dtStart);

Можно я этот пример буду использовать как демонстрацию ущербности императивного кода?

PD>Странно, что ты не понял. Я задал вопрос — чему равен "?".

Я все понял, я не понял откуда изначально взялась степень, ну т.е. вот это вот N^

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>Никак не могу с этим согласиться. Компилятор, конечно, может реализовать его более или менее эффективно, но превратить его в двойной цикл он не сможет, если компилятор писали не идиоты (впрочем, сомневаюсь, что даже идиотам это удалось бы). Наоборот тоже. Зависимсть quicksort от N — NlgN, а умножения матриц — N^3, независимо от компилятора и даже (императивного) языка.
Кстати, у нас уже был когда-то спор на эту тему. Человека, который пишет императивный код, ты считаешь человеком с мозгами. Он почему-то думает, как не надо написать, чтобы не получить квадратичную и более сложность. Человека, использующего Linq, ты почему-то считаешь кретином, который лепит все подряд конструкции, не задумываясь.

PD>Вот именно. Когда я вижу for(int i = 0; i < N; i++) я понимаю, во что это выльется, причем даже не обязан знать ассемблер. Тут как ни компилируй, а хуже O(N) быть не может. Как же мне определить , вот что выльется вызов Linq ? Более конкретно — что должно было броситься в глаза в том несчастном примере ? Что должно было сказать сразу — так писать категорически нельзя ? Каким правилам я должен следовать, чтобы такую чепуху не написать ?
Mamut уже написал, а я дополню.

В коде используется метод Aggregate, который

Applies an accumulator function over a sequence.

В описании его параметров написано, что лямбда

An accumulator function to be invoked on each element.

Таким образом, мы уже имеем линейную сложность.

Внутри лямбды используются Count и Last, которые по определению должны проходить всю коллекцию от начала и до конца.
Здесь сложность становится квадратичной.

Concat на оценку не повлияет, таким образом O(N^2).

Что должно отпугнуть? Наличие Count() и Last() на каждой итерации Aggregate. Но на самом деле, очевидная кривота Linq в решении таких задач просто потому, что он для них не предназначен. Им редко получается красиво кодировать алгоритмы, опирающиеся на индексный доступ к элементам.

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

MM>Что должно отпугнуть? Наличие Count() и Last() на каждой итерации Aggregate. Но на самом деле, очевидная кривота Linq в решении таких задач просто потому, что он для них не предназначен. Им редко получается красиво кодировать алгоритмы, опирающиеся на индексный доступ к элементам.
+1.

Зато элементарная возможность написать что-нибудь вроде:

var methods = _classType
    .GetMethods(BindingFlags.Public | BindingFlags.Static | BindingFlags.Instance)
    .Where(_ => string.IsNullOrEmpty(methodName) || methodName == _.Name)
    .Where(_ => _.HasAttribute<TestMethodAttribute>(true));

позволяет создать простой и понятный уму фильтр, в отличии от всовывания их внутрь цикла.

Более того, далее если нет необходимости — то список даже не материализуется:

if (!noShuffle)
{
    var temp = methods.ToList();
    temp.Shuffle();
    methods = temp;
}

foreach (var method in methods) // ...

В итоге код остаётся более чем понимаемым, предикат не вынесен в какие-то богом забытые методы.
И всё остаётся выглядеть очень "линейно".

Я только заради одного этого за существование и использования LINQ.
Ну а сколько он ещё даёт плюшек, тут уже писали...

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

R>Что касается использования самого линка, его, как и любую другую технологию или даже алгоритм, следует использовать там, где от него есть выгода. В твоем примере, от него нет никакой пользы, только вред, и не только в плане производительности, но и в понятности. Думаю никто не станет спорить (хотя, зная насколько человек бывает иррациональным, сильно не удивлюсь, ибо флеймы в КСВ это уже не раз доказывали

) с тем, что в примере ниже 1 вариант понятен даже не напрягая извилины в отличие от второго, в котором желание автора кода еще нужно с уметь распарсить.
Может я не так понял задачу, которую давал Павел, но у меня что-то совсем просто получилось на Linq:

IEnumerable<int> a = ...;

int p = 0;
a = a.Select(v => p = p + v);

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

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

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

форвард декларации всё так же обязателен, вывода типов параметров(для лямбд) нету, вывод типов для дженерик-аргументов практически не работает.

PD>На что мне метод для элементарного суммирования и зачем тут память 6000 раз выделять ?

Ну, когда ответишь на этот вопрос, тогда и поговорим.

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

MM>Может я не так понял задачу, которую давал Павел, но у меня что-то совсем просто получилось на Linq:
MM>

MM>IEnumerable<int> a = ...;

MM>int p = 0;
MM>a = a.Select(v => p = p + v);
MM>

Это инициализация массива, сам код вычисления такой

for (int i = 1; i < size; i++)
    a[i] += a[i - 1];

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>>Увижу linq вызов и... как определить ?

R>В отношении линка что-то принципиально меняется?

Ответь на вопрос — как определить по linq вид зависимости t=F(N). Ответишь — значит, ничего не меняется. А пока ответа нет — да. Потому что нет критерия, позволяющего определить, хороший это код на линк или нет.

Заметь, я уже в который раз прошу — дайте ответ. Простое, кащалось бы требование : дайте мне временнУю сложность алгоритма. В учебниках подробно разбирается.

А мне в ответ — что угодно, а вот эту зависимость никак дать не хотят.

<skipped>

R>Можно я этот пример буду использовать как демонстрацию ущербности императивного кода?

Нет. Когда говорят о работе с БД — появляются дополнительные факторы (скорость и протокол передачи, пул потоков, скорость работы HDD на стороне сервера , наличие индексов и т.д.). Давай останемся исключительно c работой в ОП.

PD>>Странно, что ты не понял. Я задал вопрос — чему равен "?".

R>Я все понял, я не понял откуда изначально взялась степень, ну т.е. вот это вот N^

Да просто так обычно пишут, N, N^2, N^3 и т.д. Общее место : каков алгоритм — линейный, квадратичный, кубический и т.д. ?

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

PD>>Никак не могу с этим согласиться. Компилятор, конечно, может реализовать его более или менее эффективно, но превратить его в двойной цикл он не сможет, если компилятор писали не идиоты (впрочем, сомневаюсь, что даже идиотам это удалось бы). Наоборот тоже. Зависимсть quicksort от N — NlgN, а умножения матриц — N^3, независимо от компилятора и даже (императивного) языка.
MM>Кстати, у нас уже был когда-то спор на эту тему. Человека, который пишет императивный код, ты считаешь человеком с мозгами. Он почему-то думает, как не надо написать, чтобы не получить квадратичную и более сложность. Человека, использующего Linq, ты почему-то считаешь кретином, который лепит все подряд конструкции, не задумываясь.

Передергивать не очень красиво. Я именно просил ответ, как писать хороший код на линке и как сделать так, чтобы этим кретином не быть. А в ответ — совет применить голову и т.д. На вопрос "как писать хороший императивный код" кроме рекомендации применить голову есть еще 100500 рекомендаций. А тут ни одной. Давай сюда рекомендации типа : вот такую конструкцию в такой-то ситуации применять можно, вот таких-то стоит избнгать и т.д. С объяснениями почему. А иначе — что мне делать, чтобы в роли этого кретина не оказаться ?

PD>>Вот именно. Когда я вижу for(int i = 0; i < N; i++) я понимаю, во что это выльется, причем даже не обязан знать ассемблер. Тут как ни компилируй, а хуже O(N) быть не может. Как же мне определить , вот что выльется вызов Linq ? Более конкретно — что должно было броситься в глаза в том несчастном примере ? Что должно было сказать сразу — так писать категорически нельзя ? Каким правилам я должен следовать, чтобы такую чепуху не написать ?
MM>Mamut уже написал, а я дополню.

MM>В коде используется метод Aggregate, который
MM>

Applies an accumulator function over a sequence.

MM>В описании его параметров написано, что лямбда
MM>

An accumulator function to be invoked on each element.

MM>Таким образом, мы уже имеем линейную сложность.

MM>Внутри лямбды используются Count и Last, которые по определению должны проходить всю коллекцию от начала и до конца.
MM>Здесь сложность становится квадратичной.

MM>Concat на оценку не повлияет, таким образом O(N^2).

MM>Что должно отпугнуть? Наличие Count() и Last() на каждой итерации Aggregate. Но на самом деле, очевидная кривота Linq в решении таких задач просто потому, что он для них не предназначен. Им редко получается красиво кодировать алгоритмы, опирающиеся на индексный доступ к элементам.

С Мамутом спорить — дело бессмысленное, а тебе отвечу.

Если здесь O(N^2), то дело должно обстоять плохо по сравнению с O(N), но при размере массив в 3000 почти незаметно. Все равно, что сортировать этот массив хоть quicksort, хоть bubble, но 1 раз, конечно — оба проскочат за миллисекунды. Тут, похоже, не O(N^2), а O(2^N) или O(N!) образовалось : иначе такой чудовищной скорости просто не достигнуть. Вот в этом-то и беда. O(N^2) вместо O(N) — это рядовая студенческая ошибка, а вот O(2^N) — это уже совсем другое.

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

R>Это инициализация массива, сам код вычисления такой
R>for (int i = 1; i < size; i++)
R> a[i] += a[i — 1];
Угу. Именно этот код я и написал. Или предлагается менять исходный массив? Итератор такого в принципе не позволит сделать.

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

PD>>На что мне метод для элементарного суммирования и зачем тут память 6000 раз выделять ?

M>Ну, когда ответишь на этот вопрос, тогда и поговорим.

Ритори́ческий вопро́с — риторическая фигура, представляющая собой не ответ на вопрос, а утверждение. По сути, риторический вопрос — это вопрос, ответ на который не требуется или не ожидается в силу его крайней очевидности

http://ru.wikipedia.org/wiki/%D0%A0%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B2%D0%BE%D0%BF%D1%80%D0%BE%D1%81

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

PD>Да просто так обычно пишут, N, N^2, N^3 и т.д. Общее место : каков алгоритм — линейный, квадратичный, кубический и т.д. ?

Ну, вообще-то я знаю, что это такое. Я немного другое спрашивал, откуда она изначально появилась в твоем сообщений, что зависимость O(N^какой-то там степени)? Никто из твоих оппонентов такое не говорил, или я может что-то пропустил?

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

MM>Угу. Именно этот код я и написал. Или предлагается менять исходный массив? Итератор такого в принципе не позволит сделать.

Упс.

Смотрел по диагонали, извиняюсь

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>Я именно просил ответ, как писать хороший код на линке и как сделать так, чтобы этим кретином не быть. А в ответ — совет применить голову и т.д.

Отвечали, и не раз. Достаточно краткого знакомства. Можно начать с того, что такой IEnumerable. Последовательный доступ O(1), произвольный — O(N).

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

R>Ну, вообще-то я знаю, что это такое. Я немного другое спрашивал, откуда она изначально появилась в твоем сообщений, что зависимость O(N^какой-то там степени)? Никто из твоих оппонентов такое не говорил, или я может что-то пропустил?

Речь просто шла о том, что какая-то зависимость должна быть, объема данных от размера N (количество типов, или переменных, или что-то еще). Эта зависмость едва ли может быть лучше линейной (хранить-то типы и т.д. как минимум надо). Значит, O(N^x). Вот я и спрашивал — какой тут x ?

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

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

PD>>Я именно просил ответ, как писать хороший код на линке и как сделать так, чтобы этим кретином не быть. А в ответ — совет применить голову и т.д.

R>Отвечали, и не раз. Достаточно краткого знакомства. Можно начать с того, что такой IEnumerable. Последовательный доступ O(1), произвольный — O(N).

Это я, представь себе, знаю. Ты лучше скажи — O(чего именно) в том несчастном примере и почему ? Мне что-то краткое знакомство ответа не дает. Если тебе дает — объясни, на основе краткого (или даже не очень краткого) знакомства и расскажи, как этого избежать.

Примерно так.

Некий воображаемый студент приносит мне программу с пузырьковой сортировкой.
Я : пузырьковая соритровка в общем случае не есть хорошо. У нее зависимость O(N^2). (Далее объяснение почему это так). А вот есть быстрая сортировка, у нее O(NlgN)(Далее объяснение почему это так).
O(N^2) при достаточно больших N существенно хуже (Далее объяснение почему это так). Поэтому впредь используй быструю сортировку, если не хочешь просадки производительности без какой-то выгоды.

Вот и напиши примерно то же, в применении к LinQ.

Элементарной же вещи прошу : дайте ответ, как оценить временнУю сложность алгоритма , при реализации которого используется LinQ. Для императивного кода это всегда обычно делается. Загляните в форум "Алгоритмы", там почти любая задача обсуждается в том числе с точки зрения ее временнОй сложности. Конкретно, что именно будет при таком-то алгоритме. А тут — или молчание, или общие слова или объяснение, что, мол, последовательный доступ — это O(N)

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

PD>Передергивать не очень красиво. Я именно просил ответ, как писать хороший код на линке и как сделать так, чтобы этим кретином не быть. А в ответ — совет применить голову и т.д. На вопрос "как писать хороший императивный код" кроме рекомендации применить голову есть еще 100500 рекомендаций. А тут ни одной. Давай сюда рекомендации типа : вот такую конструкцию в такой-то ситуации применять можно, вот таких-то стоит избнгать и т.д. С объяснениями почему. А иначе — что мне делать, чтобы в роли этого кретина не оказаться ?
Я дал объяснение, почему код, который ты упорно не воспринимаешь, как шутку, неоптимален. Навскидку, все функции Linq линейны и условно делятся на три вида: с отложенным исполнением, с отложенным исполнением и созданием копии исходной коллекции, с немедленным исполнением. Этого достаточно, чтобы давать оценки.

PD>Если здесь O(N^2), то дело должно обстоять плохо по сравнению с O(N), но при размере массив в 3000 почти незаметно. Все равно, что сортировать этот массив хоть quicksort, хоть bubble, но 1 раз, конечно — оба проскочат за миллисекунды. Тут, похоже, не O(N^2), а O(2^N) или O(N!) образовалось : иначе такой чудовищной скорости просто не достигнуть. Вот в этом-то и беда. O(N^2) вместо O(N) — это рядовая студенческая ошибка, а вот O(2^N) — это уже совсем другое.
Прогнал прогу и получил следующие значения времени исполнения. Первое число — количество аргументов, второе — время работы ~~шутливого~~ужасного алгоритма в миллисекундах.
5 — 3
105 — 6
205 — 46
305 — 152
405 — 360
505 — 678
605 — 1166
705 — 1826
805 — 2717
905 — 3866
1005 — 5282
1105 — 7074
1205 — 9078
1305 — 11528
1405 — 14379
1505 — 17646
1605 — 21490
1705 — 25654
1805 — 30474
1905 — 35773
2005 — 41776
2105 — 48249
2205 — 55518
2305 — 63401
2405 — 71972
2505 — 81331
2605 — 91475
2705 — 102464
2805 — 114310
2905 — 126775
3005 — 139617
3105 — 154896
3205 — 169968
3305 — 186327
3405 — 204859
3505 — 225744

График выглядит вполне себе квадратично.

PD>Некий воображаемый студент приносит мне программу с пузырьковой сортировкой.
PD>Я : пузырьковая соритровка в общем случае не есть хорошо. У нее зависимость O(N^2). (Далее объяснение почему это так). А вот есть быстрая сортировка, у нее O(NlgN)(Далее объяснение почему это так).
PD>O(N^2) при достаточно больших N существенно хуже (Далее объяснение почему это так). Поэтому впредь используй быструю сортировку, если не хочешь просадки производительности без какой-то выгоды.

PD>Вот и напиши примерно то же, в применении к LinQ.

В коде используется метод Aggregate, который
Applies an accumulator function over a sequence.

В описании его параметров написано, что лямбда
An accumulator function to be invoked on each element.

Таким образом, мы уже имеем линейную сложность.

Внутри лямбды используются Count и Last, которые по определению должны проходить всю коллекцию от начала и до конца.
Здесь сложность становится квадратичной.

Concat на оценку не повлияет, таким образом O(N^2).

Это, господа, звиздец. Человек видит только то, что он хочет видеть.

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

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

PD>>Передергивать не очень красиво. Я именно просил ответ, как писать хороший код на линке и как сделать так, чтобы этим кретином не быть. А в ответ — совет применить голову и т.д. На вопрос "как писать хороший императивный код" кроме рекомендации применить голову есть еще 100500 рекомендаций. А тут ни одной. Давай сюда рекомендации типа : вот такую конструкцию в такой-то ситуации применять можно, вот таких-то стоит избнгать и т.д. С объяснениями почему. А иначе — что мне делать, чтобы в роли этого кретина не оказаться ?
MM>Я дал объяснение, почему код, который ты упорно не воспринимаешь, как шутку, неоптимален. Навскидку, все функции Linq линейны и условно делятся на три вида: с отложенным исполнением, с отложенным исполнением и созданием копии исходной коллекции, с немедленным исполнением. Этого достаточно, чтобы давать оценки.

PD>>Если здесь O(N^2), то дело должно обстоять плохо по сравнению с O(N), но при размере массив в 3000 почти незаметно. Все равно, что сортировать этот массив хоть quicksort, хоть bubble, но 1 раз, конечно — оба проскочат за миллисекунды. Тут, похоже, не O(N^2), а O(2^N) или O(N!) образовалось : иначе такой чудовищной скорости просто не достигнуть. Вот в этом-то и беда. O(N^2) вместо O(N) — это рядовая студенческая ошибка, а вот O(2^N) — это уже совсем другое.
MM>Прогнал прогу и получил следующие значения времени исполнения. Первое число — количество аргументов, второе — время работы ~~шутливого~~ужасного алгоритма в миллисекундах.
MM>5 — 3
MM>105 — 6
MM>205 — 46
MM>305 — 152
MM>405 — 360
MM>505 — 678
MM>605 — 1166
MM>705 — 1826
MM>805 — 2717
MM>905 — 3866
MM>1005 — 5282
MM>1105 — 7074
MM>1205 — 9078
MM>1305 — 11528
MM>1405 — 14379
MM>1505 — 17646
MM>1605 — 21490
MM>1705 — 25654
MM>1805 — 30474
MM>1905 — 35773
MM>2005 — 41776
MM>2105 — 48249
MM>2205 — 55518
MM>2305 — 63401
MM>2405 — 71972
MM>2505 — 81331
MM>2605 — 91475
MM>2705 — 102464
MM>2805 — 114310
MM>2905 — 126775
MM>3005 — 139617
MM>3105 — 154896
MM>3205 — 169968
MM>3305 — 186327
MM>3405 — 204859
MM>3505 — 225744

MM>График выглядит вполне себе квадратично.

Это не ответ. Нажал по ошибке Отправить, прежде чем написал его. Сейчас напишу ответ.

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

MM>Прогнал прогу и получил следующие значения времени исполнения. Первое число — количество аргументов, второе — время работы ~~шутливого~~ужасного алгоритма в миллисекундах.

Хм...

MM>105 — 6

Если 100 (примерно) — это 6, то при квадратичной зависимости 1000 должна быть в 10*10 == 100 раз больше, то есть 6* 100 == 600. А имеем

MM>1005 — 5282

А 3000 должно быть в 30*30 == 900 раз больше, то есть 6 * 900 == 5400. А имеем

MM>3005 — 139617

Не нравится, что я начал с 100 ? OK, начнем иначе

1005 — 5282

Следовательно, для 3000 должно быть в 3*3 == 9 раз больше, то есть примерно 45000 А имеем

MM>3005 — 139617

MM>График выглядит вполне себе квадратично.

Ничего себе квадратично!

Если квадратично, и взять за точку отсчета

1005 — 5282

то для 10000 должно быть в 100 раз больше, то есть 500 секунд. Запусти, завтра скажешь, когда закончилась. А может, не завтра

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

M>Это, господа, звиздец. Человек видит только то, что он хочет видеть.

Это воистину черт знает что. Арифметику вам повторять, господа. Если бы там была квадратичная зависимость, то была бы обычная неэффективность, вполне простительная для первокурсников, а не то, что там есть.

http://rsdn.ru/forum/flame.comp/4794784.1.aspx
http://rsdn.ru/forum/flame.comp/4794908.1.aspx

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

MM>График выглядит вполне себе квадратично.

А надо не смотреть на график невооружённым глазом, а подсчёты сделать. (Но вы ж сюда не на охоту ходите?)
Твои числа очень чётко описывают кубическую зависимость.

Например, в случае 305->152, 605->1166, 1205->9078, 2405->71972 соотношение между временами при росте количества элементов в 2 раза даёт рост времени почти ровно в 8 раз.
Аналогично для других измерений (например, 405, 1205, 3605 — рост времени близок к 3**3 == 27).

А вот теперь попробуйте все вместе таки объяснить коллеге Дворкину, откуда вроде бы в простом понятном вам всем Linq взялась ещё одна степень зависимости от N, так что она даже не квадратичная, как можно было ожидать.

N>А вот теперь попробуйте все вместе таки объяснить коллеге Дворкину, откуда вроде бы в простом понятном вам всем Linq взялась ещё одна степень зависимости от N, так что она даже не квадратичная, как можно было ожидать.

Уже описаны Aggregate и Count/Last

А еще есть Concat. НапримерКоторый сам по себе далеко не простой: http://stackoverflow.com/a/4239912, http://blogs.msdn.com/b/wesdyer/archive/2007/03/23/all-about-iterators.aspx (см. со слов "The results may be perhaps surprising"), так еще и с отложенным выполнением.

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

N>А надо не смотреть на график невооружённым глазом, а подсчёты сделать. (Но вы ж сюда не на охоту ходите?)
N>Твои числа очень чётко описывают кубическую зависимость.
Да, с графиком я затупил. Ожидал резкого скачка и, не увидев его, решил, что можно считать кривую примерно квадратичной. Я редко занимаюсь подобным анализом, если такое проканает за отмазку

N>А вот теперь попробуйте все вместе таки объяснить коллеге Дворкину, откуда вроде бы в простом понятном вам всем Linq взялась ещё одна степень зависимости от N, так что она даже не квадратичная, как можно было ожидать.
Не стоило мне Concat игнорировать. Его ленивость всё усложняет, что легко проверяется, если после Concat добавить ToArray. Сейчас занят, попозже попробую составить картину, почему так получается.

Кстати, я уже привел код, который решает исходную задачу и работает линейно, но его Павел почему-то проигнорировал.

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

N>А вот теперь попробуйте все вместе таки объяснить коллеге Дворкину, откуда вроде бы в простом понятном вам всем Linq взялась ещё одна степень зависимости от N, так что она даже не квадратичная, как можно было ожидать.
В-общем, что у нас получается. Откуда береться N^2 я уже объяснил. Теперь рассмотрим, что дает ленивость Concat-а. Concat складывает два итератора: сначала обходит все значения первого итератора, потом второго (заданного в качестве параметра). Второй итератор у нас неленивый, поэтому его можем не считать. Зато первый итератор, после второй итерации Aggregate, уже представляет собой Concat. Все последующие итерации Aggregate добавляют еще один Concat. В итоге, по сути мы получим цепочку из N-1 Concat-ов. Когда код считает Count или Last, N-1-й Concat запрашивает элемент у N-2-го Concat-а, идет вложенный вызов. Тот в свою очередь запрашивает значение у N-3-го Concat-а, тоже вложенно.

Поясню. Код Concat условно такой:

IEnumerable Concat(IEnumerable e1, IEnumerable e2)
{
  foreach (v1 in e1)
  {
    yield return v1;
  }
  foreach (v2 in e2)
  {
    yield return v2;
  }
}

Так вот, e1 у нас является Concat-ом, который внутри себя, в своем e1, имеет еще один Concat, и у того тоже Concat и т.д. Такое редко бывает в нормальных Linq запросах, потому что они, как правило, имеют вложенность операторов 3-4, и ей можно пренебречь. Здесь же мы получаем еще N вложенных вызовов. Получается, что данный код построил Linq, в котором число операторов зависит от длины исходного списка. И это добавляет еще одну степень в сложность.

Если ошибся, поправляйте, не стесняйтесь

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

MM> M>Только вот даром эта дешевость никому не нужна. Потому что все давно живут в эпоху юникода и s[0] == 'ö' уже не прокатит.

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

Видимо так и есть, раз вы не в курсе, что это работает и с юникодом

avalon 1.0rc3 build 428, zlib 1.2.3

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

НС> В каком смысле не переплюнул? Компилятор шарпа вполне сопоставим по перформансу с Дельфи последних версий, которые с лямбдами и выводом типов.

Где это в дельфях вывод типов?

avalon 1.0rc3 build 428, zlib 1.2.3

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

PD> PD>>А Object Pascal ?

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

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

Перегрузка операторов, продвинутые записи, перегружаемые свойства, перечислители встроенные и кастомные, анонимные методы, конструкторы/деструкторы классов, дженерики, атрибуты. Практически тот же???

avalon 1.0rc3 build 428, zlib 1.2.3

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

M> Ops>90% покрывает константность/константные ссылки. Остальное да, надо тратить время, продумывая поведение. Зато можно дешево if(s[0]=='a') s[0]='b';

M> Только вот даром эта дешевость никому не нужна. Потому что все давно живут в эпоху юникода и s[0] == 'ö' уже не прокатит.

Мамут забавный. Смотри, показываю один раз:

var s : UnicodeString; // WideString
begin

 s := '中文';

 if s[1] = '中' then
  s[1] := '文';

end;

В чем проблема-то? Строки с двухбайтовым символом, покрывают весь BMP. Строки с четырехбайтовым символом покрывают весь юникод вообще. Но достаточно и двухбайтового символа т.к. все что за BMP практически не используется.

avalon 1.0rc3 build 428, zlib 1.2.3

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

Возможно, ты и прав, но все эти отличия примерно те же, что и для ранней версии С++ (BC++ 2.0) vs версии времен BC++5.0.

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

PD>то для 10000 должно быть в 100 раз больше, то есть 500 секунд. Запусти, завтра скажешь, когда закончилась. А может, не завтра

Павел, будут ли комментарии к этому решению?

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

PD> Возможно, ты и прав, но все эти отличия примерно те же, что и для ранней версии С++ (BC++ 2.0) vs версии времен BC++5.0.

Мой интерес к сям пропал раньше, чем вышел BC++5.0

avalon 1.0rc3 build 428, zlib 1.2.3

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

M>> Только вот даром эта дешевость никому не нужна. Потому что все давно живут в эпоху юникода и s[0] == 'ö' уже не прокатит.

H>Мамут забавный. Смотри, показываю один раз:

Это ты забавный.

H>В чем проблема-то? Строки с двухбайтовым символом, покрывают весь BMP.

Ты лучше покажи, что будет, если ты попытаешься в строке "ёкарный трамвай" заменить s[0] таким методом. При том, что она набрана следующим образом:

$ echo 'ёкарный трамвай' | iconv -t utf-16be | hd
00000000 04 35 03 08 04 3a 04 30 04 40 04 3d 04 4b 04 39 |.5...:.0.@.=.K.9|
00000010 00 20 04 42 04 40 04 30 04 3c 04 32 04 30 04 39 |. .B.@.0.<.2.0.9|
00000020 00 0a |..|
00000022

и видимая тобой "ё" представляет сумму 0435 (е) и 0308 (две точки сверху).

Это я так тонко, не используя специальных терминов, намекнул на тему Normalization forms.

H>Строки с четырехбайтовым символом покрывают весь юникод вообще.

Нету в юникоде "двухбайтового символа" или "четырёхбайтового символа". Символ может быть хоть 20-байтовым, потому что состоит из базового кодового пункта и модификаторов.

А ты продолжаешь считать, что символ == кодовый пункт. Ну что ж, до первого столба.

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

n> Ты лучше покажи, что будет, если ты попытаешься в строке "ёкарный трамвай" заменить s[0] таким методом. При том, что она набрана следующим образом:

n> $ echo 'ёкарный трамвай' | iconv -t utf-16be | hd
n> 00000000 04 35 03 08 04 3a 04 30 04 40 04 3d 04 4b 04 39 |.5...:.0.@.=.K.9|
n> 00000010 00 20 04 42 04 40 04 30 04 3c 04 32 04 30 04 39 |. .B.@.0.<.2.0.9|
n> 00000020 00 0a |..|
n> 00000022

n> и видимая тобой "ё" представляет сумму 0435 (е) и 0308 (две точки сверху).

NormalizeString, а дальше, как обычно.

avalon 1.0rc3 build 428, zlib 1.2.3

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

H>NormalizeString, а дальше, как обычно.

Переупрощаешь. Нормализация может дать и несколько символов.
Именно посимвольные сравнения начинают терять смысл, остаются только поиски подстрок. А это дороже.

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

PD>Именно. Зная структуру данных и алгоритм, сделаю вывод. Увижу массив и линейный цикл — сделаю вывод, что O(N).
Не угадал. Дальше что?
Увидел не массив, а некую структуру CCustomList. Увидел не цикл, а некий вызов типа std::sort(). Какой будет O()?

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

n> H>NormalizeString, а дальше, как обычно.

n> Переупрощаешь. Нормализация может дать и несколько символов.
n> Именно посимвольные сравнения начинают терять смысл, остаются только поиски подстрок. А это дороже.

А тут речь не о поиске, а о модификации строки. Тут, вообще говоря, пофиг на нормализации и формы представления т.к. обсуждается мутабельность vs. иммутабельность. А с мутабельными строками можно ведь и группу символов заменить:

 s:='1234567890';
 Delete(s, 5, 3); // удаление трех символов с пятой позиции
 Insert('4321', s, 5); // вставка подстроки в пятую позицию

avalon 1.0rc3 build 428, zlib 1.2.3

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

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

PD>>то для 10000 должно быть в 100 раз больше, то есть 500 секунд. Запусти, завтра скажешь, когда закончилась. А может, не завтра

MM>Павел, будут ли комментарии к этому решению?

Что-то долго от тебя ответа не было. Я уж думал, что ты и впрямь запустил тот код при N == 10000, и он все еще работает

На то решение комментарий дам, здесь.

Я его пробовал. Работает вполне успешно. Я не сравнивал его по скорости с императивным.

Так что можно подвести итоги.

1. Я не отрицаю, что на LinQ можно написать код более или менее приемлемый. Глупо было бы это отрицать — если бы это было так, LinQ давно бы помер.
2. В то же время я вынужден констатировать, что на LinQ можно написать код, скорость работы которого категорически неприемлема.
3. Никаких критериев, позволяющих сказать, в каком случае скорость будет приемлемой, а в каком нет, я так и не услышал. Кроме совета использовать голову. Использовать голову, конечно, надо, только для императивного кода к этому прилагается еще обширная информация о временнОй сложности тех или иных алгоритмов.
4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.

Вот и все.

PD>1. Я не отрицаю, что на LinQ можно написать код более или менее приемлемый. Глупо было бы это отрицать — если бы это было так, LinQ давно бы помер.
PD>2. В то же время я вынужден констатировать, что на LinQ можно написать код, скорость работы которого категорически неприемлема.

Аналогично для С++, примеры кода тут были

PD>3. Никаких критериев, позволяющих сказать, в каком случае скорость будет приемлемой, а в каком нет, я так и не услышал. Кроме совета использовать голову. Использовать голову, конечно, надо, только для императивного кода к этому прилагается еще обширная информация о временнОй сложности тех или иных алгоритмов.
PD>4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.

Это звиздец. http://rsdn.ru/forum/flame.comp/4796524.1.aspx

Провалилась попытка у него. Нуну. Я же говорю, ты видишь ровно только то, что хочешь видеть.

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

Что-то мы давно с тобой не схватывались

PD>>Именно. Зная структуру данных и алгоритм, сделаю вывод. Увижу массив и линейный цикл — сделаю вывод, что O(N).
S>Не угадал. Дальше что?

Я вообще-то гаданиями не занимаюсь. Если ты хотел сказать, что бывают циклы, при которых массив проходится не весь — ты безусловно прав, но это тривиальность. Естественно, надо смотреть, как именно выглядит цикл и что там делается. Я же имел в виду линейный проход по всему линейному массиву, как нетрудно догадаться.

S>Увидел не массив, а некую структуру CCustomList. Увидел не цикл, а некий вызов типа std::sort(). Какой будет O()?

Антон, ну не стоит так уж. Если уж о sort речь пошла, то в его quicksort имплементации вообще не цикл, а рекурсия (можно и без нее, конечно), но это не помешало еще N лет назад оценить форму зависмости t= f(N)

. Аналитически определить, заметь. Что касается std::sort, то вопрос о ее временной зависимости можешь задать в форуме C++, там тебе сильно удивятся и посоветуют пройти заново основы.

Или можешь обратиться в форум "Алгоритмы", там для каждого второго топика обсуждается временнАя зависимость алгоритма от N. Там тебе все, что нужно, объяснят, а меня уволь.

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

PD>4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.
Я сразу утверждал, что код плох и объяснил, почему вменяемый разработчик не стал бы такое делать. На мой взгляд, одно это уже говорит, что оценка изначально плохого кода — дело неблагодарное. Но мы решили потратить время, ок. Да, я упустил из виду Concat, и что? Я не могу ошибаться? Ну, хорошо, я не имел право на ошибку (хотя, учитывая первое предложение, я бы не дал ей даже повода). Однако, Павел, ты разве требовал дать оценку? Не фига подобного. Изнальный вопрос был, какие правила. Теперь ты видишь, какие правила. Такие же, как и у императивного кода. Невнимание к Concat — это моя "студенческая" ошибка, не имеющая никакого отношения к теории.

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

PD>>4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.
M>Это звиздец. http://rsdn.ru/forum/flame.comp/4796524.1.aspx
M>Провалилась попытка у него. Нуну.

Ну да. Постфактум уже что-то объяснили — после того, как я нашёл, что именно надо объяснить.

M>Я же говорю, ты видишь ровно только то, что хочешь видеть.

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

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

PD>Я вообще-то гаданиями не занимаюсь.
Да ладно.
PD>Если ты хотел сказать, что бывают циклы, при которых массив проходится не весь — ты безусловно прав, но это тривиальность.
Я, естественно, хотел сказать, что за предположение о константности времени выполнения операции a[i] без проверки того, как реализован operator[] для этого a, нужно сразу же отправлять в астрологический колледж.

S>>Увидел не массив, а некую структуру CCustomList. Увидел не цикл, а некий вызов типа std::sort(). Какой будет O()?

PD>Антон, ну не стоит так уж. Если уж о sort речь пошла, то в его quicksort имплементации вообще не цикл,
Бонус за внимательность уходит в зал.
PD>а рекурсия (можно и без нее, конечно), но это не помешало еще N лет назад оценить форму зависмости t= f(N)

. Аналитически определить, заметь. Что касается std::sort, то вопрос о ее временной зависимости можешь задать в форуме C++, там тебе сильно удивятся и посоветуют пройти заново основы.
О, воинствующая некомпетентность на марше. На всякий случай напомню, что стандарт C++ описывает не "временную зависимость", а количество сравнений. Которое, кстати, может в плохих случаях достигать N^2.
А временная зависимость будет очень шибко зависеть от реализации компаратора и оператора [] классе скормленных в std::sort итераторов.
В частности, связный список будет сортироваться std::sort-ом вовсе не за O(NlogN). А не заглядывая в реализацию ССustomList ты никаких предположений о его внутреннем устройстве сделать не сможешь. Это тебе не C, где a[i] всегда равно i[a].

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

N>Ну да. Постфактум уже что-то объяснили — после того, как я нашёл, что именно надо объяснить.
Лично у меня, как и у многих других, просто не было желания тратить время на дальнейшее разбирательство в коде. Знаешь почему? Потому что было очевидно, что Павлу этого не надо. Вот когда ты включился, тогда появилась заинтересованность.

PD>3. Никаких критериев, позволяющих сказать, в каком случае скорость будет приемлемой, а в каком нет, я так и не услышал. Кроме совета использовать голову. Использовать голову, конечно, надо, только для императивного кода к этому прилагается еще обширная информация о временнОй сложности тех или иных алгоритмов.
PD>4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.

Ну и вдогонку, раз ты такой умный, а мы все такие тупые. Расскажи про сложность чего-нить типа


int v[] = { 1, 4, 5 };
std::shared_ptr<IEnumerable<int>> source(new Vector<int>(v, ARRAYSIZE(v)));

source->Aggregate(
    [](IEnumerable<int> *current, int value){
        if(current -> Count() == 0){
           int v1[] = {0};
           std::shared_ptr<IEnumerable<int>> source(new Vector<int>(v1, ARRAYSIZE(v1)));
           return source;
        } else {
           int v1[] = {value + current -> Last()};
           std::shared_ptr<IEnumerable<int>> source(new Vector<int>(v1, ARRAYSIZE(v1)));
           return current -> Concat(source);
        }
    }
);

Чистейший C++. Взято на основе тут. Код не обязательно 100% корректный, он здесь для определения уровня понимания.

PD>>>4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.
M>>Это звиздец. http://rsdn.ru/forum/flame.comp/4796524.1.aspx
M>>Провалилась попытка у него. Нуну.

N>Ну да. Постфактум уже что-то объяснили — после того, как я нашёл, что именно надо объяснить.

Что и где ты нашел?

M>>Я же говорю, ты видишь ровно только то, что хочешь видеть.

N>Интересно, зачем ты откровенно врёшь тогда, когда тривиально можно поднять всю ветку и увидеть связи и последовательность?
N>Думаешь, что никто не захочет мараться об твою ложь?

Поднимай и видь что хочешь.

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

У меня нет ни малейшего желания занииматься разбором твоей софистики. Ты прекрасно понимал, что речь там шла отнюдь не о случаях доступа через operator[],а о прямой индексации в стиле С, в противном случае мы имеем вызов функции operator[] внутри цикла, а это надо учитывать, если ее реализация не O(1). Равно как и все остальное. Суть выводов это никак не меняет.

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

PD>>4. Попытка определить временнУю сложность этого несчастного кода, сделанная тобой и Mamut (ты привел численные данные, а он попробовал дать некоторое обоснование) вполне провалилась.
MM>Я сразу утверждал, что код плох и объяснил, почему вменяемый разработчик не стал бы такое делать. На мой взгляд, одно это уже говорит, что оценка изначально плохого кода — дело неблагодарное. Но мы решили потратить время, ок. Да, я упустил из виду Concat, и что? Я не могу ошибаться? Ну, хорошо, я не имел право на ошибку (хотя, учитывая первое предложение, я бы не дал ей даже повода). Однако, Павел, ты разве требовал дать оценку? Не фига подобного. Изнальный вопрос был, какие правила. Теперь ты видишь, какие правила. Такие же, как и у императивного кода. Невнимание к Concat — это моя "студенческая" ошибка, не имеющая никакого отношения к теории.

Ну что же, все верно. Ошибку в укор тебе ставить не буду, конечно. Правда, тот факт, что ее никто не заметил , пока не было произведено сравнение с экспериментом, тоже кое о чем говорит...

В общем, могу согласиться, что какие-то правила, наверное, существуют. Плохо лишь то, что их толком сформулировать — получается плохо. Отсюда большой риск получить весьма (пусть не настолько, как в этом примере) неэффективный код. Если эти правила будут где-то внятно изложены, если любой учебник по LinQ будет их содержать, тогда, наверное, можно будет как-то иначе к этому относиться.

На этом свое участие в дискуссии заканчиваю.

PD>В общем, могу согласиться, что какие-то правила, наверное, существуют. Плохо лишь то, что их толком сформулировать — получается плохо.

Правила ровно одни: мозг.

Синклер тебе открытым текстом написал про тот же С++:

PD>Именно. Зная структуру данных и алгоритм, сделаю вывод. Увижу массив и линейный цикл — сделаю вывод, что O(N).
Не угадал. Дальше что?
Увидел не массив, а некую структуру CCustomList. Увидел не цикл, а некий вызов типа std::sort(). Какой будет O()?

Так же и тут. Ты видишь не цикл, а работу каких-то структур. Что ты решил сделать? Выключить мозг и что-то орать с пеной у рта.

PD>Отсюда большой риск получить весьма (пусть не настолько, как в этом примере) неэффективный код. Если эти правила будут где-то внятно изложены, если любой учебник по LinQ будет их содержать, тогда, наверное, можно будет как-то иначе к этому относиться.

Эти правила изложены в любом учебнике по алгоритмам. В частности — в секции «как определить сложность алгоритма». Но да, тебе же всегда все очевидно!!

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

PD>Ну что же, все верно. Ошибку в укор тебе ставить не буду, конечно. Правда, тот факт, что ее никто не заметил , пока не было произведено сравнение с экспериментом, тоже кое о чем говорит...

Не надо выдавать желаемое за действительное!

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

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

PD>У меня нет ни малейшего желания занииматься разбором твоей софистики. Ты прекрасно понимал, что речь там шла отнюдь не о случаях доступа через operator[],а о прямой индексации в стиле С, в противном случае мы имеем вызов функции operator[] внутри цикла, а это надо учитывать, если ее реализация не O(1). Равно как и все остальное. Суть выводов это никак не меняет.
Ну конечно же меняет. Я на всякий случай напомню, что "прямая индексация в стиле С" выглядит в С++ ровно так же, как и вызов функции operator[]. Поэтому без анализа того, что там за a, и что там за i, и что там за sort никаких выводов делать нельзя.
Более того, современные компиляторы достаточно умны, чтобы в вырожденных случаях вообще выкинуть весь этот цикл из программы, если это не влияет на семантику.

Ну так вот во всех современных языках программирования ситуация обстоит ровно так же: нужно понимать, что именно происходит, чтобы давать хоть какие-то априорные оценки временных характеристик.
Даже в ассемблере у тебя нет никаких гарантий, что банальный add не вызовет пейджинг, который будет стоить тебе не 2 такта, а 3-15 миллисекунд.
Поэтому взрослые люди не рассуждают о том, "как не сделать ошибок", а пользуются профайлером.
После нескольких месяцев, проведённых с профайлером в руках, даже ты, Павел, сможешь навскидку определять узкие места в Linq — выражениях.

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

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

N>>Ну да. Постфактум уже что-то объяснили — после того, как я нашёл, что именно надо объяснить.
MM>Лично у меня, как и у многих других, просто не было желания тратить время на дальнейшее разбирательство в коде. Знаешь почему? Потому что было очевидно, что Павлу этого не надо. Вот когда ты включился, тогда появилась заинтересованность.

Шорт побьери. Извини, но мне это тоже нужно (по крайней мере пока у меня нет никаких дел ни с дотнетом, ни с LINQ), так что категорически просю пардону за обманутые ожидания.

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

S>Ну так вот во всех современных языках программирования ситуация обстоит ровно так же: нужно понимать, что именно происходит, чтобы давать хоть какие-то априорные оценки временных характеристик.
S>Даже в ассемблере у тебя нет никаких гарантий, что банальный add не вызовет пейджинг, который будет стоить тебе не 2 такта, а 3-15 миллисекунд.
S>Поэтому взрослые люди не рассуждают о том, "как не сделать ошибок", а пользуются профайлером.

Я согласен с Павлом — ты тут гонишь софистику.
Потому что независимо от пользы профайлера (она, конечно, есть) предсказание того, что конкретный алгоритм потребует кубических затрат, помогает понять, пригоден он тут или нет. Факторы типа пейджинга могут ухудшить производительность в таких случаях, но не улучшить.

S>После нескольких месяцев, проведённых с профайлером в руках, даже ты, Павел, сможешь навскидку определять узкие места в Linq — выражениях.

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

S>>Ну так вот во всех современных языках программирования ситуация обстоит ровно так же: нужно понимать, что именно происходит, чтобы давать хоть какие-то априорные оценки временных характеристик.
S>>Даже в ассемблере у тебя нет никаких гарантий, что банальный add не вызовет пейджинг, который будет стоить тебе не 2 такта, а 3-15 миллисекунд.
S>>Поэтому взрослые люди не рассуждают о том, "как не сделать ошибок", а пользуются профайлером.

N>Я согласен с Павлом — ты тут гонишь софистику.
N>Потому что независимо от пользы профайлера (она, конечно, есть) предсказание того, что конкретный алгоритм потребует кубических затрат, помогает понять, пригоден он тут или нет. Факторы типа пейджинга могут ухудшить производительность в таких случаях, но не улучшить.

Да нет там никакой софистики.

Дворкин утверждает: я завсегда смогу одним взглядом взглянув на алгоритм, сказать его сложность.
Sinclair: да нифига ты не можешь, если точно не знаешь, что именно участвуетв алгоритме. Даже на простейших алгоритмах может оказаться, что ВНЕЗАПНО a[i] — это не доступ по индексу, а имеет экспоненциальную сложность, и любая оценка алгоритма летит побоку.

Дворкин, естественно, не желает этого понять. Ты, видать, тоже

Аналогично для примера с LINQ'ом. Даже по грубым прикидкам алгоритм квадратичный. Для точной оценки надо разбираться во всех участвуемых в алгоритме структурах. А что, это когда-то было по-другому для других языков/технологий?

Возбмем абсолютно аналогичный код на C++. Ты можешь утверждать, что там — линейная сложность? Или какая-либо сложность? Нет, конечно. Но да, во всем виноваты «неформализуемые подходы оценки LINQ'а»

N> Этот опыт в результате формализуем словами?

Эти правила изложены в любом учебнике по алгоритмам. В частности — в секции «как определить сложность алгоритма».

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

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

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

M>Да нет там никакой софистики.
M>Дворкин утверждает: я завсегда смогу одним взглядом взглянув на алгоритм, сказать его сложность.
M>Sinclair: да нифига ты не можешь, если точно не знаешь, что именно участвуетв алгоритме. Даже на простейших алгоритмах может оказаться, что ВНЕЗАПНО a[i] — это не доступ по индексу, а имеет экспоненциальную сложность, и любая оценка алгоритма летит побоку.

Ну да. А завтра туда свалится метеорит, и оно вообще перестанет работать.
Вы оба начали придумывать какие-то совершенно мифические ситуации, которые при нормальном проектировании не работают. В частности, если мы говорим о массиве, и нет безумной давки в памяти, то доступ к элементу массива как a[i] имеет сложность O(1). И оценки алгоритма должны исходить именно из этого: в пределах условий его применимости оценки, полученные на основании анализа алгоритма, должны быть адекватны тому, что происходит в реальности.
И применяемые средства должны быть такими, чтобы не было проблем по коду сделать анализ оценки затрат.

M>Дворкин, естественно, не желает этого понять. Ты, видать, тоже

Я могу понять, что кто-то работает в совершенно ненормальных условиях или ненормально использует имеющиеся средства. Например, для какой-нибудь сортировки в стиле qsort это тривиально получить, пытаясь просортировать в памяти объём данных, больший, чем объём оперативной памяти — вот тут начинается жесточайший пейджинг-своппинг и время растёт в тысячи раз. Но оценка такого будет уже не оценкой сложности алгоритма, а комплексной оценкой эффективности решения, что совсем другое. И вот вы путаете эти две оценки.

M>Возбмем абсолютно аналогичный код на C++. Ты можешь утверждать, что там — линейная сложность? Или какая-либо сложность? Нет, конечно. Но да, во всем виноваты «неформализуемые подходы оценки LINQ'а»

Я не знаю такой C++, извини. Приведи код на Python, Erlang или C, тогда я тебе расскажу про него.

N>> Этот опыт в результате формализуем словами?

M>

M>Эти правила изложены в любом учебнике по алгоритмам. В частности — в секции «как определить сложность алгоритма».

Эти правила из учебника надо проецировать на конкретные особенности реализации (или наоборот, кого на что). И я говорю именно о правилах такого проецирования, а не об азах из учебника. Для обычного императивного языка они известны. Для LINQ их надо описывать заново, и Павлу непонятно, как это делать и на основании чего.

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

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

M>>Да нет там никакой софистики.
M>>Дворкин утверждает: я завсегда смогу одним взглядом взглянув на алгоритм, сказать его сложность.
M>>Sinclair: да нифига ты не можешь, если точно не знаешь, что именно участвуетв алгоритме. Даже на простейших алгоритмах может оказаться, что ВНЕЗАПНО a[i] — это не доступ по индексу, а имеет экспоненциальную сложность, и любая оценка алгоритма летит побоку.

N>Ну да. А завтра туда свалится метеорит, и оно вообще перестанет работать.
N>Вы оба начали придумывать какие-то совершенно мифические ситуации, которые при нормальном проектировании не работают.

Не мы оба, а Дворкин, который поступил ваккурат с заветом Икемефулы: нести знамя шуточного кода как доказательство чего-то там на протяжении двух лет.

N>В частности, если мы говорим о массиве, и нет безумной давки в памяти, то доступ к элементу массива как a[i] имеет сложность O(1). И оценки алгоритма должны исходить именно из этого: в пределах условий его применимости оценки, полученные на основании анализа алгоритма, должны быть адекватны тому, что происходит в реальности.
N>И применяемые средства должны быть такими, чтобы не было проблем по коду сделать анализ оценки затрат.

Кто-то хоть слово говорит против этого? Цитаты, ссылки в студию. Более того, практически сразу про этот код было сказано: никто так не будет извращаться для написания суммы элементов в массиве.

M>>Дворкин, естественно, не желает этого понять. Ты, видать, тоже

N>Я могу понять, что кто-то работает в совершенно ненормальных условиях или ненормально использует имеющиеся средства. Например, для какой-нибудь сортировки в стиле qsort это тривиально получить, пытаясь просортировать в памяти объём данных, больший, чем объём оперативной памяти — вот тут начинается жесточайший пейджинг-своппинг и время растёт в тысячи раз. Но оценка такого будет уже не оценкой сложности алгоритма, а комплексной оценкой эффективности решения, что совсем другое. И вот вы путаете эти две оценки.

Нет, не путаем.

M>>Возбмем абсолютно аналогичный код на C++. Ты можешь утверждать, что там — линейная сложность? Или какая-либо сложность? Нет, конечно. Но да, во всем виноваты «неформализуемые подходы оценки LINQ'а»

N>Я не знаю такой C++, извини. Приведи код на Python, Erlang или C, тогда я тебе расскажу про него.

Обыкновенный C++

Только ВНЕЗАПНО для него уже нельзя так просто, с наскока, оценить сложность

N>>> Этот опыт в результате формализуем словами?

M>>

M>>Эти правила изложены в любом учебнике по алгоритмам. В частности — в секции «как определить сложность алгоритма».

N>Эти правила из учебника надо проецировать на конкретные особенности реализации (или наоборот, кого на что). И я говорю именно о правилах такого проецирования, а не об азах из учебника. Для обычного императивного языка они известны. Для LINQ их надо описывать заново, и Павлу непонятно, как это делать и на основании чего.

На основании мозга.

Дворкин утверждает, например:

Я и не утверждаю, что с линком нельзя написать более или менее эффективно. Но вот без него написать столь неэффективно попросту нельзя.

Нужны какие-то правила, какие-то основания, чтобы эту голову применить. Для императивного кода они довольно просты — определите зависимость t=O(N) для вашего кода и подумайте, нельзя ли найти алгоритм с лучшей зависимостью. quicksort vs. bubble и т.д.

А здесь каким правилам следовать ?

Абсолютно тем же правилам, что и при разборе сложности императивного кода, что до Дворкина и до тебя, видать, пытается донести Синклер. LINQ — это не какие-то новые магические алгоритмы, неизвестно, откуда взявшиеся. Это все те же алгоритмы, можно вон книжку Кормана взять почитать, если что

Подходы АБСОЛЮТНО те же самые, их даже не надо формализировать. О чем MxMsk сказал тоже практически сразу: http://rsdn.ru/forum/flame.comp/4793944.aspx

оценка времени даже линейного цикла базируется на некотором знании о том, как этот цикл реализуется компилятором. То же самое и с Linq. Чтобы оценить сложность, нужно понимать, во что компилируются соответствующие методы. Как правило, имеем те же O(N). Более высокая сложность может получиться при наличии вложенных вызовов. В сущности, те же самые правила

Дальше Дворкин пишет всякую ахинею типа:

http://rsdn.ru/forum/flame.comp/4794084.1.aspx
Автор: Pavel Dvorkin
Дата: 27.06.12

Когда я вижу for(int i = 0; i < N; i++) я понимаю, во что это выльется, причем даже не обязан знать ассемблер. Тут как ни компилируй, а хуже O(N) быть не может. Как же мне определить , вот что выльется вызов Linq ?

Против чего Синклер уже сказал, что что-то уверждать даже для простейших циклах можно лишь для простейших случаев. Как только ты заменяешь простой доступ по индексу в массиве на какую-то собственную структуру данных, все твои размышления об алгоритме летят в трубу. Не так ли? И уже надо изучать, что делает та самая структура, не? Иначе якобы O(N) выльется в O(N^2) на ровном месте.

Так почему же ни Дворкин ни ты не собираетесь использовать такой же подход к Linq'у? Ведь видно же, что используются структуры, сложнее, чем банальный for. Берешь, читаешь гугл на предмет этих структур и делаешь разумные предположения.

В частности: O(N^2) определяется сразу, используя абсолютно те же подходы, что и для императивного кода. С concat сложнее, но и по нему информация и понимание находятся.

Что именно тебе формализовать? Кормана? Необходимость использовать мозг? Необходимость исследования поведения структур на предмет их поведения? Что именно?

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

Ops>>>Точно, думать не нужно, главное клепать. Это случайно не твою программу для UPS на 800М недавно обсуждали?
MM>>Прикольно, что ты не отвечаешь за свои слова, да еще и размениваешься на такие беспонтовые уколы, пытаясь навесить на меня чужие ошибки.
Ops>Я не отвечаю за свои слова? Можно ссылку или цитату? Насчет уколов — извиняюсь, буду молча сносить.
Какая тебе нужна ссылка? Ты посмотри на разговор. Вбрасываешь одно за другим, тебе объясняют, почему это неверно, но ты признать этого не можешь, а продолжаешь набрасывать. Потому и не отвечаешь. Ляпнул и забыл.

MM>>Позиционируешь себя знатоком, а в итоге демонстрируешь неумение прочитать текст и углубиться в суть решений, принятых в менеджед языках.
Ops>Вообще-то текст я прочитал, но пока вижу преимущества иммутабельных строк в основном в защите от дурака, ленящегося писать const.
Ну правильно. Чего писать, что лажаешь, проще обозвать других дураками. На всякий случай, гений, при желании никто не запрещает тебе в managed использовать мутабельные строки. Взял StringBuilder и вперед — меняй сколько влезет.

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

N>Эти правила из учебника надо проецировать на конкретные особенности реализации (или наоборот, кого на что). И я говорю именно о правилах такого проецирования, а не об азах из учебника. Для обычного императивного языка они известны. Для LINQ их надо описывать заново, и Павлу непонятно, как это делать и на основании чего.
А знаешь, что интересно: Linq — это ведь имитация ФП. Linq — это императивный код, написанный на императивном C#. Так вот и получается, что оценка Linq — это оценка сложности императивного кода, и Павел должен был сам показать класс, а не ждать этого от других. Впрочем, весь этот спор очень типичен. Сначала, засчет шуточного примера, был создан мир, в котором Linq отстой, а потом было предложено доказать, что он не отстой. Жалею, что повелся на это в очередной раз.

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

PD>Возможно, ты и прав, но все эти отличия примерно те же, что и для ранней версии С++ (BC++ 2.0) vs версии времен BC++5.0.

Как минимум перегрузки сильно усложняют компилятор, а никаких изменений в этом плане между 2 и 5 версие борладовского С++ не было.

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

Ops>Вообще-то текст я прочитал, но пока вижу преимущества иммутабельных строк в основном в защите от дурака, ленящегося писать const.
У мутабельных строк есть огромное преимущество — их гораздо реже приходится копировать, и не надо синхронизовывать многопоточный доступ.
Дурак с const тут ни при чём — семантика const в принципе не позволяет выразить иммутабельность.
Простейшая штука — метод, получивший строку в начале исполнения, и выполнивший с ней некоторую проверку, хочет полагаться на то, что результат проверки не изменится. Никакими const этого добиться нельзя; придётся делать копию (которая скорее всего не нужна). Иммутабельную строку можно использовать в качестве ключа в коллекциях. Мутабельную — нельзя. И это только верхушка айсберга.

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

S>У иммутабельных строк есть огромное преимущество — их гораздо реже приходится копировать, и не надо синхронизовывать многопоточный доступ.
Очепятка.

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

CL>И так повсюду: везде и всюду такты и байты расходуются ниначто, т.е. выделяется память там, где её выделять не нужно, и делается то, что делать не нужно.

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

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

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

CL>>Это всё равно глупо, т.к. в большинстве случаев байты получают для скармливания алгоритмам хэширования/криптования или отправляются по сети, или в файл пишутся

НС>Переключаешься в unsafe и вперед, если уверен что получишь существенный выигрышь в перформансе.

In order for C# to compile unsafe code, the application must be compiled with /unsafe

Зарубят сразу — корпоративный код никто так компилировать не захочет.
Мне в своё время пришлось доказывать необходимость использования PInvoke.

Я заметил, что новые программы любят в интернеты лазит. А отзывчивость некоторых служб оставляет желать лучшего.

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

H>что делать
Плюсик топикстартеру поставить.

H>и кому?
Тебе

---------------------------

Ничего ты тут не сделаешь.

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

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

PD>Возможно, ты и прав, но все эти отличия примерно те же, что и для ранней версии С++ (BC++ 2.0) vs версии времен BC++5.0.

Не помню 2-й BC++, но даже во времена 5-го такого количества шаблонов, как сейчас, не было. Интересно, 5-й хотя бы одну библиотеку из буста скомпилирует?

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

Ф>

Ф>In order for C# to compile unsafe code, the application must be compiled with /unsafe

Ужась просто.

Ф>Зарубят сразу — корпоративный код никто так компилировать не захочет.

Вот прям так никто? У нас вот без проблем, была бы польза.

Ф>Мне в своё время пришлось доказывать необходимость использования PInvoke.

Твои и твоего работодателя личные проблемы.

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

S> Простейшая штука — метод, получивший строку в начале исполнения, и выполнивший с ней некоторую проверку, хочет полагаться на то, что результат проверки не изменится. Никакими const этого добиться нельзя; придётся делать копию (которая скорее всего не нужна). Иммутабельную строку можно использовать в качестве ключа в коллекциях. Мутабельную — нельзя. И это только верхушка айсберга.

 Var s : String;

 Procedure ЗлобныйМетодИзменяющийСтроку;
 Begin

  s[1] := '-'; // срабатывает copy-on-write

 End;

 Procedure StringProc(AString : String);
 Begin

  Assert(AString = '123456789'); // наша важная проверка

  ShowMessageFmt('%p', [Pointer(s)]); // посмотрим на адрес исходной строки
  ЗлобныйМетодИзменяющийСтроку;
  ShowMessageFmt('%p', [Pointer(s)]); // смотрим еще раз. адрес изменился. copy-on-write в действии

  Assert(AString = '123456789'); // но переданная в параметре строка не изменилась

 End;

Begin

 s := IntToStr(123456789);
 StringProc(s); // при передаче строки RefCount будет увеличен (копия строки не создается)

End;

Какие-такие копирования

avalon 1.0rc3 build 430, zlib 1.2.5

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

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

S>> Простейшая штука — метод, получивший строку в начале исполнения, и выполнивший с ней некоторую проверку, хочет полагаться на то, что результат проверки не изменится. Никакими const этого добиться нельзя; придётся делать копию (которая скорее всего не нужна). Иммутабельную строку можно использовать в качестве ключа в коллекциях. Мутабельную — нельзя. И это только верхушка айсберга.

H>Какие-такие копирования

Прекрасно. Вы только что продемонстрировали реализацию иммутабельной строки.

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

S> H>Какие-такие копирования

S> Прекрасно. Вы только что продемонстрировали реализацию иммутабельной строки.

Дык в дельфях иммутабельных нет. Есть возможность правильного приготовления мутабельных.

avalon 1.0rc3 build 430, zlib 1.2.5

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

S>> H>Какие-такие копирования

S>> Прекрасно. Вы только что продемонстрировали реализацию иммутабельной строки.
H>Дык в дельфях иммутабельных нет. Есть возможность правильного приготовления мутабельных.
Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?

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

f> H>Дык в дельфях иммутабельных нет. Есть возможность правильного приготовления мутабельных.

f> Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?

Нет, передать тоже можно по разному.

avalon 1.0rc3 build 430, zlib 1.2.5

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

f>> Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?
H>Нет, передать тоже можно по разному.
По разному можно очень много где, если очень захотеть.

Sinclair прав, твой пример показывает реализацию иммутабельных строк, хоть они из языка и видны как мутабельные.

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

f> H>Нет, передать тоже можно по разному.

f> По разному можно очень много где, если очень захотеть.

Очень захотеть? Вообще-то var один из обычных способов передачи параметра

И это будет та-же самая строка, а не пришейзвиздерукавстрингбилдер.

f> Sinclair прав, твой пример показывает реализацию иммутабельных строк, хоть они из языка и видны как мутабельные.

В дельфях нет иммутабельных строк.

avalon 1.0rc3 build 430, zlib 1.2.5

Здравствуйте, fddima, Вы писали:
F> Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?
Нет, она всегда иммутабельна.
При передаче "по ссылке" изменяется не строка, а значение ссылки.
Ровно ту же реализацию мы имеем в C#, но почему-то там никто не говорит о "мутабельности" строк.
Единственная разница — в контроле за временем жизни. В Delphi строки финализируются детерминистически на основе счётчика ссылок (это не приводит к традиционным для рефкаунта проблемам потому, что строка не может быть частью цикла ссылок). В шарпе — собираются сборщиком мусора.

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

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

f>> H>Нет, передать тоже можно по разному.

f>> По разному можно очень много где, если очень захотеть.

H>Очень захотеть? Вообще-то var один из обычных способов передачи параметра

И это будет та-же самая строка, а не пришейзвиздерукавстрингбилдер.
Нет, это будет совсем другая строка.

 Procedure ЗлобныйМетодИзменяющийСтроку(var arg:string);
 Begin
  arg[1] := '-'; // срабатывает copy-on-write
 End;

 Procedure StringProc(AString : String);
 var
   localString: String;
 Begin

  Assert(AString = '123456789'); // наша важная проверка
  localString = AString;
  ShowMessageFmt('%p', [Pointer(localString)]); // посмотрим на адрес исходной строки
  ЗлобныйМетодИзменяющийСтроку(localString);
  ShowMessageFmt('%p', [Pointer(localString)]); // смотрим еще раз. адрес изменился. То есть нам вернули совсем другую строку.
  Assert(AString = '123456789'); // но переданная в параметре строка не изменилась
  ShowMessageFmt('%p', [Pointer(AString)]); // как и её адрес
 End;
Begin

 StringProc(IntToStr(123456789)); 
End;

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

S> H>Очень захотеть? Вообще-то var один из обычных способов передачи параметра

И это будет та-же самая строка, а не пришейзвиздерукавстрингбилдер.

S> Нет, это будет совсем другая строка.

...

Имеется ввиду, что в StringProc её нужно передать как var

avalon 1.0rc3 build 430, zlib 1.2.5

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

H>Имеется ввиду, что в StringProc её нужно передать как var
Это понятно. И тем не менее, вернётся совсем другая строка.

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

S> H>Имеется ввиду, что в StringProc её нужно передать как var

S> Это понятно. И тем не менее, вернётся совсем другая строка.

В моем коде, где не создается копия строки (localString := AString), это будет та же самая строка.

avalon 1.0rc3 build 432, zlib 1.2.5

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

H>В моем коде, где не создается копия строки (localString := AString), это будет та же самая строка.

Оптимизация копирований при refCount == 1? Ничего принципиально интересного это не даёт. Поведение строки в дельфи абсолютно аналогично поведению строки в шарпе. Включая поведение при передаче параметра с var.

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

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

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

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

Ну мне, например, тоже интересно, как такая сильная зависимость возникает, и ради чего не идут на меньшую зависимость? Ну там невозможно в принципе, очень сложно, очень медленно и т. д...

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

S> H>В моем коде, где не создается копия строки (localString := AString), это будет та же самая строка.

S>

Оптимизация копирований при refCount == 1? Ничего принципиально интересного это не даёт.

Ну вот у меня в парсере, как раз такой случай. Строка для всевозможных обработок отдается на модификацию, и у неё всегда refCount = 1. Ненужного копирования не происходит.

S> Поведение строки в дельфи абсолютно аналогично поведению строки в шарпе. Включая поведение при передаче параметра с var.

В дельфях можно изменять строку, в шарпе нет.

avalon 1.0rc3 build 432, zlib 1.2.5

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

M>Современный C++ даже Edit & Continue уже умеет. Но это достигается искючительно магией, ага.

Зачем для этой фичи много памяти при компиляции?

M>>Современный C++ даже Edit & Continue уже умеет. Но это достигается искючительно магией, ага.

E>Зачем для этой фичи много памяти при компиляции?

Та кне только же для этой фичи

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

R>Кстати, интересно, что если лямбда содержит вложенные лямбды, то это процесс может вызываться рекурсивно. Я, кажется, когда-то приводил пример, когда это вызывает комбинаторный взрыв:
R>

R>using System;

R>class Program
R>{
R>    static void Main()
R>    {
R>        Foo(a => Foo(b => Foo(c => Foo(d => Foo(e => Foo(f => Foo(g => Foo(h => a))))))));
R>    }

R>    static string Foo(Func<byte, byte> f) { return null; }
R>    static string Foo(Func<short, short> f) { return null; }
R>    static string Foo(Func<int, int> f) { return null; }
R>    static string Foo(Func<long, long> f) { return null; }
R>    static string Foo(Func<string, string> f) { return null; }
R>}

R>[/q]

Во-первых, большое спасибо за конкретику. Это возвращает обсуждение в конкретное и конструктивное русло!

Во-вторых, Верно ли я понял, что N тут -- это "глубина вложенности лямбд"?
Если да, то я предлагаю обсудить прожорливость компиляторов, в случае кода, не содержащего рекурсивных лямбд...

Просто обсуждавшийся тут "однометровый паскаль" можно было осоо навёрнутой прогой уронить, ну и аналогичный "десятиметровый шарп" тоже бы тут падал, или взрывался бы, но это никак не повод на всех остальных программах хотеть 100 метров...

R>А вот другой пример, в котором программа в 62 байта напрягает компилятор шарпа так, что современный процессор жжет кислород около минуты
R>Re[6]: [Этюд, C#] Долгая компиляция
R>

class X<A,B,C,D,E>{class Y:X<Y,Y,Y,Y,Y>{Y.Y.Y.Y.Y.Y.Y.Y.Y y;}}

PD>>Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.

IMHO это всё никому не нужно. Компилятор мог бы просто падать и не плодить много метров мусора...

R>Вот последний пример, кроме долгой компиляции, порождает сборку размером почти в 28 Мб.

В-третьих, мне лично неочевидно, что для компиляции примера с Foo и лямбдами, нужно таки экспоненциальное время и память...

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

E>>Зачем для этой фичи много памяти при компиляции?

M>Так не только же для этой фичи

Дык зачем тогда приводить эту фичу качестве объяснения роста аппетитов компиляторов?

E>>>Зачем для этой фичи много памяти при компиляции?

M>>Так не только же для этой фичи

E>Дык зачем тогда приводить эту фичу качестве объяснения роста аппетитов компиляторов?

Ты думаешь, анализ и расставление меток для Edit&Continue даются даром?

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

E>>>>Зачем для этой фичи много памяти при компиляции?

M>Ты думаешь, анализ и расставление меток для Edit&Continue даются даром?

Заходим на второй круг?

Конкретно а метки и прочее я так думаю, что если приструнить оптимизатор + оставить прокладок в коде, то это не дороже чем .map файл сгенерить. что умели практически все компиляторы С и С++...

E>>>>>Зачем для этой фичи много памяти при компиляции?

M>>Ты думаешь, анализ и расставление меток для Edit&Continue даются даром?

E>Заходим на второй круг?

E>Конкретно а метки и прочее я так думаю, что если приструнить оптимизатор + оставить прокладок в коде, то это не дороже чем .map файл сгенерить. что умели практически все компиляторы С и С++...

Блин. это одна из фич компилятора. Которых много. То есть потребности компилятора растут не только из-за Edit&Continue.

E>Зачем для этой фичи много памяти при компиляции?

Так не только же для этой фичи

Блин. Это ад какой-то

Сейчас не удивлюсь, если ты повторишь мантру.

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

M>

E>>Зачем для этой фичи много памяти при компиляции?

M>Так не только же для этой фичи

M>Блин. Это ад какой-то

Попробуй как-то ПОНЯТНО объяснить, как конкретно эта фича увеличивает рабочее множество компилятора...

M>>Блин. Это ад какой-то

E>Попробуй как-то ПОНЯТНО объяснить, как конкретно эта фича увеличивает рабочее множество компилятора...

Ты считаешь, что анализ компилиркмого кода и расставление меток является операцией с нулевым оверхедом?

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

E>Ну мне, например, тоже интересно, как такая сильная зависимость возникает, и ради чего не идут на меньшую зависимость? Ну там невозможно в принципе, очень сложно, очень медленно и т. д...

Ссылку в топике дали.

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

НС>Ссылку в топике дали.

Ну, если не трудно, повтори? Я тот топик сильно не весь ещё прочёл... Или это уже в этом топике?

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

H>В чем проблема-то? Строки с двухбайтовым символом, покрывают весь BMP. Строки с четырехбайтовым символом покрывают весь юникод вообще. Но достаточно и двухбайтового символа т.к. все что за BMP практически не используется.

Во всяком случае найти символ, который не помещается в один двухбайт, и при этом критично трактовать его в коде, именно как символ (ну, там, разделители слов, однобуквенные пунктуаторы и т. п.)
Всё равно всякие морфемы и пунктуаторы в общем случае не символы. а строки, так что в чём конкретно запара я вообще в упор не рублю...

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

N>Переупрощаешь. Нормализация может дать и несколько символов.
N>Именно посимвольные сравнения начинают терять смысл, остаются только поиски подстрок. А это дороже.

Чушь таки это. Если речь идёт об операциях над буквами именно, словами там, текстовой информацией на естественном языке, как бы, то есть символы, которые логично трактовать, как символы. Это типа там скобки, пробелы, запятые и т. д.
А есть всё остальное логично трактовать именно, как строки. Зачем в тексте на русском уметь менять e на ё или наоборот я не понимаю. Я понимаю операци "убрать диакритику", но это просто и понятно делается. Берёшь список некашерных модификаторов и поэтому списку фильтруешь...

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

S>Я, естественно, хотел сказать, что за предположение о константности времени выполнения операции a[i] без проверки того, как реализован operator[] для этого a, нужно сразу же отправлять в астрологический колледж.

На мой вкус туда надо отправлять тех кто делает такие операторы медленными.
Как мне кажется у списка на указателях не должно быть []...

но речь тут не о том.
Функциональщина, не важно в форме линка или стл, хороша тем, что освобождает программиста от размышлений о процедурном аспекте. Но тем же она и плоха. В какой-то момент фокус не удаётся и фанат функциональщины получает ВНЕЗАПНО мегатормозной код...

Или ты думаешь на С++ нельзя родить аналога линка что ли? Конечно же можно. и оно так же будет работать со всеми теми же проблемами...

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

M>Чистейший C++. Взято на основе [url=http://code.google.com/p/cpplinq/source/browse/src/cppLinqUnitTest

Какая разница С++ или шарп? Речь же идёт о функциональщине против императивщины...

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

E>На мой вкус туда надо отправлять тех кто делает такие операторы медленными.
E>Как мне кажется у списка на указателях не должно быть []...

Это интересная концепция. Вы хотите, чтобы объём прикладного кода отражал сложность нижележащей операции, так что ли?
То есть если у нас периодически в коде встречается обращение к пятому элементу списка, вы хотите требовать от программиста писать

int item5;
T curr = list.head();
for(int i=0;i<5;i++)
  curr++;
item5 = curr.value();

вместо просто list[5]?

Простите, я с этим не согласен.

E>но речь тут не о том.
А о чём?
E>Функциональщина, не важно в форме линка или стл, хороша тем, что освобождает программиста от размышлений о процедурном аспекте. Но тем же она и плоха. В какой-то момент фокус не удаётся и фанат функциональщины получает ВНЕЗАПНО мегатормозной код...

Пока что тема зависимости этого эффекта от функциональщины не раскрыта. Фанат процедурности запросто может получить ВНЕЗАПНО мегатормозной код.
Просто потому, что таково свойство любой инкапсуляции — прятать подробности.
Вот, например, делаю я совершенно процедурный вызов connect(). И ВНЕЗАПНО получаю его за 300 секунд вместо 300 миллисекунд. В чём дело? Да я просто запустил его на машине без доступа во внешнюю сеть, и он побежал искать certificate revocation list, обламываясь по таймауту.
E>Или ты думаешь на С++ нельзя родить аналога линка что ли? Конечно же можно. и оно так же будет работать со всеми теми же проблемами...

Я думаю, что некоторые тут пытаются подменить тему.

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

S>Это интересная концепция. Вы хотите, чтобы объём прикладного кода отражал сложность нижележащей операции, так что ли?
Я не хочу, что бы меняли семантику, без изменения имени.
В частности я против перегрузки операторов В НЕОЧЕВИДНЫХ случаях.
operator[]( int ) -- 'nj оператор ПРЯМОЙ выборки.

Для непрямой выборки можно завести метод, например у Next можно иметь версию с параметром "скока раз от 0 до ..."
Тогда будет что-то вроде

list.head()->Next( 5 );

S>вместо просто list[5]?
Даже, если кто-то не в состоянии запрограммировать такие простые вещи, это не даёт права кому-то приписывать мне всякий бред. Даже если этот кто-то мой земляк.

S>Простите, я с этим не согласен.

Это всё от незнания STL

E>>Функциональщина, не важно в форме линка или стл, хороша тем, что освобождает программиста от размышлений о процедурном аспекте. Но тем же она и плоха. В какой-то момент фокус не удаётся и фанат функциональщины получает ВНЕЗАПНО мегатормозной код...

S>Пока что тема зависимости этого эффекта от функциональщины не раскрыта. Фанат процедурности запросто может получить ВНЕЗАПНО мегатормозной код.
Ну тутошние наезды на линк, на самом деле, являются наездами на то, что он функциональщина

E>>Или ты думаешь на С++ нельзя родить аналога линка что ли? Конечно же можно. и оно так же будет работать со всеми теми же проблемами...

S>Я думаю, что некоторые тут пытаются подменить тему.
Да, и эти "некоторые" -- ты

Здравствуйте, Erop, Вы писали:
S>>Это интересная концепция. Вы хотите, чтобы объём прикладного кода отражал сложность нижележащей операции, так что ли?
E>Я не хочу, что бы меняли семантику, без изменения имени.
E>В частности я против перегрузки операторов В НЕОЧЕВИДНЫХ случаях.
Ой-ой-ой. Так можно много чего запретить:

int count = 1;
assert((count << 2) == (count * 4)); // :)) 
assert((cout << 2) == (cout * 4)); //  :crash:

E>operator[]( int ) -- 'nj оператор ПРЯМОЙ выборки.

S>>Простите, я с этим не согласен.
E>Это всё от незнания STL

Нет, это от понимания того, что процедурность vs функциональность тут совершенно неважны. По виду программы гадать о её нефункциональных характеристиках нельзя. Можно было бы на гипотетическом языке реального времени, где система типов бы включала перформанс-характеристики.
На реально существующих — нельзя.

E>Ну тутошние наезды на линк, на самом деле, являются наездами на то, что он функциональщина

Тутошние наезды на линк преимущественно происходят от людей, которые не знают линк, но думают, что зато знают С++.
Как показывает практика, С++ такие люди тоже не знают.

E>Да, и эти "некоторые" -- ты

Это ещё почему? Вся прелесть в том, что критикуемый линк — нифига не функциональный. Linq to objects насквозь процедурен. Он не более функционален, чем С-шный qsort().

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

S>Это ещё почему? Вся прелесть в том, что критикуемый линк — нифига не функциональный. Linq to objects насквозь процедурен. Он не более функционален, чем С-шный qsort().

а что в нем(в линке) — НЕ функционального??? qsort реализует inplace сортировку, тут всё понятно, а в линком то что?

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

J>а что в нем(в линке) — НЕ функционального??? qsort реализует inplace сортировку, тут всё понятно, а в линком то что?
Я не понимаю ваш вопрос. Весь linq — это специальный способ записи вызова некоторых определённых императивных процедур.
Я могу сделать энергичную реализацию всех этих OrderBy и ThenBy; могу сделать её inplace.
Могу — не делать. Могу написать на C++ qsort таким образом, чтобы он был ленивым и не-inplace.

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

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

J>>а что в нем(в линке) — НЕ функционального??? qsort реализует inplace сортировку, тут всё понятно, а в линком то что?
S>Я не понимаю ваш вопрос. Весь linq — это специальный способ записи вызова некоторых определённых императивных процедур.
S>Я могу сделать энергичную реализацию всех этих OrderBy и ThenBy; могу сделать её inplace.
S>Могу — не делать. Могу написать на C++ qsort таким образом, чтобы он был ленивым и не-inplace.

под линком вы имеете в виду query syntax ??

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

J>под линком вы имеете в виду query syntax ??
конечно. Тут делаются сильные заявления про то, что на "императивных" языках синтаксис якобы позволяет "видеть сквозь код" без помоши профайлера, а "функциональный linq" якобы не позволяет. Я с ними спорю

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

S>Нет, это от понимания того, что процедурность vs функциональность тут совершенно неважны. По виду программы гадать о её нефункциональных характеристиках нельзя. Можно было бы на гипотетическом языке реального времени, где система типов бы включала перформанс-характеристики.
S>На реально существующих — нельзя.

Я, в целом, согласен, что гадать при программировании нельзя. Но у меня как-то получается таки ЗАНТЬ где какие асимптоты...

Про несогласие с тем, что нехорошо менять семантику без смены имени я не понял.
IMHO, ты привёл пример говнокода который как раз и иллюстрирует, что бездумное переопределение операторов ведёт в ад.
Кстати, в правильной С++ программе в глобальном пространстве имён cout'а нет, есть std::cout...

S>Как показывает практика, С++ такие люди тоже не знают.
Эта, отучаемся таки говорить за всех...

E>>Да, и эти "некоторые" -- ты

S>Это ещё почему? Вся прелесть в том, что критикуемый линк — нифига не функциональный. Linq to objects насквозь процедурен. Он не более функционален, чем С-шный qsort().

Чё? И в области запросов к БД тоже?

Ну чего нам про слов-то спорить? Фиг с ним, давай назовём это "декларативный стиль программирования" vs "процедурный"...

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

E>Про несогласие с тем, что нехорошо менять семантику без смены имени я не понял.
E>IMHO, ты привёл пример говнокода который как раз и иллюстрирует, что бездумное переопределение операторов ведёт в ад.
Ну, то есть говнокод начинается прямо со стандартной библиотеки, так?
E>Кстати, в правильной С++ программе в глобальном пространстве имён cout'а нет, есть std::cout...

И как это поможет?
E>Эта, отучаемся таки говорить за всех...

Я за конкретных говорю.

E>Чё? И в области запросов к БД тоже?

А в области запросов к БД он настолько же процедурен, насколько любая выбранная вами библиотека доступа к БД в С++.
Вот, скажем, DBLib, мир её праху. Происходит запрос, он уезжает в сервер, потом приезжает результат. Асимптотику тут гадать по С++ коду бесполезно.
Принципиально linq ничем не отличается — кроме статической валидации корректности запроса.
E>Ну чего нам про слов-то спорить? Фиг с ним, давай назовём это "декларативный стиль программирования" vs "процедурный"...

Ну так и не спорьте, делов-то.

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

S>Ну, то есть говнокод начинается прямо со стандартной библиотеки, так?
А есть сомнения, в том, что с++-потоки -- это говнокод?

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

Секрет же прост, потоки разработали очень давно, когда на С++ и писать толком не умели, и сам С++ многое не умел. Так что ничего удивительного, что библиотека, которая была написана без опыта и с тех пор 20 лет не развивалась -- говнокод

E>>Кстати, в правильной С++ программе в глобальном пространстве имён cout'а нет, есть std::cout...

S>И как это поможет?

Показанной тобой проблемы не будет. В std нет count, а в глобальном нет cout, если ты сам его не заведёшь, конечно...

S>Ну так и не спорьте, делов-то.
Так не надо глупости писать, что вот де мол и на С++ так тоже можно. Я ещё раз намекаю, что на С++ можно вобще полный аналог линка залудить, если очень хочется. Тока не делают так почему-то

Делают через STL-way

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

E>А есть сомнения, в том, что с++-потоки -- это говнокод?

Если честно — есть.
Ну, то есть претензии к ним

E>Как ты относишься к тамошнему виртуальному наследованию, например?
Плохо. Но оно явно там такое оттого, что в языке не было нормального разделения интерфейсов и реализаций, а также возможности делать external methods.
То есть с точки зрения пользователя библиотеки — всё отлично. А то, какие там ромбики внутрях — это вопрос вторичный.

E>А к "удобству" поддержки юникода?
E>А к невозможности использовать юникод в именах файлов?
E>Ну и т. д.
Это не вина потоков. Это проблема подхода в целом. Сказывается сишное прошлое плюсов, когда "строка" и "набор байтов" было одним и тем же.
Многие разработчики и посейчас так думают. Удивляются потом, почему lowercase строки в современных платформах такой медленный — по сравнению с bit-crinching на SSE3, напедаленным руками.

E>Показанной тобой проблемы не будет. В std нет count, а в глобальном нет cout, если ты сам его не заведёшь, конечно...

Проблема так и останется — неожиданная смена семантики оператора <<.
Я просто выбрал идентификаторы немножко тролльским способом, чтобы ярче показать эту "проблему".

А вообще, идея была в том, что способ перегрузки операторов для потоков в С++ — далеко не самая "некрасивая" часть. Как раз всё более-менее здорово. Плюс ещё и манипуляторы — тоже круто.
С арифметикой вообще всё достаточно интересно устроено.
С одной стороны, есть "чёрная магия", типа вычитания по оператору +.
С другой стороны, есть "белая магия", когда мы делаем удобные и очевидные вещи, типа прибавления целого к "указателю". Тут мы полностью сохраняем все особенности семантики типа a[i] == a + i == i + a == i[a] (последнее — по желанию)

С третьей стороны, есть "серая магия", когда мы перегружаем операторы логичным способом, но теряем часть эквивалентностей. Например, для матриц мы знаем, что a * b != b * a. И вообще, в целом у нас далеко не всегда есть гарантии типа (a — b) == a + (-1 * b) — скажем, даты можно вычитать (с получением timespan), но умножать дату на интегер не имеет смысла.

E>Так не надо глупости писать, что вот де мол и на С++ так тоже можно.
Я пишу не глупости, а очевидные вещи.

E>Я ещё раз намекаю, что на С++ можно вобще полный аналог линка залудить, если очень хочется. Тока не делают так почему-то

Делают через STL-way

По-всякому делают. Я же почему писал, что "критики на поверку и С++ не знают". Потому и писал, что на практике оказывается, что они знают только уютную маленькую область С++, в которой всё расположено привычным образом. А настоящий взрослый С++, с шаблонами, частичной специализацией, функторами, и прочим, никакими такими волшебными свойствами, которые ему приписывают (типа предсказуемости асимптотик) совершенно не обладает.
А в ответ на идею кастрировать С++ и запретить писать в "функциональном стиле" я выдвигаю симметричный ответ: на С# тоже можно отказаться от всей этой адской мощи и писать на комфортном подмножестве синтаксиса.

	От:	newCL
	Дата:	17.06.12 12:39
	Оценка:	+2 -2

От:	Mamut	http://dmitriid.com
Дата:	17.06.12 12:46
Оценка:	1 (1)

	От:	Pavel Dvorkin
	Дата:	17.06.12 13:22
	Оценка:	3 (1) +1

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

	От:	newCL
	Дата:	17.06.12 13:23
	Оценка:

От:	hardcase	http://nemerle.org
Дата:	17.06.12 19:57
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	18.06.12 05:54
Оценка:

	От:	Eugeny__
	Дата:	18.06.12 23:06
	Оценка:	1 (1) +1

	От:	Andrey.V.Lobanov
	Дата:	21.06.12 18:16
	Оценка:

	От:	Трололоша
	Дата:	22.06.12 01:23
	Оценка:

От:	мыщъх	http://nezumi-lab.org
Дата:	22.06.12 02:11
Оценка:	+1

От:	rameel	https://github.com/rsdn/CodeJam
Дата:	25.06.12 17:30
Оценка:	10 (5)

От:	henson	http://www.njt-rails.com
Дата:	26.06.12 01:01
Оценка:

	От:	MxMsk
	Дата:	27.06.12 13:42
	Оценка:	2 (1) +1 -3

От:	Sinclair	https://github.com/evilguest/
Дата:	29.06.12 06:54
Оценка:

	От:	Privalov
	Дата:	19.06.12 10:54
	Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	15.07.12 07:11
Оценка: