Re[2]: За что я не люблю С++ - Компьютерные священные войны

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

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

PD>>Выделено мной. Как еще можно понимать linearly looking, я не понимаю.
S>Очень жаль, что не понимаешь. Linearly looking вовсе не означает, что там есть цикл
S>

S>for(int i=HeapStart;i< HeapLength;i++)
S>  if (IsGarbage__heap[i]) 
S>    ...
S>

S>Объясняется идея одного из алгоритмов компактификации хипа. К моменту, когда начинается вот эта работа, уже известно, что мусор, а что — нет. И время работы этого алгоритма совершенно не зависит от количества строк, на которые больше нет ссылок.

Я до сих пор был уверен, что линейный просмотр есть линейный просмотр. Если есть другие алгоритмы линейного просмотра, давай их сюда. Пока что твое утверждение не опровергает Рихтера.

S>Ну, твоему коду, значит, повезло. Ему фреймворк не нужен — достаточно базовой арифметики (спасибо, что хотя бы она встроена в C++.

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

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

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

Но вообще-то С — подмножество С++. Ну пусть не совсем точное, но в основном да. Так что все, что говорилось про С++, можно отнести и к его подмножеству.

Дело в том, что есть программисты разного рода. Ты относишься к тем, для кого программирование — это вызов методов (сам признался), а я к тем, для кого программирование — это написание (методов, функций, процедур). Вот и вся разница

. Поэтому для меня все эти игры с геттерами, сеттерами, интерфейсами, паттернами и т.д. малоинтересны. Мне придумать надо, как сделать, а не как оформить. Придумаю — как-нибудь оформлю. А вот если не придумаю — нечего будет оформлять.

S>>>Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.
PD>>И да и нет. Для того, чтобы "видеть" за С++ конструкциями ассемблерные команды — да. Но этого я обычно и не делаю, разве что если меня вдруг удивит скорость некоторого фрагмента. А вот чтобы понимать, во что такая конструкция выльется — даже не обязательно знать асм.
S>Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"?

Просто примерно представить себе, что за код при этом получится. Это интуитивно, объяснить трудно.

>Асм, конечно, знать не обязательно.

Знать — обязательно, писать на нем — нет.

>Но обязательно знать то, во что "выливается" конструкция. К примеру, выливается ли она в доступ к файлу подкачки, и если выливается, то когда. Для понимания того, что выделение массива данных размером в 5GB для обработки неизбежно потребует работы с файлом подкачки ассемблер знать не обязательно.

Ну для этого сначала не мешает знать, что в Win32 это попросту невозможно

. В Win64 можно. А насчет того, что это обязательно выльется к обращениям к файлу подкачки — неверно. Зависит от объема ОП. И не забывай, что файл подкачки может быть вообще отключен

>Зато обязательно знать про архитектуру виртуальной памяти на той платформе, для которой ты пишешь — ну, чтобы вообще понимать, что такое файл подкачки.

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

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

PD>>Какими библиотеками ?
S>Любыми библиотеками.

Вопрос был риторический, пояснения даны были ниже.

PD>>Стандартная C RTL — да, используется, да, свою версию strcpy я не буду писать. Win32 — да, тоже, потому что я и не могу написать ее функции. Но про первую столько понаписано и столько сравнений проведено, и столько раз эта strcpy обсуждалась, что я знаю, чему тут можно верить. А поскольку основное время все же ест мой собственный код, то я над ним и полный хозяин.
S>Вопрос ровно в том, что такое "твой собственный код". Повторюсь: если этот код — это всего лишь арифметика, то ему просто повезло.

См. выше.

>Остальным, тем, кто не хочет, к примеру, педалить руками циклы в умножении матриц, хочется пользоваться библиотекой. И тут выясняется, что компилятор на диво умён — и иногда невинно выглядящие вещи (типа a*b) скрывают за собой холостое копирование килобайтов, а иногда наоборот — страшные навороты сворачиваются в очень компактный целевой код.

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

Если мне приспичит, и исходники есть, я могу за автора эту работу выполнить. В конце концов, и там код на С/С++, и здесь. Просто я своему коду доверяю, а тому — как знать. Сперва проверю на тестах.

S>И без профайлера выяснить это невозможно — я еще раз повторяю пример с ошибкой в MS STL, из-за которой у них там было огребание со строками.

А у меня не было проблем с char*

. И с string STL тоже не было — я ее не использовал.

PD>>Ушел от ответа. Никакого пользовательского ввода в этой задаче нет. А как все же исправить — неясно.
S>Я уже неоднократно слышу подобные гм-м, претензии, от профайлероненавистников.

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

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

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

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

?) и потом улучшать — как ?
2. Посидеть подумать, свести к 3-циклу и написать, после чего посмотреть с помощью профайлера, что там не совсем хорошо — может, к примеру, не лучшим образом внутренний оператор реализован.

Так как же лучше ? Ответишь или , как в случае, когда тебе сказать нечего, просто выкинешь этот вопрос ?

>Опять же — пример из далёкого тебе мира СУБД.

Ну-ну... Отнюдь не далекого, не говоря уж о том, что я свою псевдо-СУБД писал

>"Показ плана запроса" не скажет тебе, какие индексы нужно поставить, и какие агрегатные таблицы нужно создать. Но без просмотра плана запроса угадать способ ускорения практически невозможно. Точнее, опять же так: опытный DBA может "в уме" прикинуть план запроса, с учётом селективности тех или иных предикатов, и еще много чего. Но его опытность — не в чтении книжек Кайта и Дейта. А в том, что он гонял реальные запросы на реальных базах под профайлером, и многократно наблюдал как за тем, что делает оптимизатор, так и за тем, куда уходит производительность. Программерская интуиция — это всего лишь кэш для фактов; если ты не будешь получать факты, то никогда не научишься предсказывать производительность. Вот, к примеру, ты, со всем своим опытом разработки, совершенно бессилен представить себе тот факт, что "мёртвые" строки не влияют на производительность программы. И что большинство приходящих тебе в голову "оптимизаций" в C# или Java только ухудшат производительность. И это несмотря на то, что про это пишут во всех книжках. А вот если бы ты поработал над конкретной задачей с профайлером в руках, то накормил бы конвеер своего процессора фактами. И уже на их основе получил новую, улучшенную "интуицию", которая бы ошибалась гораздо реже.

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

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

PD>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
G>Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.

Все, моих педагогических способностей больше не хватает

. Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
вынести не в состоянии

G>Так в этом никто и не сомневается. Можно много всего делать, другой вопрос зачем и с какими затратами.

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

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

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

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

Ну не знаю. Рихтер о сортировке не пишет. Но если даже это так, то это все равно некие затраты. Да еще соритровка.

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

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

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

PD>>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
G>>Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.

PD>Все, моих педагогических способностей больше не хватает

. Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
PD>вынести не в состоянии

Ты сильно привязываешь к конкретной архитектуре процессора и ОС (наверное потому что в других не ориентируешься).
Иммутабельность никак от процессора не зависит. Например разрабатывая интерпретатор байткода иммутабельность типов языка поможет тебе выкинуть ненужные проверки в своем интерпретаторе.

G>>Так в этом никто и не сомневается. Можно много всего делать, другой вопрос зачем и с какими затратами.
PD>Ну слава тебе господи. Можно все же, оказывается. А насчет затрат — см. мой тест немного выше.
Какой тест?

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

PD>Впрочем, дело не в этом. Посмотри, из-за чего весь разговор начался. Дескать, выделение памяти в упроавлеямой куче очень быстрое — так Антон мне заявил. Я с этим и не спорю, но удаление их будет намного менее быстрым — вот и все.
Рихтер очень много пишет о достижимых объектах, поколениях информации о достижимых ссылках итд.
Влад в своей статье тоже неплохо все написал http://rsdn.ru/article/dotnet/GC.xml. На самом деле основная работа это поиск достижимых объектов. Если мы не касаемся объектов в старших поколениях а в 0 поколении нет достижимых объектов, то указатель кучи просто сдвигается на ее начало. На самом деле очень много ньюансов где ГС очень хорош, а где и проседает по полной. Смотри в этой же статье насет врайт барьера, а так же не дефрагментируемые Лохи (старый опыт) итд. Все зависит от кокретных условий.

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

G>>Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.
PD>Все, моих педагогических способностей больше не хватает

Дык гони его на пересдачу через деканатскую комиссию, делов то!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PD>Я до сих пор был уверен, что линейный просмотр есть линейный просмотр. Если есть другие алгоритмы линейного просмотра, давай их сюда. Пока что твое утверждение не опровергает Рихтера.
Ну вот раз не опровергает — значит не опровергает. Главное, что опровергает моё утверждение — это твоё необоснованное подозрение о том, что мёртвые строки создают какую-то нагрузку на GC. Нет, не создают.

PD>Но вообще-то С — подмножество С++. Ну пусть не совсем точное, но в основном да. Так что все, что говорилось про С++, можно отнести и к его подмножеству.
Ничего не понимаю. Каким образом ты собрался относить "всё, что говорилось" про std::string и про частичную специализацию шаблонов к С?

PD>Дело в том, что есть программисты разного рода. Ты относишься к тем, для кого программирование — это вызов методов (сам признался), а я к тем, для кого программирование — это написание (методов, функций, процедур).
Ты так говоришь, как будто это что-то плохое.

PD>Вот и вся разница

.
Нет, никакой разницы нету. Ты точно так же вызываешь методы, и я точно так же методы пишу. Даже если ты пишешь на ассемблере, то это не "написание методов", а всего лишь набор вызовов определённых процедур на микрокоде. "Что наверху, то и внизу". Если я пишу "вызовы методов", то в рамках некоторого метода, который будут вызывать другие.

PD>Поэтому для меня все эти игры с геттерами, сеттерами, интерфейсами, паттернами и т.д. малоинтересны. Мне придумать надо, как сделать, а не как оформить. Придумаю — как-нибудь оформлю. А вот если не придумаю — нечего будет оформлять.
Это у тебя просто от недостатка кругозора. Всё программирование — как раз про оформление. Про перевод из одной нотации в другую.
Если тебя попросить написать высокопроизводительный HTTP-сервер для обработки сайта программистского комьюнити с посещаемостью в 40к пользователей в день — уверяю тебя, времени на раздумывания о "структурах и алгоритмах" в терминах C RTL у тебя не хватит. Это будет слишком низкий уровень абстракции. Грубо говоря, твой подход хорош там, где мы придумываем эффективный конвертер из UUEncode в Base64. Задача разработки сервера стоит на шесть уровней архитектуры выше; там думать о регистрах противопоказано.

S>>Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"?
PD>Просто примерно представить себе, что за код при этом получится.
Какой код? На каком языке?
PD>Это интуитивно, объяснить трудно.
А ты попробуй. Это называется "рефлексия" — попытка понять, каким образом ты понимаешь то, что понимаешь. Без неё достаточно сложно найти косяки в своём потоке рассуждений, и уж тем более их исправить. Ключевой момент — именно в том, о каком языке ты говоришь во фразе "примерно представить себе, что за код при этом получится". Этот язык полностью определяет твои способности как программиста. Это может быть последовательность вызовов WinAPI, или набор реляционных операторов, или цепочка трансформаций XML дерева, или последовательность HTTP-запросов. Ну, или там последовательность MOV AH, AL.

PD>Ну для этого сначала не мешает знать, что в Win32 это попросту невозможно

.
Ок. Значит, Эрик писал именно про тебя:

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

http://blogs.msdn.com/ruericlippert/archive/2009/06/08/9723963.aspx

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

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

PD>Слова, слова. Если речь идет о моем коде — да, я и отвечаю, я и анализирую. Если речь идет о чужой библиотеке, то это должен был сделать ее автор, у него код-то свой ?

Если мне приспичит, и исходники есть, я могу за автора эту работу выполнить. В конце концов, и там код на С/С++, и здесь. Просто я своему коду доверяю, а тому — как знать. Сперва проверю на тестах.
И что именно ты проверишь?

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

PD>А все же, будь добр, разрули мне эту задачу с шестикратным циклом с помощью профайлера. Для тебя редко, а для меня это моя работа — не шестикратные циклы, конечно, а как сделать. Вот в данном случае — ответь прямо, какой из вариантов я должен был бы выбрать

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

?) и потом улучшать — как ?
PD>2. Посидеть подумать, свести к 3-циклу и написать, после чего посмотреть с помощью профайлера, что там не совсем хорошо — может, к примеру, не лучшим образом внутренний оператор реализован.

PD>Так как же лучше ?
Лучше — вот так:
1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
3. Проверить её производительность
4. Если она уложилась в требования из п.1., идти делать следующую задачу.
5. Если нет, то тогда начать оптимизацию:
6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
7. Посидеть, подумать, и свести к 3-циклу
8. Перейти к п.3
Вот ссылка на более подробное описание методики: http://blogs.msdn.com/ericlippert/archive/2009/02/06/santalic-tailfans-part-two.aspx

PD>Ну-ну... Отнюдь не далекого, не говоря уж о том, что я свою псевдо-СУБД писал

Ну, тогда он должен быть тебе понятен.

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

CC>Дык гони его на пересдачу через деканатскую комиссию, делов то!

Так в комиссию меня же и включат!

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

CC>>Дык гони его на пересдачу через деканатскую комиссию, делов то!
PD>Так в комиссию меня же и включат!

Ну тогда соболезную.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PD>>Все, моих педагогических способностей больше не хватает

. Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
PD>>вынести не в состоянии

G>Ты сильно привязываешь к конкретной архитектуре процессора и ОС (наверное потому что в других не ориентируешься).

После всех моих попыток тебе что-то объяснить я уже физически чувствую, что я ни в чем вообще не ориентируюсь

.

G>Какой тест?

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

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

S>Рихтер очень много пишет о достижимых объектах, поколениях информации о достижимых ссылках итд.
S>Влад в своей статье тоже неплохо все написал http://rsdn.ru/article/dotnet/GC.xml. На самом деле основная работа это поиск достижимых объектов. Если мы не касаемся объектов в старших поколениях а в 0 поколении нет достижимых объектов, то указатель кучи просто сдвигается на ее начало. На самом деле очень много ньюансов где ГС очень хорош, а где и проседает по полной. Смотри в этой же статье насет врайт барьера, а так же не дефрагментируемые Лохи (старый опыт) итд. Все зависит от кокретных условий.

Да я и не спорю, оптимизировать здесь есть что, и что можно — уже, я полагаю, соптимизировано. Просто если выделить память можно действительно за o(1), то освободить за o(1) не удастся. Так или иначе, а от количества созданных объектов (или живых объектов, или свободных блоков или еще чего-то) это как-то зависеть будет просто в силу специфики задачи.

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

PD>Да я и не спорю, оптимизировать здесь есть что, и что можно — уже, я полагаю, соптимизировано. Просто если выделить память можно действительно за o(1), то освободить за o(1) не удастся. Так или иначе, а от количества созданных объектов (или живых объектов, или свободных блоков или еще чего-то) это как-то зависеть будет просто в силу специфики задачи.
Я влез исключительно из за просмотра памяти. Проблемы фрагментации высших поколений я обсуждал в этой ветке, и ни заявляю, что все бесплатно в этом мире. Но ГС развивается, плюс на многопроцессорных машинах для него отдельный поток отвести можно. А уж копирование на современных процессорах и памяти как то неловко даже обсуждать.
Если стрингбуилдеры и SortedList существуют вместо сегментированных аналогов, и этих аналогов нет в библиотеках.

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

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

PD>>Я до сих пор был уверен, что линейный просмотр есть линейный просмотр. Если есть другие алгоритмы линейного просмотра, давай их сюда. Пока что твое утверждение не опровергает Рихтера.
S>Ну вот раз не опровергает — значит не опровергает. Главное, что опровергает моё утверждение — это твоё необоснованное подозрение о том, что мёртвые строки создают какую-то нагрузку на GC.

Хороши же твои утверждения, если их можно опровергнуть с помощью даже необоснованных подозрений!

>Нет, не создают.

Ладно, шут с ними.

PD>>Но вообще-то С — подмножество С++. Ну пусть не совсем точное, но в основном да. Так что все, что говорилось про С++, можно отнести и к его подмножеству.
S>Ничего не понимаю. Каким образом ты собрался относить "всё, что говорилось" про std::string и про частичную специализацию шаблонов к С?

А я что-то говорил про специализацию шаблонов ? Где ? И про string я говорил лишь, что ее не использую.

PD>>Дело в том, что есть программисты разного рода. Ты относишься к тем, для кого программирование — это вызов методов (сам признался), а я к тем, для кого программирование — это написание (методов, функций, процедур).
S>Ты так говоришь, как будто это что-то плохое.

Честное слово, я не хотел тебя обидеть, и никого другого тоже. Просто у нас разные задачи.

PD>>Вот и вся разница

.
S>Нет, никакой разницы нету. Ты точно так же вызываешь методы, и я точно так же методы пишу. Даже если ты пишешь на ассемблере, то это не "написание методов", а всего лишь набор вызовов определённых процедур на микрокоде. "Что наверху, то и внизу". Если я пишу "вызовы методов", то в рамках некоторого метода, который будут вызывать другие.

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

PD>>Поэтому для меня все эти игры с геттерами, сеттерами, интерфейсами, паттернами и т.д. малоинтересны. Мне придумать надо, как сделать, а не как оформить. Придумаю — как-нибудь оформлю. А вот если не придумаю — нечего будет оформлять.
S>Это у тебя просто от недостатка кругозора. Всё программирование — как раз про оформление. Про перевод из одной нотации в другую.

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

Помнишь Вирта книгу "Алгоритмы + структуры данных == программы". И ни слова про оформление. Или тогда программирования не было ? Я думаю, что все же было. Вот к оформлению относились спокойнее.

Конечно, если придумывать решение не надо, поскольку задача стандартная, то все иначе...

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

S>Если тебя попросить написать высокопроизводительный HTTP-сервер для обработки сайта программистского комьюнити с посещаемостью в 40к пользователей в день — уверяю тебя, времени на раздумывания о "структурах и алгоритмах" в терминах C RTL у тебя не хватит. Это будет слишком низкий уровень абстракции. Грубо говоря, твой подход хорош там, где мы придумываем эффективный конвертер из UUEncode в Base64. Задача разработки сервера стоит на шесть уровней архитектуры выше; там думать о регистрах противопоказано.

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

S>>>Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"?
PD>>Просто примерно представить себе, что за код при этом получится.
S>Какой код? На каком языке?

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

PD>>Это интуитивно, объяснить трудно.
S>А ты попробуй. Это называется "рефлексия" — попытка понять, каким образом ты понимаешь то, что понимаешь.

Чуть выше попробовал

PD>>Ну для этого сначала не мешает знать, что в Win32 это попросту невозможно

.
S>Ок. Значит, Эрик писал именно про тебя:
S>

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

S>http://blogs.msdn.com/ruericlippert/archive/2009/06/08/9723963.aspx

Слушай, ты хоть разберись с основами. Кто писал

S>выделение массива данных размером в 5GB

Ты или нет ?

И в 4GB адресном пространстве, из которого 1 или 2 GB отнимает ОС, ты намерен создать массив в 5 GB ? Я за такие вещи студента с зачета выгоню!

Что же касается того примера, на который этот Эрик ссылается — с файл-мэппингом — поверь, мне это давным-давно известно, еще со времен книги Рихтера 199x года. Проецируемый файл может быть действительно 2^64 байт, только это файл, а не массив, поскольку на диске массивов все же нет, а есть файлы. А спроецировать кусок этого файла ты можешь размером максимум 2 GB (чуть меньше), это и будет массив. А потом, да, можно перепроецировать (освободить старый и аллоцировать новый) на другой кусок файла — будет иной массив, но тоже не более 2Gb. А больше одновременно -не выйдет!
С таким же успехом ты мог бы заявить, что коль скоро можно выделить 1Gb, то сделав это 100 раз, мы получим 100 Gb. Получим, верно, но в разные моменты времени, и каждый раз придется освобождать

Хоть Тб так выделяй

Кстати, плавающие окна я еще в PDP/11 видел.
И кстати, можно и без всяких мэппингов выделить память больше 4Gb одному процессу. Физической памяти, между прочим. Несвопируемой. И он будет ей владеть. И будет к ней иметь доступ. Но не одновременно ко всей

.

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

S>Но мы же не говорим про "вообще нужен", а про способность понять взаимоотношения некоторой конкретной программы с этим файлом.

И про взаимоотношения я тебе грамотному пользователю смогу объяснить. Напрмер, пользователю Фотошопа. Канва простая — картинки большие, места не хватает, а ты хочешь их много, да одновременно, да еще всякие манипуляции, а это промежуточные картинки, ну вот Windows кое-какие куски их на диск и отправляет иногда, а потом обратно. И он вполне поймет.

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

Ты знаешь, основные принципы ОС разработаны в 60-70 годы. Дейтела , например, почитай, если найдешь. И в части управления памятью ничего нового я до сих пор не заметил.

PD>>Слова, слова. Если речь идет о моем коде — да, я и отвечаю, я и анализирую. Если речь идет о чужой библиотеке, то это должен был сделать ее автор, у него код-то свой ?

Если мне приспичит, и исходники есть, я могу за автора эту работу выполнить. В конце концов, и там код на С/С++, и здесь. Просто я своему коду доверяю, а тому — как знать. Сперва проверю на тестах.
S>И что именно ты проверишь?

А я разве собирался что-то проверять ? Я сказал, что ему доверяю, а проверять буду, правильно ли он работает

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

PD>>А все же, будь добр, разрули мне эту задачу с шестикратным циклом с помощью профайлера. Для тебя редко, а для меня это моя работа — не шестикратные циклы, конечно, а как сделать. Вот в данном случае — ответь прямо, какой из вариантов я должен был бы выбрать

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

?) и потом улучшать — как ?
PD>>2. Посидеть подумать, свести к 3-циклу и написать, после чего посмотреть с помощью профайлера, что там не совсем хорошо — может, к примеру, не лучшим образом внутренний оператор реализован.

PD>>Так как же лучше ?
S>Лучше — вот так:
S>1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
S>2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
S>3. Проверить её производительность
S>4. Если она уложилась в требования из п.1., идти делать следующую задачу.
S>5. Если нет, то тогда начать оптимизацию:
S>6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
S>7. Посидеть, подумать, и свести к 3-циклу
S>8. Перейти к п.3

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

PD>>Ну-ну... Отнюдь не далекого, не говоря уж о том, что я свою псевдо-СУБД писал

S>Ну, тогда он должен быть тебе понятен.

Нет. Там хоть и псевдо-БД, но это лишь по характеру работы ее. Я никакие принципы создания БД там не использовал.

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

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

PD>>>Все, моих педагогических способностей больше не хватает

. Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
PD>>>вынести не в состоянии

G>>Ты сильно привязываешь к конкретной архитектуре процессора и ОС (наверное потому что в других не ориентируешься).

PD>После всех моих попыток тебе что-то объяснить я уже физически чувствую, что я ни в чем вообще не ориентируюсь

.
Это почти правда.

G>>Какой тест?
PD>http://rsdn.ru/forum/flame.comp/3419879.1.aspx
Прекрасно, а теперь напиши аллокатор для таких "констант" минимально дефрагментирующий память.
А потом подумай, что с иммутабельными типами эффект достигается без выкрутасов во время выполнения.

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

ГВ>>Не "строки в C++", а "строки MS STL".
S>При чём тут MS?

Да, это я не удачно высказался, потом перечитал — "MS STL" выглядело как попытка акцентировать внимание на MS. Нет, я имел в виду тут целую иерархию: STL — это одна из библиотек, MS STL — одна из реализаций STL.

ГВ>>Даже не смотря на то, что эти строки описаны в стандарте, нет никаких оснований переносить недостатки, свойственные тем или иным реализциям std::basic_string на весь C++.
S>Дети, STL и ASCIIZ — это единственные строки, стандартизованные в С++.

Ну да, и что? Ты думаешь, кого-то это смущает? Повторюсь: если мне не понравятся строки, то хай ANSI вместе XJ21 подавятся своим стандартом — я сделаю новые хранилища/манипуляторы строк и вся идеология C++ тут мне помощником. Единственное место, где неизбежно придётся учитывать наличие ASCIIZ — строковые литералы, так их вообще, чем меньше — тем лучше. А сторонние API — это всегда сторонние API со своими приколами (CRT — тоже один из API).

S>И проблема у них — вовсе не в реализации. А в архитектуре, т.е. в том контракте, которым авторы наделили std::string. Сколько можно объяснять одно и то же? Вам показывают на пальцах: иммутабельные строки — эффективнее. Отдельный от них стрингбилдер — эффективнее. А вы опять за своё: "ой, так нечестно, ваши классы спроектированы под свои задачи". Конечно std::wstring неизбежно будет плодом компромиссов — потому что перед ней поставили противоречивые задачи.

Хорошо, пусть проблема будет в контракте. Но и это не повод переносить недостатки контракта basic_string на весь C++. Если хочешь, давай отдельно поругаем контракт basic_string, я не против. Мне он тоже не во всём нравится.

ГВ>>Не смеши меня, ладно? Никто из C++-ников не говорил (AFAIR), что std::wstring есть лучшее решение на все случаи жизни. Это только строка, предусмотренная стандартной библиотекой. Но "стандартная" не означает "обязательная к применению", поэтому нельзя апеллировать к этой реализации, как к обязательно используемой везде в C++ ("строка в C++" — фраза содержит именно такое неявное обобщение). Сама по себе подобная апелляция уже ошибочна. Не нравятся те или иные строки? Сделай другие.

S>Копец. Я уже семь раз написал на эту тему: самописанные строки не будут ни с кем интероперировать.

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

S>Если бы с самого начала был спроектирован нормальный фреймворк, с раздельными контрактами на mutable и immutable строку — вот тогда да, могли бы существовать различные реализации, которые бы интероперировали на основе этих контрактов. Но в жизни ничего похожего нет — покажите мне хоть одну вменяемую реализацию строк, и хоть один непустой проект на её основе.

Надо посмотреть, обещать ничего не могу, но, вроде бы, какая-то из реализаций STL выполняла преобразование к ASCIIZ по запросу c_str(). А формат хранения был как раз каким-то сложным — не обычный линейный буфер. Ну и потом, проект на основе реализации строки — это сильное колдунство...

Шутка.

ГВ>>Ну, поздравляю нефанатов. Наконец-то они дошли до того, что известно любому C++-нику. Что универсальных решений не бывает.
S>Не вижу, чтобы что-то было известно "любому С++-нику". Пока что любые C++ ники сопротивляются любым попыткам объяснить им, что std::string — УГ. Независимо от реализации.

Тройной одеколон вам в перегонку... С++-ники сопротивляются переносу оценки "УГ" по маршруту: std::basic_string -> C++ -> C++-ники. Не трещите так много про унылость "самих C++-ников" и C++ — и прекрасно услышите, как сами C++-ники ругают и ASCIIZ, и std::basic_string. Понимаешь? Вот не надо неправомерных обобщений и всё будет намного проще.

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

PD>А я что-то говорил про специализацию шаблонов ? Где ? И про string я говорил лишь, что ее не использую.
Зато я говорил про специализацию шаблонов. Впрочем, это неважно. Как я понимаю, с С++ ты просто достаточно плохо знаком — либо я неправильно понимаю твои высказывания. Потому что из них, вроде как, следует то, что ты можешь делать разумные предположения об эффективности программ на С++ без помощи профайлера, а это явно не может быть правдой — и я уже неоднократно писал, почему.

PD>Какой-то набор малопонятных высказываний.
Не надо объяснять. Я всё прекрасно понимаю. Просто то, что ты называешь программированием — это очень-очень маленький кусочек большой картины. Но как только я пытаюсь тебе рассказать про остальные части картины и про их взаимосвязи, моя речь становится для тебя невразумительной. Ок, оставим.

PD>Помнишь Вирта книгу "Алгоритмы + структуры данных == программы". И ни слова про оформление. Или тогда программирования не было ? Я думаю, что все же было. Вот к оформлению относились спокойнее.
Ну, во времена Вирта придумывали, грубо говоря, кирпичи. Сейчас кирпичи уже более-менее придуманы. С точки зрения опытного производителя кирпичей, народ занимается непонятно чем.
PD>Конечно, если придумывать решение не надо, поскольку задача стандартная, то все иначе...
Ну почему же не надо. Я тебе еще раз намекаю на то, что если перед тобой поставить задачу спроектировать высокопроизводительное веб-приложение или даже веб-сервис, то ты встрянешь, несмотря на отсутствие каких-то сверхеъестествнных алгоритмических задач.
Там тоже думать надо — иначе бы мы не имели такого засилья откровенно неудачных веб-приложений.

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

PD>Ничего ты не понял. Увы. При чем тут регистры ? Я тебе сто раз объяснял, что моей задачей было найти эффективное решение задачи, алгоритм.
Прекрасно. Что ты называешь алгоритмом?

PD>Возможно, для HTTP сервера я его не найду — не моя тематика все эти параллельные или псевдопараллельные запросы. Но в любом случае тот, кто его будет писать, должен сначала продумать механику таких запросов и т.д, иначе у него ничего не выйдет. Алгоритм то есть.
Есть, скажем так, определённый "язык" описания устройства веб-приложения. Адресное пространство там, структуры, всё такое. Это не конкретный язык программирования; это скорее неформальное описание того, на какие запросы и как должно отвечать приложение.
Основная задача проектировщика — придумать вот это "описание" так, чтобы оно реализовывало поставленную задачу. Потом нужно будет по этому описанию приложение создать — ну там, скажем, научиться эффективно вычислять last-modified-date для составного ресурса, и всё такое.
Это не алгоритм — в том понимании, как его приводят в словарях. Нет там никакой "finite sequence of instructions". Но от этого меньше программирования там не становится.

PD>Да ни на каком. Я же говорю — интуитивно. Ну если очень хочешь — на ассемблере, но и это не совсем верно. Не о том речь. Вот пишу я и думаю — гм, вот тут вызов ядра, мне это не совсем нравится, нельзя ли без него или хоть пореже. Здесь побайтный проход — тоже не радость. Здесь... Вот и все.
Воот. Есть язык-то! Не может человек думать без языка. Он не обязательно весь вербализирован — когда его вербализируешь, остаётся всего лишь один шаг до нотации. Но сам язык есть. Есть некие образы. И вот то, какие там образы, полностью определяет то, какие программы человек может написать. Не имеет смысла оперировать терминами "вызов ядра", "побайтный проход", при разработке БД. Зато имеет смысл оперировать терминами "loop join", "bookmark lookup". Понятно? Ты вот всё время пробуешь применять образы, выработанные для Pascal/C, к управляемой среде. А это не только бесполезно, но и вредно

PD>Чуть выше попробовал

Ну вот видишь. Главное, чтобы ты не встрял, как та сороконожка

S>>выделение массива данных размером в 5GB
PD>Ты или нет ?
Ты всё-таки прочитай Эрика. Это полезно. Научишься, к примеру, отличать понятие "выделить" от понятия "отобразить".

(*) Хорошо, я соврал. 32хбитная Windows ограничивает общее количество памяти процесса на диске 16ю терабайтами, а в 64хбитной лимит равен 256 Tб. Но нет никакой причины, по которой отдельный процесс не мог бы выделить несколько Гб, если хватает места на диске.

PD>А больше одновременно -не выйдет!
Аллоцировать одновременно можно значительно больше. Отмапить — нельзя. Учим матчасть.

PD>С таким же успехом ты мог бы заявить, что коль скоро можно выделить 1Gb, то сделав это 100 раз, мы получим 100 Gb. Получим, верно, но в разные моменты времени, и каждый раз придется освобождать
Нет. http://blogs.msdn.com/oldnewthing/archive/2004/08/10/211890.aspx

PD>И про взаимоотношения я тебе грамотному пользователю смогу объяснить. Напрмер, пользователю Фотошопа. Канва простая — картинки большие, места не хватает, а ты хочешь их много, да одновременно, да еще всякие манипуляции, а это промежуточные картинки, ну вот Windows кое-какие куски их на диск и отправляет иногда, а потом обратно. И он вполне поймет.
Тем удивительнее то, что ты, к примеру, не понимаешь разницы между Allocate и Map.

PD>>>Так как же лучше ?
S>>Лучше — вот так:
S>>1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
S>>2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
S>>3. Проверить её производительность
S>>4. Если она уложилась в требования из п.1., идти делать следующую задачу.
S>>5. Если нет, то тогда начать оптимизацию:
S>>6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
S>>7. Посидеть, подумать, и свести к 3-циклу
S>>8. Перейти к п.3

PD>Нет уж, Антон, давай без общих советов. На тебе эту задачу и напиши план для нее.
У меня нет никакой задачи. Есть какой-то "шестикратный цикл", который непонятно откуда взялся, и непонятно что делает. Ты мне дай сначала саму задачу, а потом мы посмотрим, как её решать.

PD>Нет. Там хоть и псевдо-БД, но это лишь по характеру работы ее. Я никакие принципы создания БД там не использовал.
Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.

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

ГВ>Ну да, и что? Ты думаешь, кого-то это смущает?
Я не думаю, я знаю. Еще раз: покажите мне хоть одну нормальную реализацию строк, вместе с проектом, который на ней построен.
Очевидно, разработчиков каких-нибудь XML парсеров всё-таки смущает то, что в базовой комплектации нет внятных строк. Поэтому имеем то, что имеем. А не возможность подсунуть твою мега-гитлер-строку в XML парсер и ускорить его на порядок.

ГВ>Повторюсь: если мне не понравятся строки, то хай ANSI вместе XJ21 подавятся своим стандартом — я сделаю новые хранилища/манипуляторы строк и вся идеология C++ тут мне помощником.
Смелая гипотеза. Юношеский задор

Нет. Вся идеология С++ тут же гирей повиснет у тебя на ногах. Потому что в современном мире только редкие люди могут себе позволить писать без использования сторонних библиотек.
ГВ>Единственное место, где неизбежно придётся учитывать наличие ASCIIZ — строковые литералы, так их вообще, чем меньше — тем лучше. А сторонние API — это всегда сторонние API со своими приколами (CRT — тоже один из API).
Все приколы сторонних АПИ связаны именно с тем, что нет нормальной архитектуры.

ГВ>Хорошо, пусть проблема будет в контракте. Но и это не повод переносить недостатки контракта basic_string на весь C++. Если хочешь, давай отдельно поругаем контракт basic_string, я не против. Мне он тоже не во всём нравится.
Ишь, какой ты хитрый! Нет уж, хрен там. Это не я придумал вносить STL в стандарт языка. Поэтому я имею полное право критиковать "строки в С++" именно в том виде, в каком их предложил комитет. Или ты рассчитывал, что я буду обсуждать исключительно компилятор С++? Спору нет, компилятор в С++ просто прекрасен. Но без STL он даже не заработает.

ГВ>Кто тебе сказал такую глупость? Они будут интероперировать через промежуточные абстракции. Никто не мешает выполнять преобразование из rope к ASCIIZ в последний момент перед вызовом функции, требующей именно ASCIIZ. В чём прикол твоего утверждения о невозможности интероперабельности?
В том, что нет никакого смысла держать "эффективные строки", которые один хрен нужно неэффективно преобразовывать в непонятно что при отдаче в любой внешний код. Ты не можешь прочитать "эффективную строку" из файла, ты не можешь передать "эффективную строку" для вывода на экран. Всё, что ты можешь делать — это жонглировать ей внутри узкого кусочка своей программы.

ГВ>Надо посмотреть, обещать ничего не могу, но, вроде бы, какая-то из реализаций STL выполняла преобразование к ASCIIZ по запросу c_str().
А что, не все реализации возвращают ASCIIZ по запросу с_str()???
Я тебе на всякий случай напомню, что это — небезопасная строка. На ее константность полагаться нельзя, т.к. по контракту std::string рушит этот буфер после первого же неконстантного вызова.

ГВ>Тройной одеколон вам в перегонку... С++-ники сопротивляются переносу оценки "УГ" по маршруту: std::basic_string -> C++ -> C++-ники. Не трещите так много про унылость "самих C++-ников" и C++ — и прекрасно услышите, как сами C++-ники ругают и ASCIIZ, и std::basic_string. Понимаешь? Вот не надо неправомерных обобщений и всё будет намного проще.
Я делаю обобщения совершенно правомерно. Показываю еще раз: std::basic_string, как и std::wstring — отстой. Это мы уже выяснили путём непросредственного сравнения. И проблема — не в конкретной реализации, а в том, что хреново спроектированы контракты этих классов.
Именно контракты являются частью стандарта С++, что даёт мне право говорить о том, что "строки в стандарте С++ — говно".

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

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	11.06.09 07:49
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	11.06.09 07:50
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	11.06.09 07:57
Оценка:

	От:	Pavel Dvorkin
	Дата:	11.06.09 08:15
	Оценка:

	От:	Pavel Dvorkin
	Дата:	11.06.09 08:20
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	11.06.09 08:41
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	11.06.09 13:24
Оценка:	3 (1) +1