Здравствуйте, eao197, Вы писали:
E>В server-side приложениях, которые обрабатывают сотни тысяч (всего лишь) транзакций в сутки эта величина легко достигается только лишь одной подсистемой логирования.
Сотри тысяч? Гы-гы. Делим 100 000 на 24 == 4166. Делим еще на 60 == 70. Делим еще на 60 получается по транзацкии в секунду. Вспоминмаем что дает один вызов — 0.15 микросекнуд. То есть чтобы заметно затормозить сервер нам потребуется вызвать таую функцию в цигле ни как не менее 100 000 раз. Думашь это реальный сценарий?
А ведь сервер с сотнями тысяч транзаций — это скорее всего мрогопроцессорный сервер.
E>За десктом не скажу, давно уже не писал. А вот то, что не POD-объекты (да и большие POD-объекты так же) нужно передавать по ссылке -- об этом нужно учить C++ программистов с детства.
Большие само собой. Но есть же и POD-ы размером с указатель? Учитывая еще архитектуру процессора вряд ли разбросннаые по всему приложению обхекты дадут ускорение. Пара промахов в кэше и ты получишь такой кайф от своих укзателей...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>На самом деле уже существуют вполне себе корректно составленные правила хорошего тона по кодированию на разных языках. Прямо в MSDN можно найти советы по VB, VB.Net, C#, C++. И не надо самому набираться опыта, претендующий на роль программиста на выбранном языке должен их просто изучить и понять (если сам еще не дошел своим опытом).
Несоменно, но я не уверен что это надо воспринимать как оптимизацию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
? Оптимизацией нужно заниматься тогда и только тогда, когда это часть non-functional requirements. В противном случае линейкой по рукам.
FR>Я думаю бесполезно дальше говорить на эту тему, просто если бы ты почитал чуть выше, то понял бы что я писал именно про случай когда быстродействие (а не оптимизация) это основное требование.
Т.е. это non-functional requirements?
FR>И если у вас нет подобных задач это не повод все выстраивать только на своем опыте.
Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
Здравствуйте, VladD2, Вы писали:
E>>В server-side приложениях, которые обрабатывают сотни тысяч (всего лишь) транзакций в сутки эта величина легко достигается только лишь одной подсистемой логирования.
VD>Сотри тысяч? Гы-гы. Делим 100 000 на 24 == 4166. Делим еще на 60 == 70. Делим еще на 60 получается по транзацкии в секунду. Вспоминмаем что дает один вызов — 0.15 микросекнуд. То есть чтобы заметно затормозить сервер нам потребуется вызвать таую функцию в цигле ни как не менее 100 000 раз. Думашь это реальный сценарий?
Думаю, что вполне реальный. Поскольку транзакции распределяются не равномерно. Существуют т.н. часы-пик, когда транзакции будут валиться сотнями в секунду. Кроме того, почему ты думаешь, что обработка одной транзакции -- это элементарная операция? Сама обработка может быть весьма не тривиальной задачей.
VD>А ведь сервер с сотнями тысяч транзаций — это скорее всего мрогопроцессорный сервер.
Это для Java и C# уже протребуется многопроцессорный сервер
А для C++ обычный, однопроцессорный, класса P4 2GHz прекрасно справляется. И даже в часы пик запас прочности солидный остается.
E>>За десктом не скажу, давно уже не писал. А вот то, что не POD-объекты (да и большие POD-объекты так же) нужно передавать по ссылке -- об этом нужно учить C++ программистов с детства.
VD>Большие само собой. Но есть же и POD-ы размером с указатель? Учитывая еще архитектуру процессора вряд ли разбросннаые по всему приложению обхекты дадут ускорение. Пара промахов в кэше и ты получишь такой кайф от своих укзателей...
Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти. А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, IT, Вы писали:
IT>>Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
FR>Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
Да но для начала нужно определиться что именно у тебя должно идти быстрее чем с 10 fps. Это и будут функциональные требования.
Здравствуйте, FR, Вы писали:
FR>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Кстати, интересно. Что может вызвать ситуацию, когда другого решения не избежать? (т.е. выбросить все и переписать заново ради оптимизации — это единственный путь)
Радикально неправильный выбор используемых средств исключим (не та база данных, не тот сервер приложений и т.п.).
У кого такие случаи бывали?
Здравствуйте, eao197, Вы писали:
E>Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти. А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
Здравствуйте, _Winnie, Вы писали:
E>>Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти. А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
_W>aliasing, aliasing, aliasing, aliasing, aliasing, aliasing _W>
А можно то же самое но внятно и по-русски?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alexey Axyonov, Вы писали:
AA>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, IT, Вы писали:
IT>>>Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
FR>>Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
AA>Да но для начала нужно определиться что именно у тебя должно идти быстрее чем с 10 fps. Это и будут функциональные требования.
Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, FR, Вы писали:
FR>>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Д>Кстати, интересно. Что может вызвать ситуацию, когда другого решения не избежать? (т.е. выбросить все и переписать заново ради оптимизации — это единственный путь)
Я тут уже приводил пример, есть игра для PC требует больше 256Mb памяти, ее сейчас портируют на PS2 где памяти всего 32Mb, реально легче переписать с нуля.
Здравствуйте, FR, Вы писали:
FR>Я тут уже приводил пример, есть игра для PC требует больше 256Mb памяти, ее сейчас портируют на PS2 где памяти всего 32Mb, реально легче переписать с нуля.
и как правило, это сопровождается радикальным урезанием функциональности
фактически, на выходе может получиться совсем другая программа, имеющая только некоторые общие свойства с оригинальной
я бы вообще не стал называть это "оптимизацией"
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, FR, Вы писали:
FR>>Я тут уже приводил пример, есть игра для PC требует больше 256Mb памяти, ее сейчас портируют на PS2 где памяти всего 32Mb, реально легче переписать с нуля.
Д>и как правило, это сопровождается радикальным урезанием функциональности Д>фактически, на выходе может получиться совсем другая программа, имеющая только некоторые общие свойства с оригинальной Д>я бы вообще не стал называть это "оптимизацией"
Нет, урезание есть но не радикальное, просто оригинал так "хорошо" написан, на PS2 есть и более сложные игры.
Здравствуйте, FR, Вы писали:
FR>Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
Вообще-то потребитель далеко не всегда понимает, чего хочет. И лозунг "спрос рождает предложение" так же не совсем верен. Потребителем очень умело манипулируют. Те же самые супер-пупер IDE, которые тормозят на ноутбуках с 512Mb памяти -- хорошие примеры. Потребителю просто дали понять, что появилось новое качество, которое сейчас важнее, чем быстродействие. Со временем, когда к фенечкам и рюшечкам IDE привыкнут, быстродействие вновь станет фактором конкурентной борьбы. Но и тогда для отвлечения (или привлечения) потребителя что-нибудь новое придумают.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
IT>>Кстати, наследование, инкапсуляция и полиморфизм тоже в определённом смысле есть ни что иное как патерны
AVK>Безусловно. К примеру паттерн инкапсуляция это просто разновидность MVC (M — поля, V — публичный интерфейс, C — код методов).
Хм. Интересній взгляд! Хотя, имхо, М это скорее код, а С — диспетчиризатор сообщений.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, FR, Вы писали:
FR>>Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
E>Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
то есть слово test набирается 8 секунд?
E>Вообще-то потребитель далеко не всегда понимает, чего хочет. И лозунг "спрос рождает предложение" так же не совсем верен. Потребителем очень умело манипулируют. Те же самые супер-пупер IDE, которые тормозят на ноутбуках с 512Mb памяти -- хорошие примеры. Потребителю просто дали понять, что появилось новое качество, которое сейчас важнее, чем быстродействие. Со временем, когда к фенечкам и рюшечкам IDE привыкнут, быстродействие вновь станет фактором конкурентной борьбы. Но и тогда для отвлечения (или привлечения) потребителя что-нибудь новое придумают.
В играх такое не прокатит, я могу представить человека терпящего тормозящий рабочий инструмент, но если вместо игры получится слайд-шоу, то ее просто сразу снесут.
Здравствуйте, FR, Вы писали:
E>>Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
FR>то есть слово test набирается 8 секунд?
Нет, но иногда окошечки для выбора списка методов через несколько секунд напряженного свопа появляются.
E>>Вообще-то потребитель далеко не всегда понимает, чего хочет. И лозунг "спрос рождает предложение" так же не совсем верен. Потребителем очень умело манипулируют. Те же самые супер-пупер IDE, которые тормозят на ноутбуках с 512Mb памяти -- хорошие примеры. Потребителю просто дали понять, что появилось новое качество, которое сейчас важнее, чем быстродействие. Со временем, когда к фенечкам и рюшечкам IDE привыкнут, быстродействие вновь станет фактором конкурентной борьбы. Но и тогда для отвлечения (или привлечения) потребителя что-нибудь новое придумают.
FR>В играх такое не прокатит, я могу представить человека терпящего тормозящий рабочий инструмент, но если вместо игры получится слайд-шоу, то ее просто сразу снесут.
Смотря какая игра. Если это пасьянс на раздевание виртуального противника, то могут и не снести
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если нам не помогут, то мы тоже никого не пощадим.
