Здравствуйте, Cyberax, Вы писали:
C>Ошибаетесь, вот МС показала здравый смысл — в Windows Vista все как и C>раньше будет основано на unmanaged-приложениях. В том числе и explorer с C>оффисом. И пока программисты, ратующие за увеличение производительности C>труда, будут писать чего-то там на WinForms или Avalon'е — МС будет C>совершенствовать свой набор оффисных программ, интегрированных через C>OLE2 (аналога которого в managed-мире нет и не предвидится).
Маленько ошибочка вышла. Поддержка офисом Net'а уже давно есть. Даже и без нее можно работать Com'ом. OLE2 давно умерла, остались ActiveX. Поддержка его(кривая правда) но все таки есть.
Да в чем же я ошибаюсь? Везде, где это возможно, все стараются делать проще, а не эффективнее.
Причины непереписывания на .net word-а по-моему очевидны. К неэффективности .net никакого отношения они не имеют.
И вообще — я бы поставил вопрос иначе — пока ратующие за эффективность кода будут ковыряться в своем низкоуровневом коде, использующие windows forms (или VB) коллеги будут успешно сдавать заказчику один проект за другим. Замечу — результат их труда неизменно будет отвечать заявленным требованиям по эффективности.
Поделюсь одним жизненным наблюдением.
Моя фирма использует в своей работе инструментальные средства и подходы, по сравнению с которыми между .net и машинными кодами разницы почти не заметно.
Как-то раз пути одного из наших проектов пересеклись с проектом некой третьей фирмы, которая все по-мужицки делала на с++. Год за годом, версия за версией. Они с этого проекта, собственно, и кормились (насколько я понимаю).
Когда руководитель группы разработки этой фирмы во время сравнительных испытаний возможностей их системы и того, что было сделано тремя нашими разработчиками за пол-года, увидел наш вариант — у него натурально дрожжали руки. У человека началась форменная истерика — потому что от очень четко понял свое место в этой жизни. И место своего подхода к разработке ПО, соответственно.
Кесарю — кесарево, а слесарю — слесарево. И пытаться привинтить к прикладному программированию высокие идеалы экономии бесценной conventional памяти — не стоит.
GlebZ wrote:
> C>Ошибаетесь, вот МС показала здравый смысл — в Windows Vista все как и > C>раньше будет основано на unmanaged-приложениях. В том числе и > explorer с > C>оффисом. И пока программисты, ратующие за увеличение производительности > C>труда, будут писать чего-то там на WinForms или Avalon'е — МС будет > C>совершенствовать свой набор оффисных программ, интегрированных через > C>OLE2 (аналога которого в managed-мире нет и не предвидится). > Маленько ошибочка вышла. Поддержка офисом Net'а уже давно есть.
Я сказал "основана" — .NET в том же Word'е играет только роль
скриптового языка.
> Даже и без нее можно работать Com'ом. OLE2 давно умерла, остались > ActiveX. Поддержка его(кривая правда) но все таки есть.
OLE2 — живее всех живых (см. оффис). ActiveX — это примерно subset
технологий OLE2.
mrozov wrote:
> Причины непереписывания на .net word-а по-моему очевидны. К > неэффективности .net никакого отношения они не имеют.
Да ну?
> И вообще — я бы поставил вопрос иначе — пока ратующие за эффективность > кода будут ковыряться в своем низкоуровневом коде, использующие > windows forms (или VB) коллеги будут успешно сдавать заказчику один > проект за другим.
Ну да, и через год об этих проектах забудут. А вот выверенные и быстрые
низкоуровневые приложения будут продаваться и развиваться еще долго.
> Когда руководитель группы разработки этой фирмы во время сравнительных > испытаний возможностей их системы и того, что было сделано тремя > нашими разработчиками за пол-года, увидел наш вариант — у него > натурально дрожжали руки. У человека началась форменная истерика — > потому что от очень четко понял свое место в этой жизни. И место > своего подхода к разработке ПО, соответственно.
Ну значит плохо на С++ писали. У нас была обратная ситуация — группа
С#истов полтора года делала приложение. Оно у них работало, но медленно
и не особо устойчиво (подумаешь, пара исключений при запске — ничего
ведь не падает).
Поэтому когда мы выкатили заказчику примерно такой же продукт с
поддержкой OLE2 (то есть наши документы можно, например, в Word
вставлять) — старое приложение торжественно удалили.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько PD>это возможно!
Не согласится не возможно.
Сперва, хочу все-таки попросить всех участников форума быть разумными "насколько это возможно!" (с) Pavel Dvorkin и не скатываться на обсуждение технологий и ЯП — жаль, что это сделал Павел.
Да, я, безусловно, ЗА эффективный код. Сам иногда удивляюсь вопиющему пофигизму к эффективности. Только ИМХО эффективность нынче меряется далеко не объемом используемой оперативки и быстродействием. Эффективность трансформирповалась нечто другое. Посмотрим на нее в немного другой плоскости. Буду говорить об эффективноти 2х типов: эфективность на уровне кода и на уровне технологий.
Эффективность на уровне кода.
Простейший пример неэффективности приведу из проекта, в который с недавнего времени пришел. Один коллега пишет:
for (int i = 0; i < reporter.GetDistributorsCount()*reporter.GetReportTypesCount(); i++)
{
// работа с БД
}
Я сказал, что это не очень красиво и попросил переписать сие безобразие на следующий код:
for (int i = 0, count = reporter.GetDistributorsCount()*reporter.GetReportTypesCount(); i < count; i++)
{
// работа с БД
}
На что мне открыто заявили: "reporter.GetDistributorsCount()*reporter.GetReportTypesCount() — это ничто по сравнению тем, что находится в теле цикла! работа с БД уничтожит эту оптимизацию". Уж не знаю и правда ли он так думает или для него слишком уж обидно, когда вчерашний студент учит код писать профессионала со стажем. Ну не прав он. На все 100 не прав. Когда в метод GetDistributorsCount(), однажды добавят работу с БД, а то и с веб-сервисами (на самом деле в этот метод вряд ли, а в другой?), тогда начнет плоды пожимать. А что, тяжело сразу написать эффективно?
Дело тут не в расбрасывании ценными килобайтами памяти, а в неэффективности с точки зрения поддержи кода и системы в целом.
Буду ли я оптимизировать работу с матрицами? — It depends... По большей части от поставленной задачи. Стараться сделать все как можно оптимальнее, определенно буду. Но скорее всего у начальства не вызовет восторга, на то, чтоб даже 5-6 часов, я сделал код экономящий пару МБ.
Действительно, мы сейчас живем в век дешевой техники и дорогой рабочей силы. Но экономя на поддержке и разработке многие, прежде всего заказчики и начальники, действительно портят программистов. Что однако не умоляет множество глупых и бездарных программ.
По поводу ICQ-клиента — Miranda рулит
Эффективность на уровне технологий.
Вот с архитектором в проекте очень даже повезло. Сейчас используется 5 ЯП с соответсвующими им технологиями. Я бы еще пол года назад сказал бы — да зачем мне какой-то там Питон, .NET форева. (Надеюсь больше меня эти мысли посещать не будут.) Все от начала до конца можно было сделать на .NET. Однако, прилили и C++, и Питон, и Ява Скритп, и Перл. Чего добились — думали: путаницы и неразберихи — оказалось: простоты и эффективноти!
Что я хочу этим сказать — ну сколько можно доказывать друг другу, что вот так вот в # не сделаешь, а вот так в ++ (хотя сам люблю друзьям ++никам, за кружечкой пива обяснить, что ++ — это так — игрушки ). Пора уже давно выяснить сильные стороны каждой из технологий и использовать их. А будь мне действительно так важны те 2 МБ при работе с матрицами — сяду за плюсы и глазом не моргну. Чего и вам, Павел, желаю.
Здравствуйте, Cyberax, Вы писали:
C>OLE2 — живее всех живых (см. оффис). ActiveX — это примерно subset C>технологий OLE2.
И да, и нет. Насколько я помню, в ActiveX уменьшили количество обязательных интерфейсов. И добавили свои. Но OLE2 он не отрицал. Он его развивал.
Здравствуйте, Cyberax, Вы писали:
C>Ну значит плохо на С++ писали. У нас была обратная ситуация — группа C>С#истов полтора года делала приложение. Оно у них работало, но медленно C>и не особо устойчиво (подумаешь, пара исключений при запске — ничего C>ведь не падает).
C>Поэтому когда мы выкатили заказчику примерно такой же продукт с C>поддержкой OLE2 (то есть наши документы можно, например, в Word C>вставлять) — старое приложение торжественно удалили.
А вот слова 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++.
К чему бы это?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
ie>Действительно, мы сейчас живем в век дешевой техники и дорогой рабочей силы. Но экономя на поддержке и разработке многие, прежде всего заказчики и начальники, действительно портят программистов. Что однако не умоляет множество глупых и бездарных программ.
Это не заказчики и начальники. Многие из них и не знают каким образом вся эта груда текста, написанное на языке очень похожем на английском, может работать. Разработка — это дело самих разработчиков. И поставить например Code Review — это не работа заказчика, это работа разработчиков. Так что винить надо только себя.
ie>Вот с архитектором в проекте очень даже повезло. Сейчас используется 5 ЯП с соответсвующими им технологиями. Я бы еще пол года назад сказал бы — да зачем мне какой-то там Питон, .NET форева. (Надеюсь больше меня эти мысли посещать не будут.) Все от начала до конца можно было сделать на .NET. Однако, прилили и C++, и Питон, и Ява Скритп, и Перл. Чего добились — думали: путаницы и неразберихи — оказалось: простоты и эффективноти!
А вот это плохо. Смешивать питон с перлом. Будь моя воля, я бы привел все к одному языку. Очень трудно переключаться с одного языка на другой. Вроде бы очень похоже, и термины такие-же. Только дизайн программ весьма зависит от используемого языка. Есть языки которые от которых зависят выбранные технологии. Тут хочешь не хочешь надо. И это хорошо. Но если что-то можно сделать одним языком, то это нужно делать именно этим языком.
С чего все началось. Началось с того, что к Net программам Павел начал приставлять свойства C++. Ну нет у него многих свойств С++. Точно также и нет многих свойств C# у С++. В результате, дизайн программ существенно различается. По форуму Net очень часто поступают вопросы, сквозь которого проступает C++.
И данный пост Павла(которым он наконец разродился) именно связан с темой сравнения с С++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> Создается впечатление, что рост быстродействия процессоров несколько PD>замедлился. Может быть, я не прав, но мне кажется, что мы подошли к некоторому PD>пределу, и если не последует технологического прорыва, то скорость сильно расти PD>не будет. Еще раз — может быть, я не прав. Кстати, о памяти пока в этом плане PD>говорить не приходится.
PD> Но так или иначе — этот предел есть. Очень уж четкие физические PD>законы здесь действуют, их не обойдешь. Раньше или позже, но бурный рост PD>мощности ПК заменится если не стагнацией, то более или менее плавным изменением, PD>на проценты, а не в разы.
Абсолютно верно. Мы уже подошли к пределу. У меня 3GHz процессор уже два года. И никакого двухкратного скачка частоты за 18 месяцев не предвидется.
Тем не менее плотность транзисторов можно наращивать и дальше. Поэтому процессорная индустрия переходит из области гонки за частоту в область много ядерных процессоров (multicore). Уже существуют dual-core Intel Pentium D & AMD Athlon64 X2. В скором будущем у нас будут гораздо больше core, порядка десяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько PD>это возможно!
Читал. Плакал. Вспоминал статью Саттера “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software” — там тоже про то, что закон Мура уже не тот, что был раньше
Однако, в наше время таки оптимизировать всё до последнего байта есть непозволительная роскошь. Моё время как разработчика несравненно дороже времени процессора и оперативной памяти.
Я приведу пример из собственного проекта. У меня есть изображения букв в матрице 32×64, и время от времени мне приходится сравнивать их с генерируемыми в процессе работы программы изображениями в аналогичной матрице. Если бы я не поддался на идею коллеги закодировать каждую строчку пикселов DWORD’ом, и хранил их в 8-битных bitmap’ах — у меня бы для сравнения использовалась библиотека Intel Performance Primitives, тщательно вылизанная разработчиками из Intel’а под все их процессоры. И по скорости, я уверен, это было бы быстрее, чем написанные моими не идеально прямыми руками циклы. И в части внедрения изменений в код это было бы более поддерживаемо, чем эта побитовая арифметика и магические функции подсчёта битов в двойном слове.
Пишите свои программы понятно, господа! Если использование показывает, что память — узкое место, найдите 10% кода, которые используют 90% памяти. Если использование показывает, что узкое место — процессорное время, найдите 10% кода, которые работают 90% времени. Premature optimization is the root of all evil, хотя и premature pessimization тоже is the leaf of no good.
Centaur wrote:
> Однако, в наше время таки оптимизировать всё до последнего байта есть > непозволительная роскошь. Моё время как разработчика несравненно > дороже времени процессора и оперативной памяти.
Дайте я придумаю цитату: "Если разработчик экономит свое время, то он
тратит время своих пользователей".
> Пишите свои программы понятно, господа! Если использование показывает, > что память — узкое место, найдите 10% кода, которые используют 90% памяти.
Миф. Современные программы тормозят одинаково по всему коду.
Здравствуйте, GlebZ, Вы писали:
ie>>Действительно, мы сейчас живем в век дешевой техники и дорогой рабочей силы. Но экономя на поддержке и разработке многие, прежде всего заказчики и начальники, действительно портят программистов. Что однако не умоляет множество глупых и бездарных программ. GZ>Это не заказчики и начальники.
Ну не скажи.... Живой пример. Я попросил своего менеджера ежедневно выделять из моего рабочего времени 1 час на ревью кода вновь пришедшего. Ну не умеет новенький эффективный код писать и это не его вина, не научили еще. Нет же, и так в сроки можем не уложиться. Сдадим этап, тогда если(!) сильно тормозить будет, возможно(!), сделаем ревью... Вот так — если и возможно! А так — работает и пес с ней с эффективностью. Вот кто виноват? Скажи, пожалуйста.
В итоге — пора сдавать, а DataGrid ну уж очень тупит при отрисовке. Студент делал его раскрасску. Хочешь расскажу какой он код в DataGridColumnStyle.Paint напихал
ie>>Вот с архитектором в проекте очень даже повезло. Сейчас используется 5 ЯП с соответсвующими им технологиями. Я бы еще пол года назад сказал бы — да зачем мне какой-то там Питон, .NET форева. (Надеюсь больше меня эти мысли посещать не будут.) Все от начала до конца можно было сделать на .NET. Однако, прилили и C++, и Питон, и Ява Скритп, и Перл. Чего добились — думали: путаницы и неразберихи — оказалось: простоты и эффективноти! GZ>А вот это плохо. Смешивать питон с перлом.
Смотря что понимать под "смешивать". Если я не ошибаюсь Перл пришел из-за необходимости генерить Excel отчеты (могу ошибаться, сам в Перловую часть не разу не лазил). Ну нет в .NET средств эффективной генерации Excel отчетов. В Perl есть, взяли, прикрутили. Почему это плохо? Лично мне, да никому другому, не надо переключаться между всеми 5ю языками. Мне пока приходилось работать над ++ модулями и .NET. Понадобится лезть куда-то еще — есть проектная документация. Так что. А к Питону Перл никак не завязан.
GZ>Будь моя воля, я бы привел все к одному языку.
И я сначала тоже так хотел...
GZ>Очень трудно переключаться с одного языка на другой. Вроде бы очень похоже, и термины такие-же. Только дизайн программ весьма зависит от используемого языка. Есть языки которые от которых зависят выбранные технологии. Тут хочешь не хочешь надо. И это хорошо. Но если что-то можно сделать одним языком, то это нужно делать именно этим языком.
Ну вот тот же пример с тестом Павла. Он явно дает понять, что ++ код эффективней справляется с поставленной задачей. Так и сделать эту чать на ++, конечно, без фанатизма, если эта часть действительно критичная, а не бегать каждый раз делать на ++ все что там даст выйгрыш в скорости и использовании памяти.
GZ>С чего все началось. Началось с того, что к Net программам Павел начал приставлять свойства C++. Ну нет у него многих свойств С++. Точно также и нет многих свойств C# у С++. В результате, дизайн программ существенно различается. По форуму Net очень часто поступают вопросы, сквозь которого проступает C++. GZ>И данный пост Павла(которым он наконец разродился) именно связан с темой сравнения с С++.
Да, и это не может не огорчать. Вместо того чтоб спорить что же все таки лучше, общими усилиями написали бы статью, о том какие классы задач и их подзадач с помощью какой технологии эффективно решаются.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Минусов мне за эти тезисы поставят, это уж точно.
Что-то не видать.
Щас будет филосовское эссэ... Блииннн...
[...skipped...]
PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько PD>это возможно!
Этот вопрос не такой очевидный как кажется. Начать с того, что такое "программа для компьютера"? Какой-нибудь хитрый алгоритм кластеризации в многомерном пространстве — это программа. ICQ — это тоже программа. Но между ними существует фундаментальное различие, которое довольно трудно сформулировать четко и однозначно. Но безусловно то, что это это совершенно разные категории программ. Для пояснения задействуем очень сильное колдунство — О-нотацию. ICQ занимает, скажем 30 мег. Но это все равно O(1) памяти! И до тех пор, пока эта программа работает на 99.99% ширпотребовских компьютеров, нам глубоко пофигу, сколько конкретно пямяти она занимает — это все равно O(1), просто в силу того, что нет такого параметра, от которого бы измерялось это "О". Количество записей в контакт-листе? — нет, это копейки, которые можно вообще не считать (впрочем, это тоже не так-то просто, но об этом — делее).
Другое дело — некий алгоритм кластеризации (это я говорю чисто абстрактно, алгоритм может называться как угодно, скажем, "структурной оптимизации параметрического синтеза"). Он может требовать O(N^2) памяти. Например, для 10 точек — 100 байт памяти, для тысячи точек — уже 10 мег, а для миллиона точек не хватит и всей памяти всех компьютеров на земле.
К чему эти все абстрактные рассуждения? А вот к чему.
Всем людям хочется легких и больших денег. А большие деньги можно сделать только на чем-то очень массовом. А массовое это что? — программа ICQ, например. Или MS Office, whatever. И все эти программы (ну не все, но 99%) относятся к классу сложности O(1) по памяти. Теоретически, это мое утверждение конечно же ложно, но практически — это так. Это раньше было не так, например, когда текстовый редактор требовал O(N) оперативной памяти, а ее всего было 32K, то это был плохой редактор. Файл размером в 100K в нем было принципиально невозможно отредактировать. Требовался редактор класса O(1) оперативной памяти, который динамически работал с дисковой памятью. Как сейчас помню — KED, он же K52, адаптированный под систему команд терминала VT52, который подключался по RS232 на скорости 9600. То есть, реальный канал был менее килобайта в секунду — и это между компьютером и монитором!
После преодоления порога в 640K произошла фундаментальная метаморфоза: тот же текстовый редактор из класса O(N) превратился в класс O(1)! Это опять же, спорное утверждение, но на практике это так. Допустим, у нас есть редактор класса O(N), требующий 1 байт памяти на символ. В 32K памяти можно отредактировать 32K символов. В 640K — 640K символов. А сколько можно отредактировать в одном гигабайте памяти? А самое главное — кому это надо? Лично я не видел ни одного человека, которому бы понадобилось редактировать гиговый текстовый файл. Есть чисто человеческое ограничение — больше мега текста в 99.99% случаев редактировать не требуется. А что такое один мег при объеме памяти в гиг? Именно по причине этого человеческого фактора и появилась принципиальная возможность не заморачиваться такими вещами, как "ручной" динамический своп. Дальше больше — когда сам текстовый редактор с пустым окном занимает 30 мег, а при загрузке 100K текста — 31 мег, мы можем смело считать его редактором класса O(1) — нам никогда не понадобится редактировать такой текстовый файл, который бы существенно увеличил объем занимаемой памяти. А редакторы, ранее бывшие в классе O(1) стали просто не нужны, поскольку работают медленнее. Конечно же я утрирую, но лишь для пояснения идеи — стало можно писать сколько угодно кода, который гарантированно влезает в память. И при условии эффективного хранения данных основная масса программ не требует какой-либо экономии.
Но не тут-то было — сон разума рождает чудовищ. Эта "свобода" породила монстра — неэффективные структуры данных. Взять, например, тот же IE или Firefox. При открытиии ветки на РСДН в 1000 сообщений они отъедают около 10 мег памяти. Десять килобайт на заголовок сообщения! Да сами сообщения в разы меньше! И программы снова превратились в класс O(N). Теоретически. На практике, в 99% случаев можно считать, что они остаются O(1), просто потому, что в большинстве случаев нам не требуется просматривать 1000 сообщений (а если и требуется, то это — исключение). И вот здесь-то и кроется главная причина неэффективности — для получения прибыли достаточно обеспечить работоспособность в 99% случаев, а те, которые требуют большего — они перебьются. Они погоды не делают.
С точки зрения биснеса и легких денег, производители массового софта безусловно правы. Надо стремиться не к какой-то там гипотетической эффективности, а чтобы получить денег — вот здесь и сейчас. Но здесь кроется и главная засада: этот путь тупиковый — такой же, как и любая финансовая пирамида. Рано или поздно рухнет. Кто-то безусловно, на этом мощно заработал и продолжает зарабатывать и получать удовольствия от жизни. Вопрос — сколько это может продолжаться. Может быть долго. Но если не будет нового прорыва в железячной технологи, то коллапс неизбежен. Система является квази-устойчивой: стоит чуть толкнуть — и понеслать п... по кочкам.
И вот здесь мы подходим к главному вопросу — а в чем заключается это "удовольствие от жизни"? Вся индустрия mainstream-софта построена по принципу "американской мечты" — вот мы сейчас зафигачим, продадим, нарубим зеленой капусты, а потом будем всю жизнь "курить бамбук". Безусловно, кому-то это удается, точно так же, как есть шанс получить большие деньги в МЛМ-лохотроне. Другое отношение — это просто "поддерживать жизнедеятельность", то есть, работать на дядю за небольшую, но гарантированную зарплату (ничего не имею против этого — сам такой). Но лично мне и то и другое просто скучно. Мне гораздо интереснее думать — вот это для меня и есть по большому счету удовольствие. Конечно же, я тоже люблю деньги и тоже люблю кататься на доске по снегу с гор и тоже учавствую в этом лохотроне. И мой профессиональный рейтинг повышается, поскольку я стремлюсь к этому повышению. Но я все-таки опасаюсь, что это вся эта индустрия может рухнуть — такое уже было — помните дот-комы?
И именно поэтому я стремлюсь к написанию только эффективного кода. Во-первых, из чисто прагматических соображений. Я убежден (возможно ошибочно) в том, что мои инженерные навыки будут востребованы при любых катаклизмах в индустрии. Во-вторых, мне это просто по жизни нравится — заниматься нетривиальными задачами. Задачи класса O(1) мне неинтересны, хотя, надо признать именно они пока что и обеспечивают в основном мою жизнедеятельность (такова, брат, диалектика). Но я стремлюсь к некому кайфу в жизни — делать только эффективные вещи, интересные мне самому. И в-третьих, моя практика показывает, что это вполне возможно — оставаться в рамках того, что интересно мне и только мне (эффективный код и нетривиальные задачи) и при этом быть востребованным (я этого пока не достиг, но "есть тенденция").
Таким образом, вопрос о написании эффективного/неэффективного кода заключается в рисках и личном выборе этих рмсков. Мой риск — остаться вымершим динозавром. Риск индусов — остаться у разбитого корыта в случае падения рынка индустрии (не надо говорить, что это невозможно — это ОЧЕНЬ возможно). Все-таки, по совокупности факторов, я выбираю путь "динозавра". Индусы ничего не умеют кроме как дубасить мегатонны кривого кода. Я тоже это умею, хотя и не знаю все эти Java-дот-неты так как они знают. Но при этом я умею кое-чего еще, а именно — работать над задачами, сложнее класса O(1).
Не уверен, что моя позиция хороша. По крайней мере, я знаю, что эта ниша невелика и мне вряд ли удастся заработать большие деньги. Большие деньги в индустрии делаются на попсовом, кривом и глючном софте, пожирающем мегабайты. Period! Это никакой не сарказм, это просто факт — так устроен этот мир. Но если захотеть и не лениться, то это вполне реально — делать только эффективные и интересные вещи и при этом "выпивать-закусывать". Это не самый простой путь, но (цитируя Кастанеду), мне представляется, что это — путь с сердцем. А путь "чтоб просто работало" — это путь без сердца. Вот и вся разница. Большинство людей выбирает путь полегче — и они правы! — но это и есть причина того, что "the grass was greener, the taste was sweeter".
И нечего плакаться по поводу того, что "программы раздулись и тысячекратно замедлились". Лично для меня это является совершенно ортогональным фактором к моим интересам.
Надо так (цитата из Х.Забей, "Победил"):
Сражался как п...ц всему
Что было сил,
И выиграл войну.
И победил...
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> И действительно, как было не признать! Пока программа небольшая и в память PD>>помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и PD>>придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают. PD>>Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это PD>>не стирание EXE-файла во время его работы. Это когда программа во время своей PD>>работы использует память, занятую своими командами (которые уже отработали и PD>>больше не потребуются) под свои данные. GZ>У меня это называлось overlay.
Нет, оверлей — это нечто иное. Я этим на СМ-4 и ЕС-1022 занимался, это вполне легальное действие, даже ассемблер не требуется. А самоубийство только на ассемблере делалось, даже ИМХО не на ассемблере тогда, а просто в кодах.
PD>> Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello, PD>>World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите. GZ>Ты Турбо-Vision пользовался?
Немного.
GZ>Я тоже горячился когда оказалось что exe файл для Delphi был больше мега(сейчас не помню, но для тех времен очень много). Но то, что я мог мышью быстро собрать приложение и получить за него деньги перевешивало. Как программисту который уважает свое творчество, это плохо. А вот для человека который пытается на хлеб масло намазать, чрезвычайно хорошо.
GZ>NT 4.0 на 8 мегабайтах не работала, а обслуживала саму себя. И то, если сервис паки не ставить.
Ну пусть на 16
GZ>Так оно места то много не занимает. Оно действительно эффективно. А вот если говорить о сопутсвующих процессах, типа сервисов и т.д., или тех же картинок, то это и есть увеличение. С установкой сервис паков и добавления функциональности, ситуация выравнивается.
Чудно. А могу я эти сервисы безболезненно удалить, и освободить Мбайт так 50-60 ? Немного — получится, а остальные, увы, обязательны для системы. А мне, в общем, все равно, как это называется, ядро или сервисы, лишь бы занимали они поменьше.
GZ>Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват?
А какое это имеет отношение к тому, о чем я говорил ? Если машина загружена сверх ее реальных возможностей — конечно, ты не виноват. А вот если реальные возможности машины позволяют загрузить 10 копий твоей программы (без вордов и эксцелов), будь она эффективно написана, а она написана так, что и 3 копии тормозят — виноват ты.
Ты можешь сформулировать когда программу можно считать избыточной?
Попробую.
Программа избыточна, когда она
1. Использует памяти больше, чем требуется.
2. Загружает процессор больше, чем требуется.
3. Хранит на диске файлы большего размера, чем требуется.
А требуется — по характеру задачи.
PD>>Или вот другой пример — с умножением матриц GZ>Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.
Дошли до того, что здесь виной перегрузка в кэше оверхеда на класс массив.Но по мне хоть кэш, хоть процессор, хоть винчестер, хоть дух святой. Не желаю я причин знать , а просто факт констатирую — машина это может в несколько раз быстрее делать, значит и должна делать!
GZ>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.
Ничего у вас не получится. Потому что эти узкие места вы, может, и найдете, а вот общий уровень все равно с оверхедом будет. Там Мбайт, здесь Мбайт — в итоге 100 Мбайт и виновных нет.
PD>>Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно GZ>Жадные вы. Че вам памяти жалко? GZ>Во первых, ICQ — это глюк официально выходящий в альфа-бета видах. Притом накрученная функциональностей, которая особо никому и не нужна.
А у ICQ вообще когда-нибудь не-беты были ? У меня что-то впечатление такое, что она только из бет и состоит
GZ>Во-вторых, не стоит по одной-двух программах делать выводы о отрасли в целом. Во времена MSDOS, были свои глюкавые монстры.
Ну другие примеры уже привели, не буду повторяться.
PD>>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не PD>>слишком думая об эффективности, а потом узкие места можно оптимизировать. GZ>Подпишусь.
Имеешь право
GZ>Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы.
Пользователь доволен. Вполне. И если он у тебя один — решай с ним все проблемы. А вот когда речь о продуктах, используемых в миллионах копий идет — тут задавать вопрос, доволен ли пользователь — все равно, что спрашивать, оуениваете ли вы положительно работу ГосДумы . Отдельно одной программой доволен, другой — доволен, третьей доволен, все вместе запустишь — недоволен. Жалуйтесь кому хотите, хоть господу богу.
GZ>Аналогия неуместна. Важно насколько клиенту важно чтобы он летал. Зачастую заказывают атомную подводный крейсер, а тебе выкатят Ту155 с 5 подводными винтами. И вроде двигается быстрее чем нужно. И летает, что не заказывали. И вроде винты красивые и их больше чем нужно. Но не плавает. Ну не успели научить.
Бывает и такое. Как в известном анекдоте, как ни собираю, а пулемет получается. Но почему аналогия неуместна — не понял.
GZ>Не согласен. Уже вверх перестали развиваться такими темпами. Зато начали развиваться вширь.(двухядерные процы)
Я же не утверждаю, что я прав. Дай бог, чтобы я неправ в этом был.
GZ>А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.
Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> И вот тогда этот неэффективный стиль программирования даст себя знать! PD>Сейчас можно просто рассуждать — чего я буду 20 Мбайт экономить, если PD>пользователь без проблем 256 может докупить ? А вот когда опять в жестких PD>лимитах работать придется — окажется, что некоторые программы, которые вполне PD>могли бы быть написаны, написаны не будут, или же будут написаны лет через 10 PD>после того момента, когда они могли бы появиться! Потому что эффективно PD>работать большинство не умеет. Привычки у них такие — что нам стоит лишних PD>десяток Мбайт взять!
Научить обычного, не озабоченного "оптимизацией-везде-где-можно" программиста оптимизировать программы куда проще, чем научить "байтовыжимателя" писать нормальный и понятный код. Потому что второй всегда будет искать, как в .NET обнулить поля структуры с помощью ZeroMemory (да-да, это намек ) — вместо того, чтобы проектировать архитектуру. Да еще и считать окружающих идиотами, потому что они не понимают, как же это важно — обязательно залезть на нижний уровень по самый локоть.
Здравствуйте, Dyoma, Вы писали:
D>А как вам вот такой тезис, что программа просто должна быть достаточно xxx? D>Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать;
Если бы мы были в однопрограммной системе — готов согласиться. А в многопрограммной — нет. Потому как отдельная программа может быть вполне достаточна, а все вместе они едят ресурсов немеряно и тормозят.
Кстати, сформулируй критерий достаточности, если можешь.
D>Я ни в коем случае не призываю не думать об эффективности, не искать всегда и везде лучшие подходы и алгоритмы. Я предлагаю не думать об этом больше/чаще, чем о, например, удобстве UI или чистоте и последовательности архитектуры.
Удобство UI прямого отношения к эффективности обычно не имеет. А вот чистота и последовательность архитектуры отнюдь не требует применения неэффективных методов. Скорее наоборот — скажи кратко, но хорошо (К. Прутков)
Ответили мне многие. Всем спасибо за обсуждение. К сожалению, не могу ответить всем, да это и не надо, пусть дискуссия идет своим чередом.
Но вот одно либо я недостаточно четко изложил, либо меня не поняли, либо не хотели понять. Я не призыаваю к тотальной оптимизации, это просто глупо, в конце концов. И те, кто меня в этом упрекают, зря стучатся в открытую дверь. Я выступаю за то, чтобы код на своем уровне писался эффективно. Чтобы не использовались явно избыточные по памяти или времени конструкции, когда это совсем не обязательно и вполне ясно, как без них обойтись, отнюдь не поступаясь при этом ясностью и четкостью.
И если интструмент спроектирован так, что он мне неизбыточное кодирование делать не дает, а заставляет или хотя бы толкает на это избыточное исходя из того, что нечего эти ресурсы экономить — вот с этим я и не согласен.
Здравствуйте, Дарней, Вы писали:
Д>Научить обычного, не озабоченного "оптимизацией-везде-где-можно" программиста оптимизировать программы куда проще, чем научить "байтовыжимателя" писать нормальный и понятный код. Потому что второй всегда будет искать, как в .NET обнулить поля структуры с помощью ZeroMemory (да-да, это намек ) — вместо того, чтобы проектировать архитектуру. Да еще и считать окружающих идиотами, потому что они не понимают, как же это важно — обязательно залезть на нижний уровень по самый локоть.
Не согласен. Я бы сказал, что это вещи вещи независимые — "этого научить проще тому-то, чем вот этого — противоположному". Здесь главное — чтобы человек обладал некими общими инженерными навыками. Фишка в том, что если человек умеет оперировать байтами в памяти, он как минимум знает, как устроен компьютер. И если он является инженером по своей сущности, то он очень быстро поймет, почему этого не надо делать в дот-нет. И наоборот, если человек начал с дот-нет, но при этом он обладает некими инженерными знаниями, он очень быстро разберется в том, как надо делать эффективно. Встречаются упертые личности — одни на ASM, другие — на C#, но они — не инженеры. И вопрос переучивания — он больше психологический чем технический. Если человек является инженером по своей психологии, то он переучивается легко — хоть туда, хоть сюда. Если же это для него туго, то наилучший способ его задействовать — это поставить на ковейер — пусть работает как машина Тьюринга и выполняет команды. Не хочет? — ну и ладно, найдем другого. Все это и ко мне тоже относится — так что просьба не принимать на личный счет.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Не, ну по поводу word-а все как раз очевидно. Там уже столько всего наколбашено и до такой степени криво, что что-либо переделовать по большому счету они сами боятся. Да и нужды нет.
А вообще — мы говорим о немного разных вещах. Есть время и место для низкоуровневых технологий. Так же, как есть время и место для оптимизации.
И то и другое (по моим представлениям) состовляет ну никак не больше 10% от всех нужд.
И как бы "хардкорщикам" не хотелось обратного, но большая часть рынка и большая часть программистов — это прикладники. Т.е. ваши аргументы просто пролитают мимо меня со скоростью пули."Вот мы писали драйвер и Java оказалась слабовата". Ну да. И что?
Поддержка офисом Net'а уже давно есть. Даже и без нее можно работать Com'ом. OLE2 давно умерла, остались ActiveX. Поддержка его(кривая правда) но все таки есть.
Ну не успели научить.
