Здравствуйте, alexeiz, Вы писали:
A>Абсолютно верно. Мы уже подошли к пределу. У меня 3GHz процессор уже два года. И никакого двухкратного скачка частоты за 18 месяцев не предвидется.
Да, закон Мура уже не работает несколько лет!
И ещё "нюанс", про который забывают говорить — архитектура современных компьютеров далека от фон-неймановской. Вы видите 3GHz + 2Gb памяти, а на самом деле... 3GHz + 512Kb (Вам ещё повезло, у Celeron кеш меньше в 2\4 раза). Остальная память работает со скоростью на порядок меньше.
Отсюда и отсутствие различия в скорости работы кода откомпилированного MSVC с опцией /clr и без неё. Сравнивается 2 неоптимальных варианта.
A>http://www.gotw.ca/publications/concurrency-ddj.htm
A>Тем не менее плотность транзисторов можно наращивать и дальше.
Я бы сказал — до сих пор удавалось находить решения технологических проблем.
A>Поэтому процессорная индустрия переходит из области гонки за частоту в область много ядерных процессоров (multicore). Уже существуют dual-core Intel Pentium D & AMD Athlon64 X2. В скором будущем у нас будут гораздо больше core, порядка десяти.
2 ядра — та ещё "конфетка". Ни о каком увиличении скорости в 2 раза речи быть не может. Общая шина памяти, необходимость в когеррентности данных в кеше — это только низкоуровневые железнае проблемы. Когда будет 8 ядер все эти заморочки только усугубятся. Эффективных способов решения нет, и, боюсь, не будет.
Но давайте попробуем заглянуть в будующее:
— бездисковые терминалы с тонкими каналами; загрузка огромного приложения с сервра будет напоминать о загрузке с магнитофона.
— workstation, являющиеся одновременно и "personal" web server — крутится большое количество сервисов, интерпретаторов, БД и прочего. А ещё хочется mp4 посмотреть, да и не закрывать браузер с десятками открытых страниц.
ИМХО не стоит забывать, что развитие часто идёт по спирали...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>2 ядра — та ещё "конфетка". Ни о каком увиличении скорости в 2 раза речи быть не может. Общая шина памяти, необходимость в когеррентности данных в кеше — это только низкоуровневые железнае проблемы. Когда будет 8 ядер все эти заморочки только усугубятся. Эффективных способов решения нет, и, боюсь, не будет.
О чём я и говорю. Dual-core с точки зрения программы — это два процессора. Если программа однопоточна, как большинство существующих, то никакого увеличения производительности не будет. Однако, если мы научимся писать многопоточные программы, то есть шанс, что их производительность будет расти с ростом количества ядер. Есть, конечно, проблемы с памятью, но я думаю, что производительность памяти будет еще некоторое время расти, и память будет становиться дешевле.
Здравствуйте, McSeem2, Вы писали:
MS>Не согласен. Я бы сказал, что это вещи вещи независимые — "этого научить проще тому-то, чем вот этого — противоположному". Здесь главное — чтобы человек обладал некими общими инженерными навыками. Фишка в том, что если человек умеет оперировать байтами в памяти, он как минимум знает, как устроен компьютер. И если он является инженером по своей сущности, то он очень быстро поймет, почему этого не надо делать в дот-нет. И наоборот, если человек начал с дот-нет, но при этом он обладает некими инженерными знаниями, он очень быстро разберется в том, как надо делать эффективно. Встречаются упертые личности — одни на ASM, другие — на C#, но они — не инженеры. И вопрос переучивания — он больше психологический чем технический. Если человек является инженером по своей психологии, то он переучивается легко — хоть туда, хоть сюда. Если же это для него туго, то наилучший способ его задействовать — это поставить на ковейер — пусть работает как машина Тьюринга и выполняет команды. Не хочет? — ну и ладно, найдем другого. Все это и ко мне тоже относится — так что просьба не принимать на личный счет.
Я конечно и не спорю, если человек вменяем — переучить его не проблема. Но слишком уж часто охота за байтами превращается в навязчивую манию, с которой чертовски трудно бороться — по себе знаю . Именно поэтому обучение надо начинать "сверху", а не "снизу", ИМХО
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но вот одно либо я недостаточно четко изложил, либо меня не поняли, либо не хотели понять. Я не призыаваю к тотальной оптимизации, это просто глупо, в конце концов. И те, кто меня в этом упрекают, зря стучатся в открытую дверь. Я выступаю за то, чтобы код на своем уровне писался эффективно. Чтобы не использовались явно избыточные по памяти или времени конструкции, когда это совсем не обязательно и вполне ясно, как без них обойтись, отнюдь не поступаясь при этом ясностью и четкостью.
GN>2 ядра — та ещё "конфетка". Ни о каком увиличении скорости в 2 раза речи быть не может.
Ага. И есть даже закон. здесь GN>Общая шина памяти, необходимость в когеррентности данных в кеше — это только низкоуровневые железнае проблемы. GN>Когда будет 8 ядер все эти заморочки только усугубятся. Эффективных способов решения нет, и, боюсь, не будет.
В архитектуре Фон Неймана, да. Усугубляться. А насчет 8 ядер — посмотри Cell. здесь
Здравствуйте, gear nuke, Вы писали:
GN>ИМХО не стоит забывать, что развитие часто идёт по спирали...
Это не развитие идет по спирали, это просто отдельные люди любят повторять старые и давно известные ошибки...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, оверлей — это нечто иное. Я этим на СМ-4 и ЕС-1022 занимался, это вполне легальное действие, даже ассемблер не требуется. А самоубийство только на ассемблере делалось, даже ИМХО не на ассемблере тогда, а просто в кодах.
Да уж. Я тогда маленький был. Слышал о монстрах которые для того чтобы понять программу переписывали с ассемблера на коды.
PD>Чудно. А могу я эти сервисы безболезненно удалить, и освободить Мбайт так 50-60 ? Немного — получится, а остальные, увы, обязательны для системы. А мне, в общем, все равно, как это называется, ядро или сервисы, лишь бы занимали они поменьше.
Тут конечно фигня творится. Когда новую функциональность с исправлением ошибок смешивают. Но отрицать то, что увеличение функциональности сервиспаками и требования к памяти строго пропорциональны, нельзя. Таже NT4 — с последними сервис паками мег 100 занимает оперативы. Если отрубать ненужное, то можно и сильно сократить. Вопрос только в том, что инструментов недостаточно.
GZ>>Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват?
PD>А какое это имеет отношение к тому, о чем я говорил ? Если машина загружена сверх ее реальных возможностей — конечно, ты не виноват. А вот если реальные возможности машины позволяют загрузить 10 копий твоей программы (без вордов и эксцелов), будь она эффективно написана, а она написана так, что и 3 копии тормозят — виноват ты.
Я бы не стал так говорить. Можно просто программы классифицировать:
1. Резидентные программы на машинах пользователей. Они действительно должны быть компактными, не должны забирать много ресурсов компа, и не мешать пользователю выполнять его основную работу.
2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.
3. Пользовательские программы. Наверно этот класс программ ты и имел ввиду. Вот именно это и есть путь для компромиса. И компромисс между функциональностью и ресурсами. Если функциональность нужная, и она требует достаточно ресурсов, то пользователь не будет возражать, по опыту знаю. Если в требованиях к программе не записано что попутно должны генерится сцены 3D Studio Max, то ему несложно будет выгрузить ее, или понять о том, что это была именно его ошибка. Но вот если функциональность ненужная, а требует достаточно ресурсов, то здесь и я сильно возмущаюсь(а такое на каждом шагу ). Но существует еще вопрос, что значит избыточность ресурсов? Если моя программа занимает на N мегабайт больше, и при этом я уверен что количество ошибок(которые есть будут и полностью их поубивать нельзя) значительно меньше, то я займу эти N мегабайт. В принципе, это и есть некоторая цель Net Framework. Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач. Но адаптируя избыточные ресурсы компьютера к цели уменьшить количество ошибок программ, я делаю больше для пользователя, чем таже программа — хоть и маленькая но ненадежная.
PD>Ты можешь сформулировать когда программу можно считать избыточной?
PD>Попробую. PD>Программа избыточна, когда она PD>1. Использует памяти больше, чем требуется. PD>2. Загружает процессор больше, чем требуется. PD>3. Хранит на диске файлы большего размера, чем требуется.
PD>А требуется — по характеру задачи.
Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500. Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.
PD>>>Или вот другой пример — с умножением матриц GZ>>Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.
PD>Дошли до того, что здесь виной перегрузка в кэше оверхеда на класс массив.Но по мне хоть кэш, хоть процессор, хоть винчестер, хоть дух святой. Не желаю я причин знать , а просто факт констатирую — машина это может в несколько раз быстрее делать, значит и должна делать!
Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки. Правда это можно сделать за пределами Net.
GZ>>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.
PD>Ничего у вас не получится. Потому что эти узкие места вы, может, и найдете, а вот общий уровень все равно с оверхедом будет. Там Мбайт, здесь Мбайт — в итоге 100 Мбайт и виновных нет.
Нет. Не том и дело.
1. Если ты получил понятную программу, достаточно маленьку по исходным кодам, которую прочитает любой ребенок, и которая представляет вверх искуства программирования на ООП, это совсем не значит что она есть эффективна в плане использования памяти и процессора. Даже сказал бы наоборот. Но вот то, что в ней ошибки локализованы, сопровождать ее легко — это факт. После этого ее доводят до требуемого уровня производительности. Это делается легко, поскольку дизайн программы легко сопровождаем. Но это приводит к усложнению дизайна программ. А иногда и архитектуры.
2. Если ты начал предполагать в процессе построения программы, что вот здесь есть узкое место, которое написать оптимально, то
Во — первых, ты можешь ошибиться, это происходит часто, особенно на уровне конкретного программиста большого проекта. Например предположил что здесь надо бы переписать чтобы использовалось значительно меньше тактов процессора, но оказалось что сюда программа зайдет только один раз. И нагрузка на проц, в данный момент никого не волнует. Или когда компилятор делает оптимизацию за программиста, но он об этом не представляет, и тратит даром время при этом мешая компилятору. Это хорошо проявилось например в разности времени здесь
. Оптимизация вполне корректна со стороны программиста, только компилятор уже это сделал.
Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.
Вобщем, мое мнение, что оптимизация программ по используемым ресурсам, должны проходить в 3 плоскостях:
1. При построении архитектуры. Мы еще видим все проблемы в комплексе, и наиболее крупные можем сразу решить.
2. Алгоритмическая оптимизация. Неэффективный алгоритм на порядки хуже неоптимизированного кода.
3. Оптимизация готового продукта под конкретные требования пользователя. Свое мнение я уже описал.
PD>А у ICQ вообще когда-нибудь не-беты были ? У меня что-то впечатление такое, что она только из бет и состоит
Нет, еще альфы. По моему — релизы там не бесплатные. Хотя могу ошибаться.
GZ>>Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы.
PD>Пользователь доволен. Вполне. И если он у тебя один — решай с ним все проблемы. А вот когда речь о продуктах, используемых в миллионах копий идет — тут задавать вопрос, доволен ли пользователь — все равно, что спрашивать, оуениваете ли вы положительно работу ГосДумы . Отдельно одной программой доволен, другой — доволен, третьей доволен, все вместе запустишь — недоволен. Жалуйтесь кому хотите, хоть господу богу.
Пользуйся альтернативами Я понимаю что в случае крупных монополистов — такое плохо проходит. Слишком высока сложность программ. Но нельзя так говорить о всей отрасли. Пользуются же мирандой вместо аськи.
PD>Бывает и такое. Как в известном анекдоте, как ни собираю, а пулемет получается. Но почему аналогия неуместна — не понял.
Потому что важно чтобы летал, а не с той скоростью которую пользователь не заказывал. В старое время бесшабашных программистов одиночек, они могли плавать, и даже нырять. Но летать не получалось. Сам такие программы писал, грешен.
Так что главное достигнуть цели. Если цель не достигнута, то уже ничего не важно.
GZ>>А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.
PD>Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?
Да. Я вполне представляю весь процесс сооружения такой программы. Если ты потратил время на то, чтобы адаптировать решение на меньшие ресурсы, когда я знаю что ресурсы заказчика(или предполагаемого заказчика) значительно больше, то безусловно. Ты проделал работу, которая никому не нужна. Мало того, ты усложнил сопровождение программы. Для программ класса серверов приложений — я не вижу исключений из этого правила.
Здравствуйте, ie, Вы писали:
ie>Ну не скажи.... Живой пример. Я попросил своего менеджера ежедневно выделять из моего рабочего времени 1 час на ревью кода вновь пришедшего. Ну не умеет новенький эффективный код писать и это не его вина, не научили еще. Нет же, и так в сроки можем не уложиться. Сдадим этап, тогда если(!) сильно тормозить будет, возможно(!), сделаем ревью... Вот так — если и возможно! А так — работает и пес с ней с эффективностью. Вот кто виноват? Скажи, пожалуйста.
Значит аргументация подкачала. На войне больше всего боялись даже не немцев. Больше всего боялись плохого командира. ie>В итоге — пора сдавать, а DataGrid ну уж очень тупит при отрисовке. Студент делал его раскрасску. Хочешь расскажу какой он код в DataGridColumnStyle.Paint напихал
Обычно это в юмор, ветка про индусов.
ie>Смотря что понимать под "смешивать". Если я не ошибаюсь Перл пришел из-за необходимости генерить Excel отчеты (могу ошибаться, сам в Перловую часть не разу не лазил). Ну нет в .NET средств эффективной генерации Excel отчетов. В Perl есть, взяли, прикрутили. Почему это плохо?
Вообще-то в Net много чего есть. Можно и отчеты генерить. Непонимаю. ie>Лично мне, да никому другому, не надо переключаться между всеми 5ю языками.
А мне приходится. Сразу понимаешь недостатки того или иного языка. Например, нечитабельность C++(когда работал на чистом С++, таких проблем не ощущал). Или отсутвие автоматических деструкторов в Delphi. Про разность методов работы, я уже писал.
ie>Ну вот тот же пример с тестом Павла. Он явно дает понять, что ++ код эффективней справляется с поставленной задачей. Так и сделать эту чать на ++, конечно, без фанатизма, если эта часть действительно критичная, а не бегать каждый раз делать на ++ все что там даст выйгрыш в скорости и использовании памяти.
В конкретном случае, да. Но без ясной и понятной причины, этого делать нельзя.
GZ>>С чего все началось. Началось с того, что к Net программам Павел начал приставлять свойства C++. Ну нет у него многих свойств С++. Точно также и нет многих свойств C# у С++. В результате, дизайн программ существенно различается. По форуму Net очень часто поступают вопросы, сквозь которого проступает C++. GZ>>И данный пост Павла(которым он наконец разродился) именно связан с темой сравнения с С++.
ie>Да, и это не может не огорчать. Вместо того чтоб спорить что же все таки лучше, общими усилиями написали бы статью, о том какие классы задач и их подзадач с помощью какой технологии эффективно решаются.
Пройди по поиску. Это не раз обсуждалось.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Но вот одно либо я недостаточно четко изложил, либо меня не поняли, либо не хотели понять. Я не призыаваю к тотальной оптимизации, это просто глупо, в конце концов. И те, кто меня в этом упрекают, зря стучатся в открытую дверь. Я выступаю за то, чтобы код на своем уровне писался эффективно. Чтобы не использовались явно избыточные по памяти или времени конструкции, когда это совсем не обязательно и вполне ясно, как без них обойтись, отнюдь не поступаясь при этом ясностью и четкостью.
Д>Что в лоб, что по лбу — особой разницы я не вижу
Оптимизация всего и вся либо же не использование заведомо неэффективных конструкций — и ты не видишь разницы ? Ну, тогда сложно сказать что-то еще.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Оптимизация всего и вся либо же не использование заведомо неэффективных конструкций — и ты не видишь разницы ? Ну, тогда сложно сказать что-то еще.
А ты прочитал статью? Там есть как раз про "заведомо неэффективные конструкции". Почитай, в частности, про страшный алгоритм сложности f(n^3)
Здравствуйте, GlebZ, Вы писали:
GZ>Да уж. Я тогда маленький был. Слышал о монстрах которые для того чтобы понять программу переписывали с ассемблера на коды.
Нет. Они просто ее писали в кодах, с самого начала
>Таже NT4 — с последними сервис паками мег 100 занимает оперативы.
У нас еще старый класс есть, для первокурсников, там 64 Мб и NT4. Вполне работает, SP последний.
GZ>Я бы не стал так говорить. Можно просто программы классифицировать: GZ>1. Резидентные программы на машинах пользователей. Они действительно должны быть компактными, не должны забирать много ресурсов компа, и не мешать пользователю выполнять его основную работу.
+
GZ>2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.
+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.
GZ>3. Пользовательские программы. Наверно этот класс программ ты и имел ввиду. Вот именно это и есть путь для компромиса. И компромисс между функциональностью и ресурсами. Если функциональность нужная, и она требует достаточно ресурсов, то пользователь не будет возражать, по опыту знаю. Если в требованиях к программе не записано что попутно должны генерится сцены 3D Studio Max, то ему несложно будет выгрузить ее, или понять о том, что это была именно его ошибка. Но вот если функциональность ненужная, а требует достаточно ресурсов, то здесь и я сильно возмущаюсь(а такое на каждом шагу ). Но существует еще вопрос, что значит избыточность ресурсов? Если моя программа занимает на N мегабайт больше, и при этом я уверен что количество ошибок(которые есть будут и полностью их поубивать нельзя) значительно меньше, то я займу эти N мегабайт. В принципе, это и есть некоторая цель Net Framework.
Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше. А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам. От ошибок алгоритма меня никакой FrameWork не защащает. Складывать килограммы с метрами (вместо того, чтобы умножать) и там вполне можно, .
>Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач.
Я бы эту фразу перевернул.
Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.
GZ>Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500.
Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.
>Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.
Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.
GZ>Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки.
Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы. Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.
GZ>>>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест.
"У нас никогда нет времени на то, чтобы сделать все как следует, но всегда есть время на переделки"
>А также оптимизацией памяти, если ее оказалось недостаточно.
Ничего ты не соптимизиуешь. Не ты лично, а те, кто к эффективности не привык. Им и в голову не придет, что это все на 20 Мб может меньше требовать.
GZ>1. Если ты получил понятную программу, достаточно маленьку по исходным кодам, которую прочитает любой ребенок, и которая представляет вверх искуства программирования на ООП, это совсем не значит что она есть эффективна в плане использования памяти и процессора. Даже сказал бы наоборот. Но вот то, что в ней ошибки локализованы, сопровождать ее легко — это факт. После этого ее доводят до требуемого уровня производительности. Это делается легко, поскольку дизайн программы легко сопровождаем.
Ну и заявление! Дизайн понятен, сопровождение легко, след-но, оптимизировать будет несложно! А то, что для оптимального решения задачи, возможно, надо не в деталях оптимизировать, а все решение пересмотреть и весь дизайн переделать — это ты не допускаешь ? Совсем другим способом ее решать!
GZ>Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.
ИМХО это лечится рано или поздно, а первое — не всегда.
GZ>Вобщем, мое мнение, что оптимизация программ по используемым ресурсам, должны проходить в 3 плоскостях: GZ>1. При построении архитектуры. Мы еще видим все проблемы в комплексе, и наиболее крупные можем сразу решить.
+
GZ>2. Алгоритмическая оптимизация. Неэффективный алгоритм на порядки хуже неоптимизированного кода.
+++
GZ>3. Оптимизация готового продукта под конкретные требования пользователя. Свое мнение я уже описал.
+-
GZ>Пользуйся альтернативами Я понимаю что в случае крупных монополистов — такое плохо проходит. Слишком высока сложность программ. Но нельзя так говорить о всей отрасли. Пользуются же мирандой вместо аськи.
Да, а вместо Net Framework что предложишь ? Вместо MS Office ?
PD>>Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ? GZ>Да. Я вполне представляю весь процесс сооружения такой программы. Если ты потратил время на то, чтобы адаптировать решение на меньшие ресурсы, когда я знаю что ресурсы заказчика(или предполагаемого заказчика) значительно больше, то безусловно. Ты проделал работу, которая никому не нужна. Мало того, ты усложнил сопровождение программы. Для программ класса серверов приложений — я не вижу исключений из этого правила.
Опять -таки — все верно, если у тебя единственный заказчик. Ему хоть на 2Gb пиши, если у него их 4. Но я-то о других случаях говорю.
Здравствуйте, Pavel Dvorkin, Вы писали:
D>>А как вам вот такой тезис, что программа просто должна быть достаточно xxx? D>>Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать;
PD>Если бы мы были в однопрограммной системе — готов согласиться. А в многопрограммной — нет. Потому как отдельная программа может быть вполне достаточна, а все вместе они едят ресурсов немеряно и тормозят.
PD>Кстати, сформулируй критерий достаточности, если можешь.
Для начала честно признаюсь с неспособности его сформулировать, но могу показать, где как я думаю стоит его искать в конкретных случаях.
Во первых полностью согласен с мыслями
Glebz о достаточной оптимальности. Особенно с его классификацией и походом к оптимизации.
Далее предлагаю забыть о том что работа это не только возможность кушать, но еще и сточник кайфа и способ "поддерживать форму". И посмотреть на "достаточно" только с точки зрения бизнеса.
Во-первых наше место в делании денег на софте: Делает их кассир, в тот момент когда приходит покупатель. А приходит он потому, что отдел PR удачно прорекламировал продукт и покупатель не только узнал, но еще и решил купить. А вот теперь наше место — помочь PRщкам делать свою работу лучше. Если бизнес делается не на продаже софта, немного меняются детали моего рассуждания, но общая идея таже — наше дело делать софт, достаточно востребованный пользователем. Достаточно в смысле бизнеса.
Теперь, кто же тот самый пользователь, для которого надо быть достаточным? Ответ — тот же для кого стараются PR. Тут пользователи делятся на две группы:
1. Кто уже выбрал. Их надо удержать, новая версия (патч) должена быть достаточна, что бы пользователь не взял другой продукт и должена быть выпущена достаточно быстро.
2. Кто про продукт знает, но не пользуется. Соответственно достаточно чтобы потенциальный пользователь стал действительным.
Ксати предположения о target group и цене на продукт могут очень помошь всести многопрограммную систему к "квази" однопрограммной.
Сколько ресурсов у предполагаемого пользователя? Какие сколько из них заняты его типовыми программами? — Остальное только для нас
Сколько пользователь заплатит за наш софт? А сколько за апгрейд, что бы не тормозил?
Девелопер должен думать о том как с наибольшей пользой потратить свое рабочее время. В частности, если плохо известно для кого стараемся, то очень может быть, что стоит вообще ничего не кодить, а узнать это.
Возможна ситуация, когда начальник имеет другое представление о приоритетах (в просторечие — начальник дурак ), а рассматриваем мы ситуацию с позиции хорошо покушать, и удовлетворить вообще-то надо начальство. Тут два варианта (кроме увольнения). Донести свое видении до начальства. Или получать кайф от качественного выполнения заказанной работы, в конце-концов, может он и прав и в любом случае это его ответственность.
PD>Удобство UI прямого отношения к эффективности обычно не имеет. А вот чистота и последовательность архитектуры отнюдь не требует применения неэффективных методов. Скорее наоборот — скажи кратко, но хорошо (К. Прутков)
Не соглашусь по обоим пунткам. Тривиальный пример — это выбор платформы (процессорный код vs VM, различные языки — различного качества компиляторы/VM`ы).
Архитектура может быть достаточно гибкой для оптимизации, но при этом излишне сложной, если оптимизация не потребуется. И наоборот, очень удобной, но местами эффективные решения придется делать кривостью. В первом случае получаем много скорости мало фич, во втором — наоборот. Конечно замечательно, когда "кратко, но хорошо", но бывает озарение не пришло...
C UI теже проблемы. Все время стоишь перед выбором, усложнять реализацию или использовать не эффективные решения. Например, хочу показать всегда актульную информацию -> паттерн observer -> что наблюдаем? И тут часто оказывается, что следить за всем подряд существенно проще чем только за тем, что необходимо. А если завтра после небольших изменений необходимого станет больше?
Дарней wrote:
> Научить обычного, не озабоченного "оптимизацией-везде-где-можно" > программиста оптимизировать программы куда проще, чем научить > "байтовыжимателя" писать нормальный и понятный код.
Кто сказал, что хороший оптимизированый код — непонятен? Код той же
Miranda читается без всяких проблем, хотя она и не жрет мегабайты.
> Потому что второй всегда будет искать, как в .NET обнулить поля > структуры с помощью ZeroMemory (да-да, это намек ) — вместо того, > чтобы проектировать архитектуру. Да еще и считать окружающих идиотами, > потому что они не понимают, как же это важно — обязательно залезть на > нижний уровень по самый локоть.
Опять же, оптимизация — это не значит копание в машинных кодах. Нужно
просто следить, чтобы не было явных ляпов, где время/память тратится зря.
GlebZ wrote:
> PD>Чудно. А могу я эти сервисы безболезненно удалить, и освободить > Мбайт так 50-60 ? Немного — получится, а остальные, увы, обязательны > для системы. А мне, в общем, все равно, как это называется, ядро или > сервисы, лишь бы занимали они поменьше. > Тут конечно фигня творится. Когда новую функциональность с > исправлением ошибок смешивают. Но отрицать то, что увеличение > функциональности сервиспаками и требования к памяти строго > пропорциональны, нельзя. Таже NT4 — с последними сервис паками мег 100 > занимает оперативы.
Это, наверное, если все сервисы сразу запустить. Я долгое время без
проблем работал на P166+32Mb+NT SP6.
Здравствуйте, Cyberax, Вы писали:
C>Кто сказал, что хороший оптимизированый код — непонятен? Код той же C>Miranda читается без всяких проблем, хотя она и не жрет мегабайты.
А кто вообще сказал, что он такой уж оптимизированный? Если ты прикрутишь к ней кучу плагинов, чтобы сравнять по всем функциям с аськой — уверен, жрать она будет ничуть не меньше. К тому же глючит она не по детски — хотя и сам ей давно пользуюсь, ибо перегруженная ненужными функциями аська меня совсем достала.
Так что — за всё надо платить.
C>Опять же, оптимизация — это не значит копание в машинных кодах. Нужно C>просто следить, чтобы не было явных ляпов, где время/память тратится зря.
Ты можешь точно сказать, где проходит граница между "явными" и "неявными" ляпами?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Оптимизация всего и вся либо же не использование заведомо неэффективных конструкций — и ты не видишь разницы ? Ну, тогда сложно сказать что-то еще.
Д>А ты прочитал статью? Там есть как раз про "заведомо неэффективные конструкции". Почитай, в частности, про страшный алгоритм сложности f(n^3)
Ну, во-первых, эта статья есть гораздо ближе, да еще и на русском.
А во-вторых, опять же не туда показываешь. Я об общем стиле написания говорю, о заведомо неэффективных конструкциях, которые порой используются. В определенных случаях это может не сказаться, согласен. А вот когда весь код таким образом пишут, то повышается общий уровень неэффективности.
Вот, кстати, дай мне ответ. Хотя это лучше в .net, но ИМХО не страшно и здесь.
Перекодирование строки из файла из 866 в 1251.
Все что я нашел, сводится к
public string MyDecoder(string str)
{
byte[] b = Encoding.GetEncoding(866).GetBytes(str);
str = Encoding.GetEncoding(1251).GetString(b);
return str;
}
или вариациям на эту тему
Имеем здесь
Память
Исходная строка — 2N байт (N- число символов). Если строка из файла, то StreamReader еще поработал, чтобы ее из 866 в юникод перевести. И внутри себя он без массива в N байт не обошелся.
Массив b — N байт
Результирующая строка — 2N байт
Вывод ее в другой файл — еще N байт в 1251 внутри StreamWriter.
Итого 7N байт
А нужно всего-то N байт.
Время
StreamReader в юникод переделывал — цикл
GetBytes — цикл
GetString — цикл
StreamWrite записывает в файл с перекодировкой — цикл.
Итого 4 цикла. А нужен всего 1.
Я вполне допускаю, что ты сейчас мне это эффективнее напишешь. Ты. А все будут именно это и делать.
D>Я абсолютно согласен с ортимизацией "где надо", речь не об этом. В исходном посте посте говорилось о тенденции, о появившихся привычках и том, что понятие "оптимальный" просто забывается, уходит вслед за 1Mhz компами и 640Кb памяти. И что эта тенденция очень может выйти боком в свете физических пределов GHz и Gb.
И чем же она может выйти боком? тем что народ разучится писать эффективные программы? Но это ж не секрет дамасской стали.
К тому же большинство из нас писать эффективные программы могут, и даже любят... но им этого менеджеры не дают... и правильно делают, я писал выше почему.
А тенденция не поменяется пока не закончатся гигагерцы и гигабайты.
Буду краток: писать код надо так, чтобы из него можно было получить максимальную денежную прибыль.
Лично я признаю только такое правило.
В каких-то случаях, это выская производительность, достигаемая оптимизацией и аккуратностью выбора алгоритмов.
В каких-то случаях, это высокая скорость разработки, с быстрым отловом ошибок, простота архитектуры и грамотное разбиение на классы для дальнейшего удобного сопровождения и модификации. Ситуаций много, поэтому абсолютных правил быть не может. Кроме того, ради чего все делается(т.е. зарабатывания денег)
Уважаемый mrozov правильно написал, что времена любителей позаниматься сексом с компом прошли в индустрии программирования. Энтузиастам и "вольным художникам" не место в индустрии.
Все вышенаписанное — мое имхо.
McSeem2 wrote:
> А вот слова Matthew MacLaurin из Microsoft MSX group, который зовет > меня туда работать: > The project is an advanced, small-team product – an information > manager for the internet age. We started it in research and are now > going to ship it. It uses queries as the primary organizational > construct – letting users easily build and manipulate queries as first > class objects, etc. It also emphasizes tagging and distributed > information. We’ve put a lot of work into a very elegant and polished > user interface with translucency, drop shadows, seamless compositing > everywhere, etc. *Our prototype is up and running in C#, and we are > now porting to C++*. > К чему бы это?
Кстати, у нас в постановке проекта так и звучало: "Переделать прототип
приложения c C# на С++" Между строчками читалось: "Эта <пиииииии>
программа на C# не может делать ни <пииииииииии>. Сделайте нам нормальную."
Здравствуйте, Nickolay Ch, Вы писали:
NC>Уважаемый mrozov правильно написал, что времена любителей позаниматься сексом с компом прошли в индустрии программирования. Энтузиастам и "вольным художникам" не место в индустрии.
Вот это сильно сказано.
Пора менять профессию.
NC>Все вышенаписанное — мое имхо.
На это и остается расчитывать. А вдруг ты прав?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
. Именно поэтому обучение надо начинать "сверху", а не "снизу", ИМХО
