Здравствуйте, vdimas, Вы писали:
V>Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
V>Ключевая фраза: "ничего не стоит".
Бесплатный сыр бывает только в мышеловках.
V>Ну представь хоть на секунду, что в стремлении выпустить, например, новую Тойоту на рынок, с новыми, прямо-таки космическими внешними обводами, фирма Тойота пошла на следующие допущения: V>- Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора V>- Топлива она жрет в 2 раза больше V>)
Как уже надоели кривые аналогии. Причины раздувания современного ПО отнюдь не в космических формах, а совсем даже в функционале и надежности. Рынок автостроения здесь плохая аналогия, поскольку все что можно из текущей технологии уже выжали и производителям ничего не остается кроме как вылизывать существующие модели. Если кто то сможет сказать новое слово в плане надежности или функционала при условии приемлемых остальных основных характеристик, то он подомнет под себя львиную долю рынка. На рынке ПО такое пока возможно прежде всего благодаря растущим вычислительным мощностям (а совсем не кривотой самой отрасли, как предполагаешь ты). Остановится рост мощностей, начнут вылизывать существующий софт.
V>Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
Тем не менее разница между теперешними моделями и моделями пускай 5-тилетней давности в этом плане ничтожна. Индустрия автопрома точно так же высасывает деньги из покупателей, только у них приемы другие — продать то же самое в новой, более модной обертке. С технической точки зрения мода на дизайн, заставляющая производителей чуть ли не каждый год менять модельную линейку является форменным идиотизмом. В IT выхлоп от прогресса все таки поощутимее (и, кстати, именно он дал возможность автопрому хоть как то улучшить функционал и надежность).
V>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
Боюсь, не просто не уступающими, но и значительно превосходящими.
V>Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие. А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило. Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати). А у нового поколения — ни стыда ни совести по отношению к ресурсам аппаратуры или сети.
Я почему то вижу прямо обратное. Если человек пишетоткровенно тормозной код на ровном месте, то обычно у него без этого масса проблем. Такого чтобы человек превосходно проектировал и писал код без багов, но при этом не умел оптимизировать по производительности я еще ни разу не встречал. Так не воюете ли вы с ветряными мельницами?
V>Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
Из этого можно сделать ровно один вывод — серебряных пуль не быват. О вреде паттернов это не говорит никоим образом. Влад вон тоже в свое время активно был против них и считал их костылями для ламеров. Однако ж стоило попробовать и ...
Вобще, как это не странно, паттерны это не столько что то новое собственно в готовых проектных решениях, сколько очень удобный инструмент обучения и коммуникаций. К примеру, решение, описанное в терминах паттернов, выглядит заметно короче и понятнее, чем если без них, ибо стандартные паттерны это суть алфавит проектировщика.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, IT, Вы писали:
VD>>Предположим завтра тебя попросят написать программу или сайт для хранения и поиска поворских рецептов (ну, скажут, что дадут лимон баксов, а работы там не неделю...). Неуже ли ты из-за этого по быстрому в повора переквалифицируешся?
IT>В повора нет, но свои рецепты там хранить буду
Хорошая идея ...
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, IT, Вы писали:
IT>Я же говорю, мы с тобой о разном. Я буду заниматься оптимизацией процессов, которые нужны пользователю, потому что я сам пользователь. Не пытаюсь прикинуться, а именно сам пользователь и есть.
Нет. Нет и нет. Невозможно построить такую же систему как и у заказчика. Такую систему можно сделать в небольшом количестве решений, но не в большинстве. И бизнес-процессы разные, и система не отделывается от лейбла тестируемой. Разработчик в роли пользователя оперирует человеко-часами и знаниями системы. Ему ничего не стоит в том или ином случае воспользоваться этими знаниями. И если ему что-то неудобно, то у него есть отмазка в виде человекочасов. Пользователи на это меньше обращают внимание.
Как тебе такие примеры из жизни:
Поставили себе систему. Оттестировали. Вроде работает, и работает эффективно. Ставим пользователю — нарекания. У нас было 2-3 сотни объектов. У него несколько миллионов. Хорошо, взяли от него базу. Но только вопрос в том, что база не берется одна к одному. В ней заменяется вся коммерч. информация суррогатными данными. В результате, статистика базы неверна, и проследить планы запросов почти невозможно.
Или другой пример. Юзаем систему, эмулируем бизнес-процесс. Один отчет создается от 2-4 часов. Плохо. Не будет же пользователь ждать 2-4 часа каждый раз. А отчет нам кажется для выстроенного бизнес-процесса важным. Тратим кучу человекочасов на оптимизацию. Переписываем значительную часть кода. Делаем его более расширяемым, чтобы подцеплять для других отчетов. Сообщаем заказчику о том, что сделали, ставим update. На следующий день заказчик звонит и говорит, дескать вы бы сначало нас спросили нужно ли делать этот отчет. По ихнему бизнес-процессу, этот отчет будут делать ну минимум раз в полгода. И если начальник почешется и вспомнит. Поэтому 2-4 часа можно было бы и потерпеть. К тому же, на той кластерной системе время было значительно меньше. А вот избыточную нагрузку на сервера БД возникшую после оптимизации — терпеть не будут. Откатили. Потеряли на пустом месте деньги, силы и время. А вопрос был только в том, чтобы сделать один звонок и спросить у пользователей.
Поэтому нет правды у разработчиков. Ну нельзя предугадать что будет твориться у пользователей. Задача разработчика помочь высказать идеи и реализовать их. Но ни в коем случае не подменять пользователей собою.
Здравствуйте, IT, Вы писали:
VD>>Предположим завтра тебя попросят написать программу или сайт для хранения и поиска поворских рецептов (ну, скажут, что дадут лимон баксов, а работы там не неделю...). Неуже ли ты из-за этого по быстрому в повора переквалифицируешся?
IT>В повора нет, но свои рецепты там хранить буду
Самогон?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Влад, твои слова: "я в те времена намерено отказался от 'буферизации'" выглядят совершенно не убедительно, т.к. ты сам несколько раз подчеркивал, что опыта у тебя на тот момент практически не было.
Понимаш ли. Мне не в чем тебя убеждать. Я тебе рассказываю как дело было. Я может быть уже не помню технические детали, но суть вопроса мне очень хорошо врезалась в память.
E>Вот ты бесишься, что народ не понимает, что оптимизировать нужно только то, что нужно и только на основании точных оценок.
Я не бушусь. Я сожалею и грущу.
E>Но ты и сам пойми, что оптимизация, выполненная не профессионалом -- это страшная штука. Практически тоже самое, что бесполезная или бестолковая оптимизация.
Оптимизация может быть полезной, бесполезной и вредной. Кто ее делает значения не имеет. Я же делился опытом и выводами сделанными из этого опыта. То что у некоторых проффесионалов выводы из этого рассказа постоянно сбиваются на обсуждение технических подробностей все же не моя вина, а их беда.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Снимаю шляпу перед Pavl-ом Dvorkin-ым. При всем моем несогласии с его мировозрением, писать он умеет убедительнее. Даже те кто, как оказалось, скорее стоит на одних позициях со мной поддержали его зажигательные речи.
Здравствуйте, VladD2, Вы писали:
E>>Влад, твои слова: "я в те времена намерено отказался от 'буферизации'" выглядят совершенно не убедительно, т.к. ты сам несколько раз подчеркивал, что опыта у тебя на тот момент практически не было.
VD>Понимаш ли. Мне не в чем тебя убеждать. Я тебе рассказываю как дело было. Я может быть уже не помню технические детали, но суть вопроса мне очень хорошо врезалась в память.
Влад, да меня не нужно убеждать, на самом деле я не так далек от твоей точки зрения, как тебе кажется (см., например, МКЭ в моей судьбе :)
). Я о том, что твоя позиция выглядит неубедительно как раз из-за этого фактора.
E>>Вот ты бесишься, что народ не понимает, что оптимизировать нужно только то, что нужно и только на основании точных оценок.
VD>Я не бушусь. Я сожалею и грущу.
Ну и зря, время само все по местам расставит.
E>>Но ты и сам пойми, что оптимизация, выполненная не профессионалом -- это страшная штука. Практически тоже самое, что бесполезная или бестолковая оптимизация.
VD>Оптимизация может быть полезной, бесполезной и вредной. Кто ее делает значения не имеет. Я же делился опытом и выводами сделанными из этого опыта. То что у некоторых проффесионалов выводы из этого рассказа постоянно сбиваются на обсуждение технических подробностей все же не моя вина, а их беда.
Мне кажется, что проблема твоего поста была в том, что для благой цели были выбраны не удачные средства. В то же время у Павла Дворкина средство оказалось даже лучше (значимее), чем преследуемая им цель. Но, в отличии от тебя, я придаю важное значение "оформлению" идей автора того или иного поста. Это как борьба Microsoft Windows и IBM OS/2. Целью обоих было создание ОС следующего поколения для PC. У M$ был корявенький продукт (цель), но отличный маркетинг (средства). А у IBM -- с точностью до наоборот. Результат всем известен.
По-моему, вы оба затронули две важнейшие тенденции. Павел -- о том, что внимание к элементарной эффективности на уровне написания кода падает. Пример тому: Смотрел на Java код. ...много думал.
Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &. В подавляющем большинстве случаев это уже даст необходимый прирост производительности. Хотя даже такая немудреная оптимизация уже содержит несколько неприятных подводных камней, про которые нужно знать, например:
const std::string & do_something( const std::string & title, const std::string & chapter )
{ ... return title; }
const std::string & processing_result = do_something( "I Love This Game!", "Long, long time ago..." );
processing_result.length(); // Бамс!!!
Так вот смысл высказываний Павла я вижу в том, чтобы научить разработчиков пользоваться подобными элементарными приемами оптимизации и понимать, что за этим может стоять. Смею тебя уверить, что многие начинающие C++ программисты очень долго не могут привыкнуть к тому, чтобы передавать сложные объекты как параметры через ссылки.
Смысл же твоего высказывания я вижу в том, что в современных условиях совершенно нет необходимости выходить дальше элементарной оптимизации (примеры которой я только что привел) или, что еще хуже, пренебрегать безопасностью в погоне за эфимерным выигрышем. Если кто-то сейчас использует для форматирования сложного выражения sprintf вместо std::ostringstream, то это как раз проявление того эффекта, о котором ты, имхо, и говоришь. Ведь все начинается с малого. Сначала sprintf вместо std::ostringstream (просто потому, что sprintf кажется эффективнее) даже без подсчета количества обращений к sprintf -- их может оказаться настолько ничтожно мало, что выигрыш будет на два порядка меньше, чем статистическая погрешность измерений скорости работы программы. Дальше больше -- выбор кажущихся более эффективными алгоритмов априори, без реальной оценки ситуации. Ну и дальше еще больше -- выбор неправильных архитектурных решений или неверная расстановка приоритетов при планировании работ по проекту. А все начинается с казалось бы безобидного выбора в пользу sprintf.
Так что, имхо, вы оба правы, но каждый говорит о крайних проявлениях. А истина, она где-то посередине. Или вообще в другой стороне.
Извини, если я опять тебя не правильно понял.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
VD>>Именно это я вижу в его примерах и словах. Там явным образом прослеживается натуральная борьба с абстракциями. Ведь за них нужно латаить. Заметь у него в коде ни разу не появился ни один строковый класс. В коде сплошные сишные строки размещаемые исключительно в стеке. А ведь по его же словам приводимый им код написан на С++.
V>Знаешь, когда я писал лексические анализаторы, я тоже не пользовался классами строк, и тоже активно использовал стек. При определенной аккуратности лекго исключаются возможности прохода по стеку. Обяснить как?
V>Т.е., повторю, в отрыве от контекста доказывать свою правоту бесполезно. Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает, но, может он это делает специально, в ответ полное пренебрежение к этому вопросу у окружающего мира?
Не совсем так. Специально, я конечно, это не делаю. Кстати, на вопрос, почему я в примерах из своего проекта не использую string и т.д. ответ очень простой — проект делался на чистом С. Мне это активно не нравилось, но я вошел в проект, когда он уже существовал и изменить ничего не мог.
А вот чего я не понимаю — почему некоторые упорно приписывают мне то, чего я не говорил ? Я говорю, что надо писать эффекктивно — мне отвечают "он призывает писать эффективно любой ценой". Я ничего вообще о дизайне и архитектуре не говорил — у меня, оказывается, натуральная борьба с абстракциями. Покажите мне место, где я призывал "любой ценой"
Увы, существует два способа спорить. Один — для того, чтобы попытаться найти истину. Другой — чтобы победить в споре любой ценой. При этом используются явные передергивания, приписывание оппоненту того, что он не говорил и т.д. В общем, что тут объяснять — PR-технологии у всех на глазах.
V>(уффф, чтоб меня так чужие оценки беспокоили...)
V>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность.
FR>Игры понятие очень растяжимое, но сейчас больше 80% рынка игр это приставки, а это в некторых аспектах похлеще контролеров,(ситуация такая что аппаратура неизменна а требования к программам все выше и выше) и битовыжимание там нормальная практика.
Это ты случайно не про PlayStation 3? Который вроде как 2 HDTV потока может одновременно декомпрессить, а стандартного MPEG — так под 1000 видеопотоков? Я презенташечку бегло так посмотрел — дык десктопы лет через пять только догнать эту железяку смогут.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
FR>>Игры понятие очень растяжимое, но сейчас больше 80% рынка игр это приставки, а это в некторых аспектах похлеще контролеров,(ситуация такая что аппаратура неизменна а требования к программам все выше и выше) и битовыжимание там нормальная практика. S>Это ты случайно не про PlayStation 3? Который вроде как 2 HDTV потока может одновременно декомпрессить, а стандартного MPEG — так под 1000 видеопотоков? Я презенташечку бегло так посмотрел — дык десктопы лет через пять только догнать эту железяку смогут.
Я про PlayStation 2 про который тоже говорили что PC их долго не догонит, это долго длилось только два года. И под этот PS2 еще года три будут активно разрабатывать игры, так просто от 100 миллионов проданных устройств не отмахнутся.
Если же говорить про PS3 то надо внимательней читать презентации (где почти все чистый пиар, даже ролики там были предрендереные, а если подсчитать производительность любой современной видеокарты по их методике тоже получатся терафлопсы ) и смотреть тех. характеристики, и можно увидеть что памяти там всего 256 Mb (не ресурс?) она снова таки не виртуальна, а процессор это Cell оптимально программировать под который без выкрутасов не получится.
Здравствуйте, FR, Вы писали: FR>Я про PlayStation 2 про который тоже говорили что PC их долго не догонит, это долго длилось только два года. И под этот PS2 еще года три будут активно разрабатывать игры, так просто от 100 миллионов проданных устройств не отмахнутся. FR>Если же говорить про PS3 то надо внимательней читать презентации (где почти все чистый пиар, даже ролики там были предрендереные,
Я их увы, не читал. Только смотрел. И как-то слабо верится в то, что демонстрашка прямого управления 3d объектами предрендеренная. Что касается супергеймов — это да. Возможен и пререндеринг. Хотя я в этом сомневаюсь — у парней бы оторвали все лишнее, если бы демка нового GPU случайно оказалась невоспроизводима на реальном железе. Это ж не писюк, где все можно списать на корявую сборку, некошерную память и прочие пуговки. Все легко проверяется.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
FR>>Если же говорить про PS3 то надо внимательней читать презентации (где почти все чистый пиар, даже ролики там были предрендереные, S>Я их увы, не читал. Только смотрел. И как-то слабо верится в то, что демонстрашка прямого управления 3d объектами предрендеренная. Что касается супергеймов — это да. Возможен и пререндеринг. Хотя я в этом сомневаюсь — у парней бы оторвали все лишнее, если бы демка нового GPU случайно оказалась невоспроизводима на реальном железе. Это ж не писюк, где все можно списать на корявую сборку, некошерную память и прочие пуговки. Все легко проверяется.
Ну я тоже смотрел Знакомые художники говорят что демки игр нарисованы. Да и простое сравнение с демками от XBOX 360 в котором железки примерно того же уровня показывает, что все таки нарисовали. У Сони никто ничего оторвать не сможет она на этом рынке как ms на pc'ишном
Да и графическую карту что будет на PS3 (nVidia RSX) чудом техники не назовешь, Nvidia говорит что она шустрее чем пара (через SLI) GeForce 6800 Ultra , а это значит что скорее всего уже следующим летом топовые карты на PC уже обгонят nVidia RSX.
Здравствуйте, eao197, Вы писали:
E>Мне кажется, что проблема твоего поста была в том, что для благой цели были выбраны не удачные средства.
С этого момента можно по подробнее.
E> Это как борьба Microsoft Windows и IBM OS/2. Целью обоих было создание ОС следующего поколения для PC. У M$ был корявенький продукт (цель), но отличный маркетинг (средства). А у IBM -- с точностью до наоборот. Результат всем известен.
Аналогия не то что бы не уместна, она просто неверна, ну, или хотя бы спорна. Опять втягиваемся в религиозные возйны, но все же скажу пару слов. IBM OS/2 — это доработка MS OS/2. Другими словами OS/2 разрабатывал МС. Так вот в МС поняли, что OS/2 не является продуктом который требует рынок. Другими совами OS/2 не оптимальна для пользователя. Тогда МС начала разработку NT. NT оказался продуктом бескомпромисным, в отличии от OS/2 и намного более перспективным, но на то время NT была еще более неприемлема для пользователей. Тогда МС создала проект Чикаго (будующую Вынь 95). Его суть была скрещивание Windows 3.11 и Windows NT. Зазача быал — впихнуть максимум возможностей NT в ОС имеющюю намного меньшие потребности в ресустах и намного большую совместимось с 16-битным миром. Главное что пропихнул МС в Чикагу — это Win32 ATI. Конечно существовал Win32S, но в нем было реализовано уж очень мало нужных вещей. Причем и те что были реализованы — эмулировались. Второе по важности было введение изолированных адресных пространств. Для императивных языков того поколения это было очень важное нововведение. Дале шли многопоточность и красивый UI.
Конечно последние версии ОС тоже реализовали многое из того что решали проекты NT и Чикаго, но:
1. В полном объеме все фишки появились слишком поздно.
2. Полуось была компромисом — не такая надежная как NT и не такая неприхотливая к ресурсам, и (что намного важнее) не такая совместимая с Windows 3.1 как Чикаго.
В купе с намного более дружественным инсталлятором и конфигурацией эти ОС таки выиграли технологичесую гонку. А маркетинг... Он не маловажен, но люди не приняли бы такую важную вещь как ОС только на одном обмане.
Соственно сказал я об этом потому что вижу здесь очень похожие ошибки в логических рассуждениях, что и в осбуждении проблем производительности. "Хочется" заменят анализ фактов и холоднокровное вынесение суждений.
E>По-моему, вы оба затронули две важнейшие тенденции. Павел -- о том, что внимание к элементарной эффективности на уровне написания кода падает.
Плохой пример. Вырван из контекста и опять таки без реального анализа того какие оптимизации что дали бы. Думаю, что большинство рассуждения о проблемах этого кода чистый воды безсоновательный треп.
Ну, и главное. Если этот код являетс проблемой, то его можно просто переписать более эффективно когда в том появится реальная необходимость. Т.е. это случай когда нужно выполнить этап оптимизации. Думаю, в программе откуда был вырван этот кусок кода есть множество других место написанных более не оптимально. Но эти места проблем не создают. Так что опять таки о чем разговор? Нашел проблему? Устрани ее. А разжевывать сопли бья себя пяткой в грудь и крича "куда катится индустрия" не надо. Индустрия намного более размунее таких вот крикунов. Она подчиняется законма рынка и самобалансируется.
E> Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &.
Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая. Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
Например, погляди как реализован CString в MFC. Сам объект содеражит только ссылку на динамически занимаемый блок памяти. Все остальное в этом блоке. Передача CString в качестве параметра и даже возврат его из функции — это самое верное решение как с точки зрения производительности, так и с точки зрения удобства использования.
E> В подавляющем большинстве случаев это уже даст необходимый прирост производительности.
Как раз в подавляющем большинстве случаев — это ничено не даст. Ну, кроме глупой самоуверенности тому кто это делает.
E>Так вот смысл высказываний Павла я вижу в том, чтобы научить разработчиков пользоваться подобными элементарными приемами оптимизации и понимать, что за этим может стоять. Смею тебя уверить, что многие начинающие C++ программисты очень долго не могут привыкнуть к тому, чтобы передавать сложные объекты как параметры через ссылки.
Разработчик должен набираться опыта. Когда опыт у него уже будет, он и без умных советов сможет понять что более приемлемо, а что нет. Знании эти должны быть систематизированы и получены из надежных источников, а не браться из умозрительных предположений.
E>Смысл же твоего высказывания я вижу в том, что в современных условиях совершенно нет необходимости выходить дальше элементарной оптимизации (примеры которой я только что привел) или, что еще хуже, пренебрегать безопасностью в погоне за эфимерным выигрышем. Если кто-то сейчас использует для форматирования сложного выражения sprintf вместо std::ostringstream, то это как раз проявление того эффекта, о котором ты, имхо, и говоришь.
Вообще-то я говорил о другом. Я говорил, о том, что надо знать что делашь, и не делать ничего просто так.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Мне кажется, что проблема твоего поста была в том, что для благой цели были выбраны не удачные средства.
VD>С этого момента можно по подробнее.
А чего тут подробнее? Я уже несколько раз об этом говорил. Ты привел в качестве примера свой опыт на тот момент, когда ты и программировать-то нормально не умел (по твоим же словам). А следовательно (для меня лично) -- грош цена этому опыту.
Да и ты сам сказал:
Вообще-то я говорил о другом. Я говорил, о том, что надо знать что делашь, и не делать ничего просто так.
Так вот, делая вторую или третью программу в своей жизни, сложно знать "что делаешь".
Ну об этом мы уже говорили.
E>> Это как борьба Microsoft Windows и IBM OS/2. Целью обоих было создание ОС следующего поколения для PC. У M$ был корявенький продукт (цель), но отличный маркетинг (средства). А у IBM -- с точностью до наоборот. Результат всем известен.
VD>Аналогия не то что бы не уместна, она просто неверна, ну, или хотя бы спорна. Опять втягиваемся в религиозные возйны, но все же скажу пару слов. IBM OS/2 — это доработка MS OS/2. Другими словами OS/2 разрабатывал МС.
Не так уж и долго MC разрабатывал OS/2. Уже OS/2 2.0 IBM доделывала без MC, а уж OS/2 3.0 и OS/2 4.0 были сделаны вообще без МС.
VD> Так вот в МС поняли, что OS/2 не является продуктом который требует рынок. Другими совами OS/2 не оптимальна для пользователя. Тогда МС начала разработку NT. NT оказался продуктом бескомпромисным, в отличии от OS/2 и намного более перспективным, но на то время NT была еще более неприемлема для пользователей. Тогда МС создала проект Чикаго (будующую Вынь 95). Его суть была скрещивание Windows 3.11 и Windows NT. Зазача быал — впихнуть максимум возможностей NT в ОС имеющюю намного меньшие потребности в ресустах и намного большую совместимось с 16-битным миром. Главное что пропихнул МС в Чикагу — это Win32 ATI. Конечно существовал Win32S, но в нем было реализовано уж очень мало нужных вещей. Причем и те что были реализованы — эмулировались. Второе по важности было введение изолированных адресных пространств. Для императивных языков того поколения это было очень важное нововведение. Дале шли многопоточность и красивый UI.
Так об этом я и говорил. Обе корпорации хотели сделать продукт следующего уровня для PC. Только MC отталкивалась от нужд пользователей и поэтому смогла привлечь к себе разработчиков ПО. А вот IBM, видимо, расчитывала на стройность архитектуры, но нужды пользователей были им фиолетовы. Уж не знаю как, но IBM не удалось привлечь разработчиков ПО. Может из-за того, что в Presentation Manager координаты откладывались от нижнего левого угла? Из-за этого мне было лично мне было геморройно Windows-код в PM портировать.
VD>Конечно последние версии ОС тоже реализовали многое из того что решали проекты NT и Чикаго, но: VD>1. В полном объеме все фишки появились слишком поздно. VD>2. Полуось была компромисом — не такая надежная как NT и не такая неприхотливая к ресурсам, и (что намного важнее) не такая совместимая с Windows 3.1 как Чикаго.
Не надо мне-то байки про ненадежность OS/2 рассказывать. Она падала только из-за кривых драйверов (как и NT). Ну и Watcom-овский отладчик пару раз у меня OS/2 повесил. Так что надежность Warp-а была ничуть не хуже NT.
E>> Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &.
VD>Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая. Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
ДА-А-А? Ну-ну. Примеры в студию, пожалуйста.
Но об этом в отдельном посте.
VD>Например, погляди как реализован CString в MFC. Сам объект содеражит только ссылку на динамически занимаемый блок памяти. Все остальное в этом блоке. Передача CString в качестве параметра и даже возврат его из функции — это самое верное решение как с точки зрения производительности, так и с точки зрения удобства использования.
И многопоточности, надо полагать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Да и графическую карту что будет на PS3 (nVidia RSX) чудом техники не назовешь, Nvidia говорит что она шустрее чем пара (через SLI) GeForce 6800 Ultra , а это значит что скорее всего уже следующим летом топовые карты на PC уже обгонят nVidia RSX.
Вроде как GeForce 7800 GTX уже быстрее двух ульр. От этого SLI толку почти нет. Вот может у ATI что выйдет. Хотя до Voodoo 2 SLI они вряд ли дотянут. Та почти удваивала скорость.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, на вопрос, почему я в примерах из своего проекта не использую string и т.д. ответ очень простой — проект делался на чистом С. Мне это активно не нравилось, но я вошел в проект, когда он уже существовал и изменить ничего не мог.
А причем тут проект? Речь шала о примерах на голом С под названием С++.
PD>А вот чего я не понимаю — почему некоторые упорно приписывают мне то, чего я не говорил ? Я говорю, что надо писать эффекктивно — мне отвечают "он призывает писать эффективно любой ценой". Я ничего вообще о дизайне и архитектуре не говорил — у меня, оказывается, натуральная борьба с абстракциями. Покажите мне место, где я призывал "любой ценой"
Глядя на примеры все становится ясно и без призывов. Достаточно объяснить, что строки в донтете сакс подкрепив примером в стиле С с буферами на стэке и все будет ясно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>>Очень поучительная иллюстрация к тому, что по-байтово считывать из файла действительно не стиот.
L>2VladD2: Задам столь любимый тобою вопрос. А минус-то за что?
За повторение глупости.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
