Здравствуйте, Ikemefula, Вы писали:
V>>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем... I>То есть, коэффициэнт 16 высосан из пальца ? Поздравляю.
Ты сказал о 8, и я по твоему описанию увидел некорректность в сценарии.
V>>Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет. V>>И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.
I>"Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать.." @ vdimas
Дык, это ведь ты код требуешь. Я-то эту тему давно прошел и все выводы давно сделал. Мне лишь для своей эрудиции интересно понагибать последний дотнет.
В плане числодробления уже нагибал — сосет не нагибаясь как и прежде. В плане GC они там что-то сильно много хвалились — надо проверить насколько соответсвует действительности.
Здравствуйте, vdimas, Вы писали:
V>>>Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда. I>>Расскажи, в каком из примерно десятка тестов, что я сделал за последнюю неделю, гоняется только 0-е поколение ?
V>Словами ты описал мне именно это. Код всё-равно не показал.
Это ты додумал как тебе удобно было. Начни со своей модельки с очередями, только подумай сам, где ты ошибся на два порядка и при чем здесь миллионы объектов.
>И да, не уходи от ответа на вопрос: в синтетических тестах получал ли свои 15 сек паузы на GC?
Уже отвечал — 15 сек задержки было получено в нативном приложении, которое в цикле крутило QPC, Sleep, QPC + printf если время намного больше ожидаемого.
I>>Моя модель более простая,
V>Она более однобока с т.з. происходящего в реальном коде.
Правильно, для того что бы исследовать наблюдаемый эффект.
V>Хотя, если речь о твоём клиническом случае в десятки миллионов объектов, то... то какого хрена там делает дотнет, не пояснишь? Он не для этих сценариев.
Это заблуждение.
I>>понимаешь что это значит с т.з. диагностики ?
V>Ес-но понимаю. Это означает нерелевантность любых синтетических результатов по такой модели.
Это означает что модель легко использовать для исследования эффекта.
I>>Вообще то ты говоришь про оптимизацию, которая и нужна как раз из за того, что количетсво узлов слишком сильно влияет на перформанс GC
V>Нет, речь не о кол-ве узлов, а именно что об простом обновлении ссылочных полей "старых" объектов. Попробуй еще раз.
Я именно про это и говорю, без этой оптимизации GC придется обходить весь граф объектов.
I>>Буду знать, а то я было решил что ты акк кому то дал.
V>Да не будешь ты знать... ты пытаешься модель заранее урезать и высмеиваешь любые попытки сделать наоборот.
Я пытаюсь упростить модель до предела, что успешно получается.
Здравствуйте, vdimas, Вы писали:
V>>>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем... I>>То есть, коэффициэнт 16 высосан из пальца ? Поздравляю.
V>Ты сказал о 8, и я по твоему описанию увидел некорректность в сценарии.
Если бы ты читал внимательно, то заметил бы, что эта разница целиком и полностью из за очереди при том что издержки на GC ничтожны. Эта разница как раз и натолкнула меня на мысль о том, что твои данные отличаются от реальных минимум на порядок-другой.
I>>"Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать.." @ vdimas
V>Дык, это ведь ты код требуешь. Я-то эту тему давно прошел и все выводы давно сделал. Мне лишь для своей эрудиции интересно понагибать последний дотнет. V>В плане числодробления уже нагибал — сосет не нагибаясь как и прежде. В плане GC они там что-то сильно много хвалились — надо проверить насколько соответсвует действительности.
Ничего, если я тебе твои слова покажу ?
Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.
И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.
Здравствуйте, Ikemefula, Вы писали:
V>>Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных. I>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.
Дык, тогда ты попался. ))
На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько.
I>>>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.
V>>Пффф.. Описанное тобою не имеет ничего общего с протуханием кеша. То бишь аргумент про детский лепет я тебе, пожалуй, возвращу. )) V>>Ты показал эффект от нелокальности данных для потока, более ничего.
I>Я не знаю какой смысл ты вкладываешь в "протухание кеша"
Это вытеснение из кеша нужных для нашей задачи данных/кода конкурирующими задачами. У тебя же такой заметный эффект мог получиться не от вытеснения, а от блокировки разделяемых линеек кеша во время их синхронизации на аппаратном когерентном движке ассоциативной памяти.
Здравствуйте, Ikemefula, Вы писали:
V>>И? поясни юмор? I>Поясняю — на мой взгляд в твоих слова примерно 90-95% дезы пополам с общими словами( по оценке снизу конечно же).
А на мой взгляд твоя область деятельности настолько далека от вопросов гарантий эффективности, что тебе любые замеченные эффекты насчет быстродейтвия кажутся сигналами с далекой вселенной. по оценке снизу, ес-но.
V>>Не пробовал на досуге сравнивать размеры своих объектов vs размеры их метаописания?
I>И сколько этого "достаточно велико" ? На боевом приложении, где разных типов не менее 1000 (по оценке снизу) эффект ничем не отличается от чистой синтетики Сколько это "достаточно велико", 10К, 100К, 1ККК ?
В боевом приложении может быть несколько тысяч типов и лишь по некоторым из них коллекции заметных размеров. Размеры самих объектов, например на 32-битной архитектуре, в среднем довольно малы. Я получал в статистике порядка 2-3 десятка байт в среднем на объект.
Здравствуйте, vdimas, Вы писали:
V>>>Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных. I>>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.
V>Дык, тогда ты попался. )) V>На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько.
А где сказал сказал, что процессор был "одноядерный", дашь ссылку ? Может быть тебе лучше прекратить додумывать ?
I>>Я не знаю какой смысл ты вкладываешь в "протухание кеша"
V>Это вытеснение из кеша нужных для нашей задачи данных/кода конкурирующими задачами.
Правильно.
>У тебя же такой заметный эффект мог получиться не от вытеснения, а от блокировки разделяемых линеек кеша во время их синхронизации на аппаратном когерентном движке ассоциативной памяти.
Здравствуйте, Ikemefula, Вы писали:
V>>Увы, это ты ошибся. Интересуют собственные затраты на эту операцию, а как их найти с помощью статистики ты должен бы и сам знать, если умудрился самостоятельно закончить ВУЗ.
I>Нет, просто ты упустил из виду ключевой момент — как делать маленькие задержки и как правильно обрабатывать такие результаты. В виндовс это мягко говоря нетривиальная задача. Например rdtsc который ты указал, тоже имеет нюансы использования. И QueryPerformanceCounter имеет нюансы.
Тривиальнейшая задача что под виндами, что под линухами.
I>Ты же великий реалтаймщик, распинаешься перед публикой которая непонимает ни капли , по твоим словам, в реалтайме, а сам не можешь рассказать, какие же подводные камни у этого реалтайма.
По опыту, лишние подробности вызывают негодование "высокоуровневых программистов". Особенно когда приводишь тесты... Начинают искать то забытий Dispose в конце теста (хотя не требовался), то им не нравится что использовал для замера DateTime.Now вместо QueryPerformanceCounter (всегда так делаю на "длинных" тестах, системный таймер более точен, несмотря на более грубое квантование) и т.д. до бесконечности. Могу кинуть ссылку, где этот бред во всей красе. ))
Кароч, на указанных временных отрезках ньюансами можешь пренебречь. Сценарий тут ровно наоборот, то бишь подразумеваемые тобой ньюансы существенны лишь точного замера времени, но не для показанной задачи. Ссылки на сами эти ньюансы я же здесь и давал и объяснял когда-то, какой смысл повторяться?
В общем, мне было интересно, чтобы ты пошевелил процессором — но увы. Ес-но, у нас многозадачная ОСь, а данные нужны релевантные. Очевидно, над тупо собирать статистику и выкидывать нерелевантные данные. Например, те, где мы хотели получить задержку ~50us, а получили по-факту 50ms. "Ширину" допуска для временного интервала можешь выбрать сам. Это не бог весть какая наука, чтобы нельзя было догадаться самому.. ес-но, стоило тебе только быть чуть заинтересованней в обсуждении и вообразить себе сценарий реального генерирования необходимых задержек для целей тестирования, ты бы справился легко. В общем, я-то твоё "лишь бы поболтать" и так вижу, просто показываю твой абсолютно незаинтересованный в техническом плане подход к обсуждению тебе же самому.
Собсно, поэтому лень строчить для тебя нехилый исходник... что он тебе заранее неинтересен, увы, даже если покажет всё, что я хотел показать.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>И? поясни юмор? I>>Поясняю — на мой взгляд в твоих слова примерно 90-95% дезы пополам с общими словами( по оценке снизу конечно же).
V>А на мой взгляд твоя область деятельности настолько далека от вопросов гарантий эффективности, что тебе любые замеченные эффекты насчет быстродейтвия кажутся сигналами с далекой вселенной. по оценке снизу, ес-но.
Ты мягко говоря ошибся, последний год я постоянно сталкиваюсь с оптимизацией по памяти и перформансу, а последние три месяца только этим и занимаюсь.
Тебе трудно признать, что критерии эффективности и оптимизации бывают разные ?
I>>И сколько этого "достаточно велико" ? На боевом приложении, где разных типов не менее 1000 (по оценке снизу) эффект ничем не отличается от чистой синтетики Сколько это "достаточно велико", 10К, 100К, 1ККК ?
V>В боевом приложении может быть несколько тысяч типов и лишь по некоторым из них коллекции заметных размеров. Размеры самих объектов, например на 32-битной архитектуре, в среднем довольно малы. Я получал в статистике порядка 2-3 десятка байт в среднем на объект.
Внятно пожалуйста — количетсво типов, средний размер и что нужно делать, желательно кодом.
Здравствуйте, Ikemefula, Вы писали:
V>>>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ. I>>>Давай, покажи на примере Enumerable.ElementAt, вперёд.
V>>Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))
I>"прирост до 50 раз " @ vdimas
А теперь тебе надо бъяснить пассаж насчет Enumerable.ElementAt.
V>>Тебе действительно сложно перебрать элементы абстрактного и конкретного контейнеров?
I>Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются. I>Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.
Дык, никто не мешает использовать любые конкретные типы, в т.ч. обычный массив. И таки, если речь об итерировании, то итерирование по List<> нифига не дорогое удовольствие, в отличие от IList<>.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>В оригинальной концепции сообщения тоже были объектами, нашел подтверждение у Кея. А у Пирса в минимальном можестве фич ничего такого уже не упоминается. Да и во множестве ООЯ идентифицировать method invoke не представляется возможным.
V>Да фиг с ним, с Пирсом. Как ты собрался вообще представлять сообщения в своём ООЯ?
В том и дело, что кроме как представлять их (воображать), ничего с ними сделать нельзя. Ну или если очень надо, то завести класс Message/Command, который передавать внутри сообщения и идентифицировать как сообщение его экземпляры.
V>Тупл неких значений-аргументов obj.f(x, y, x)? Какое же это ООП? ))) V>Хотя, де-факто так имеем в мейнстиме.
Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет.
Здравствуйте, samius, Вы писали: S>Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет.
Просто мейнстрим, в отличие от академики, требует реальных решений для реальных проблем.
Поэтому встраивают поддержку паттернов, отличных от "отправить один объект в качестве сообщения другому объекту".
Ну, вот как с теми же енумами в Джаве.
С точки зрения теории кристалла, енум можно эмулировать при помощи класса, у которого есть финитное количество экземпляров. Экземпляры созданы до начала работы пользовательского кода и никогда не умирают.
Для того, чтобы этот класс изобразить, нужно много "подпорок" и надстроек над исходной минимальной ООП-моделью. Нужна поддержка статических методов; нужна поддержка запечатанных классов; нужна поддержка приватных конструкторов.
И даже когда всё это есть, желателен синтаксический сахар, потому что руками описывать все эти public static readonly Color.Red = new object(); — занудство.
После этого при использовании можно опираться на ссылочную эквивалентность.
Понятно, что всё это — изоморфно подмножеству натуральных чисел, поэтому в некоторых языках, которые не стесняются мультипарадигменности, енумы реализуются не как сахар над ООП, а по-настоящему.
Примерно то же самое мы имеем по отношению к абстрактной "передаче сообщения" vs. "вызов метода".
В абстрактной академике биндинг выполняется полностью принимающей стороной, а в качестве сообщения может выступать всё, что угодно.
В конкретном мейнстриме имеются методы, сигнатуры, сложные правила совместимости, статический биндинг и прочее. Потому, что надо работать, а не доказывать достаточность минимального базиса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия. А вот с ФП нужно уже что называется долбить.
Т.е. имеется в виду т.н. "сетевой эффект", да?
Когда 99% кода, который ты встречаешь в жизни, написано с использованием ООП, и только 1% — с использованием ФП, то это и формирует твою квалификацию. В таком случае — согласен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, samius, Вы писали: S>>Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет. S>Просто мейнстрим, в отличие от академики, требует реальных решений для реальных проблем. S>Поэтому встраивают поддержку паттернов, отличных от "отправить один объект в качестве сообщения другому объекту". S>Ну, вот как с теми же енумами в Джаве.
По поводу енумов в Джаве согласен.
S>Примерно то же самое мы имеем по отношению к абстрактной "передаче сообщения" vs. "вызов метода". S>В абстрактной академике биндинг выполняется полностью принимающей стороной, а в качестве сообщения может выступать всё, что угодно. S>В конкретном мейнстриме имеются методы, сигнатуры, сложные правила совместимости, статический биндинг и прочее. Потому, что надо работать, а не доказывать достаточность минимального базиса.
Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
Отчасти поэтому мы и имеем кучу работы с сингатурами, сложными правилами совместимости и прочим, вплоть до несовместимости Func/Action в C#. В ФП с более накладным применением аргументов все как-то намного проще.
Здравствуйте, Sinclair, Вы писали:
I>>"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия. А вот с ФП нужно уже что называется долбить.
S>Т.е. имеется в виду т.н. "сетевой эффект", да?
Я не сильно понимаю этот термин. По ООП если в вакууме, как бы тоже надо читать. Но в реальности это не нужно т.к. грубо говоря среда сама предоставляет все необходимое.
S>Когда 99% кода, который ты встречаешь в жизни, написано с использованием ООП, и только 1% — с использованием ФП, то это и формирует твою квалификацию. В таком случае — согласен.
Здравствуйте, vdimas, Вы писали:
I>>Нет, просто ты упустил из виду ключевой момент — как делать маленькие задержки и как правильно обрабатывать такие результаты. В виндовс это мягко говоря нетривиальная задача. Например rdtsc который ты указал, тоже имеет нюансы использования. И QueryPerformanceCounter имеет нюансы.
V>Тривиальнейшая задача что под виндами, что под линухами.
А еще ты забыл рассказать про "/usepmtimer", affinity, rdtscp и ничего не рассказал как влияет кеш на результаты таких измерений.
I>>Ты же великий реалтаймщик, распинаешься перед публикой которая непонимает ни капли , по твоим словам, в реалтайме, а сам не можешь рассказать, какие же подводные камни у этого реалтайма.
V>Кароч, на указанных временных отрезках ньюансами можешь пренебречь. Сценарий тут ровно наоборот, то бишь подразумеваемые тобой ньюансы существенны лишь точного замера времени, но не для показанной задачи. Ссылки на сами эти ньюансы я же здесь и давал и объяснял когда-то, какой смысл повторяться?
см выше
V>Собсно, поэтому лень строчить для тебя нехилый исходник... что он тебе заранее неинтересен, увы, даже если покажет всё, что я хотел показать.
Ты только не волнуйся, я еще на прошлой неделе понял, что от тебя кода не будет
Здравствуйте, samius, Вы писали:
S>Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
Объект мог быть создан на стеке и передан по ссылке...
S>Отчасти поэтому мы и имеем кучу работы с сингатурами,
Ну так сигнатуру аргументов и возвращаемого значения можно рассматривать как некий автообъявляемый тип-тупл. Собсно, в С++ сигнатура ф-ии/метода и есть полноценный тип, в отличие от дотнета.
S>сложными правилами совместимости
ИМХО, никаких сложностей: ковариантность и контрвариантность зависит от направления аргумента в сигнатуре in/out, т.е. возвращаемое значение ничем от out аргумента в этом плане не отличается. Сложно запутаться.
S>и прочим, вплоть до несовместимости Func/Action в C#.
Да, в дотнете делегаты не абстрактные типы, а вполне конкретные. За это их пинали с самого начала. Даже напиши рядом такой же Action2 через copy&paste и он будет несовместим с исходным Action.
S>В ФП с более накладным применением аргументов все как-то намного проще.
Тебе проще из-за абстрактности функциональных типов + обобщенного программирования. Это фишка конкретного языка, а не ФП как такового.
Здравствуйте, Ikemefula, Вы писали:
I>>>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы. V>>Дык, тогда ты попался. )) V>>На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько. I>А где сказал сказал, что процессор был "одноядерный", дашь ссылку ? Может быть тебе лучше прекратить додумывать ?
Выделенное не по-русски разве?
>>У тебя же такой заметный эффект мог получиться не от вытеснения, а от блокировки разделяемых линеек кеша во время их синхронизации на аппаратном когерентном движке ассоциативной памяти.
I>Отключи кеш да замерь разницу.
И какие проблемы? Отключать надо для обоих вариантов для сравнения. Давай тест, отключу да проверю.
Небольшая разница может быть только на многоканальном контроллере, но никак не в 100 раз, ес-но.
Хотя и 100 раз — че-то дофига. Я максимум вручную насильно добивался ухудшения на этом эффекте в ~20 раз на шестиядернике. Мне уже любопытно, как ты получил свои 100 раз?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ. I>>>>Давай, покажи на примере Enumerable.ElementAt, вперёд.
V>>>Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))
I>>"прирост до 50 раз " @ vdimas
V>Этот множитель сложился из двух множимых. См. исходный пост на русском языке: http://www.rsdn.ru/forum/philosophy/4843592.1.aspx
То есть, ты разницу между IList и List помножил на разницу между ручной и встроеной серилизацией ?
Но по любому , ты снова ошибся хотя уже не на порядок
Проверяем "разница м/у использованием List<> и IList<> в коде от 3-х до ~10-ти раз (от стоимости тела цикла зависит)"
Итерации по контейнерам длиной N, где в цикле выполняется единственная строчка в виде обращения к элементу для того что бы все итерации были в равных условиях, элементов 10КК, 10 прогонов + вычисление среднего.
Для сравнения приведены результаты по ArrayList и LinkedList и Array
цикл контейнер время_относительно_первой_строчки
foreach object[] 1
for object[] 1
foreach IList<object> 3.5
for IList<object> 4
for List<object> 1.7
foreach List<object> 2
ForEach List<object> 1.7
foreach ArrayList 6
for ArrayList 3
foreach LinkedList<object> 4
Итого, максимальная разница между List и IList в 2.5 раза. С valuetype вместо object разница еще меньше, всего 1.5 раза.
Вероятно "от 3-х до ~10-ти" ты получил вообще на пустых итерациях
V>А теперь тебе надо бъяснить пассаж насчет Enumerable.ElementAt.
Объясняю — использование List может быть очень дорогим удовольствием, а хочется, что бы некоторые функции вроде Linq2Objects работали крайне быстро, выход — IList<>
I>>Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются. I>>Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.
V>Дык, никто не мешает использовать любые конкретные типы, в т.ч. обычный массив. И таки, если речь об итерировании, то итерирование по List<> нифига не дорогое удовольствие, в отличие от IList<>.
Ты похоже не понимаешь — если List это очень дорого, то и массив тоже будет так же дорого.
Реальная разница в 2.5 раза на почти пустой итерации. Если цикл чуть сложнее суммы элементов, эта разница становится ничтожной.
Здравствуйте, vdimas, Вы писали:
I>>>>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы. V>>>Дык, тогда ты попался. )) V>>>На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько. I>>А где сказал сказал, что процессор был "одноядерный", дашь ссылку ? Может быть тебе лучше прекратить додумывать ?
V>Выделенное не по-русски разве?
Выделенное выражает степень уверенности и там не содержится утверждение про какие то конкретные процы. Что бы было понятно — я просто не помню на каких процах какие именно были результаты, я привел только наихудший результат который запомнился.
I>>Отключи кеш да замерь разницу.
V>И какие проблемы? Отключать надо для обоих вариантов для сравнения. Давай тест, отключу да проверю.
Вариантов гораздо больше чем "обоих".
V>Небольшая разница может быть только на многоканальном контроллере, но никак не в 100 раз, ес-но.
Ай, не гони, сравнивать нужно пропускную способность памяти и L1, поделить одно на другое и будет разница в производительность для "памятезависимых" приложений.
V>Хотя и 100 раз — че-то дофига. Я максимум вручную насильно добивался ухудшения на этом эффекте в ~20 раз на шестиядернике. Мне уже любопытно, как ты получил свои 100 раз?
В зависимости от структуры процессора, особенностей чипсета, разница между частотами ядра и памяти, оптимизаций конкретного кода разница может быть и больше 100 раз. Только L2 может давать до 30% времени.
Здравствуйте, Sinclair, Вы писали:
SV.>>>>Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден. S>>>Как это "не виден"? Да он в плане счетов написан крупным шрифтом. То, что вы дали счёту какой-то внутренний служебный идентификатор — ваше личное решение; нужды в нём никакой нет. SV.>>После таких слов Лука Пачоли в гробу перевернулся. S>С чего бы это вдруг?
Ну как же. Как он смел заниматься бухгалтерией без плана счетов, утвержденных Минфином РФ с его идентификаторами? Ладно, это была шутка. Не обращайте внимания.
SV.>>Ваш план счетов — это один-единственный аспект, отчетный. А вы на основе его идентификаторов делаете уникальные ключи, хотя это всего лишь внешние атрибуты (и то, не факт, что прямые, очень может быть, что вычисляемые). S>Не очень понятно, что значит "вычисляемые".
Я имел в виду запись в отдельной таблице с указанием текущего справочника и вхождения в него.
SV.>>Во-первых, план счетов — хронотопический стандарт, он действует на территории отдельного государства, и его средняя продолжительность жизни — пять лет. По уму, место его — в справочнике. Чтобы любое количество реальных счетов можно было отнести на счет из текущего плана, а исчезновение из плана идентификаторов не приводило к необходимости переоткрывать счета. Если подумать, из счета даже ссылаться на справочник текущего плана напрямую нельзя. S>Совершенно верно. Именно поэтому идея представить счёт в виде объекта — порочна. Потому что все необходимости что-там "переоткрывать" связаны исключительно с представлением о счёте как о чём-то таком, у чего есть своё собственное поведение. SV.>>Нужно делать промежуточную таблицу с историей ссылок. S>Это ещё зачем? Такая таблица нужна только тогда, когда вы придаёте счёту идентичность. А у счёта её нет — вы только что сами написали об этом. S>Если у вас в таблице проводок пишутся только идентификаторы счетов (в соответствии с той версией плана, которая актуальна на момент действия проводки), то никаких исторических таблиц делать не надо.
Один простой вопрос. Как вы в этой системе будете вести лицевые счета? Они не видны в отчете, но видны операционисту.
SV.>>Во-вторых, план счетов — внешний по отношению к организации стандарт. Есть ведь и другие аспекты помимо налогово-отчетных. В реальной организации на один внешний счет, включенный в отчет, может приходиться 10 внутренних, которые вообще в вышеупомянутом аспекте не видны. S>Ну и что? Каким образом нам тут поможет ООП-шный объект "счёт"? То, что вы описываете, прекрасно реализуется на декларативном Екселе, не то что без ООП, а даже и без структурного программирования.
А я и не говорю про ООП. Я переключился на уникальные искусственные идентификаторы счета, которые (не) нужны.
SV.>>"Это" — это что? Сделать шорткат от Current'а на Date.Now? S>Да.
SV.>>А почему не будем? Очень даже будем. Дизайн — он безответный, и, прикрываясь его интересами (которых у него нет), можно что угодно запроектировать. Вы ровно это и делаете. Берете произвольное решение, которое нравится вам ("надо его выносить наружу"), и пишете "с точки зрения правильного дизайна". Пойди поспорь. Или надо соглашаться, или начнется совершенно идиотский спор "какой дизайн трушнее". Который закончится взаимным посыланием нафиг и тем, что каждый останется при своем мнении. S>Есть объективная реальность. Вообще дизайн — на удивление точная наука, даже если мы говорим о веб-дизайне или дизайне интерьеров. Всё в нём подчинено требованиям удобства сиреч эргономики. S>А уж дизайн софта — и подавно. Есть совершенно объективные критерии того, какой дизайн лучше другого — это стоимость внесения изменений. S>А рассуждения о субьективности критериев дизайна — это, простите, махровая гуманитарщина. То есть отказ от пользования логическим мыслительным аппаратом.
Вот опять мы говорим не про ООП. И опять я скажу, что тут шайбочкой не обойтись.
То, что прочитал, для меня звучит дико. В центре любого дизайна для меня стоит ЧЕЛОВЕК. Юзер. Покупатель и пользователь. С одной стороны дизайн продает. Если ЧЕЛОВЕКУ не нравится, он не купит. С другой — если вас этот покупатель интересует в будущем (он честно и регулярно платит), то даже после продажи надо обеспечить ЧЕЛОВЕКУ какое-то минимальное удовлетворение от покупки. Видите, сколько раз я сказал "ЧЕЛОВЕК"? А теперь вспомните, как "человечный" будет по латыни? Humanus. Да, представьте себе, это махровая гуманитарщина.
Теперь про логический аппарат. Аппарат вам не поможет, извините. Вся история IT — это история того, как тупорылый юзер похерил все достижения точных наук и чистого разума и купил себе айфон. Угадать ход его мысли логически? Ха-ха-ха. Вся наука сводится к тому, чтобы либо быть с ним в резонансе, как это делал Джобс, либо ориентироваться по другим продуктам, фокус-группам и так далее. То есть, изучать человека без фиги (точной науки) в кармане. Кто бы мог подумать, что главное в мобильной операционной системе — блестящие иконки. Это я такой умный задним умом, как все русские. Когда игра уже сыграна.
Что эти немного абстрактные рассуждения значат применительно к ООП и счетам? Я делаю утверждение, основанное на наблюдениях, а не на какой-то там мифической науке: никто не любит писать объектные модели, но все очень любят ими пользоваться, поскольку они снижают порог вхождения. Я делаю второе утверждение — нет, и не может быть никакой науки, чтобы доказать или опровергнуть первое утверждение. Максимум, что мы можем сделать — это провести опрос или посмотреть на эволюцию имеющихся программных систем. Мое третье утверждение — вам же самому будет лучше, если программисты по проекту под вашим началом смогут быстро в нем осваиваться. Экономически. Поскольку есть и такая точка зрения — мы привлекаем лучших специалистов, вот пусть они и нюхнут дерьмеца. Монстры-инженеры, как-никак. Лапшу там поразгребают, знание о проводках постаскают из модуля в модуль. Люди такие есть, но вы их сначала наймите, а потом окажется, что бросать их на бухгалтерию — как микроскопом гвозди забивать.
SV.>>Например, Васе поставили задачу — "построение таблицы [счет]-[текущий баланс]". Если вы опять напишете про своих теток, которые паразитируют на реальном труде, приводя сведения о реальном бизнесе в соотетствие с порождением советского Госплана (а откуда же еще высрались эти планы счетов?), которым такая таблица не нужна, не надо, пожалуйста. S>Коллега, меньше эмоций. Бухгалтерию придумали вовсе не в СССР, и про тёток никто не писал. Если у Васи представления о счёте, как о баночке с деньгами — то это личные Васины проблемы. Точнее, это проблемы того, кто Васю нанял, потому что реальная бухгалтерия работает вовсе не так. S>Реальная бухгалтерия — это, в первую очередь, механизм расчёта налогов. Без этого, грубо говоря, можно просто иметь одну баночку с деньгами, и просто брать из неё столько, сколько нужно.
Нет, нет и еще раз нет. Реальная бухгалтерия обслуживает реальный бизнес. А ему надо вести счета, основанные на проводках, не для того, чтобы рассчитывать долю государства, а для того, чтобы этим самым бизнесом оперировать. Я знаю, что говорю, поскольку имел такие заказы. Когда у вас сотня клиентов, у каждого свой мультивалютный счет, а у вас свои внутренние служебные счета, вы не можете оперировать баночкой. 95% времени вы осуществляете переводы в рамках своей финансовой деятельности, а к моменту подготовки налоговой отчетности у вас все эти пачки и пачки счетов суммируются и относятся на несколько позиций из плана. Люди заранее ПРОСИЛИ, чтобы все эти лицевые счета были отмаркированы в целях облегчения дальнейшего суммирования.
Без эмоций, вполне спокойно, я заявляю: то, что вы описываете, это паразитизм. Минфин в роли краба, который лицо закрывает, и личинка чужого в виде собственной бухгалтерии, которая грызет бизнес изнутри. Борьба с безработицей по-русски. Все понятно, но за пределами этих уродливых перекосов жизнь тоже есть.
Опять же, причем тут Лука Пачоли. А чем они все эти века занимались, пока Госплан не выкатил план счетов, интересно?
SV.>>Мир не крутится вокруг СССР. У других, знаете, тоже бывает бухгалтерия, в которой баланс счета — сумма проводок, а не состояние. S>Совершенно верно. Вот только зачем вы хотите иметь именно счёт с состоянием вместо суммы проводок ?
У счета нет состояния. Он его эмулирует. Я, вроде, не скупился в словах, когда это описывал.
SV.>>Так вот, выше я предложил сделать шорткат на основе дефолтного параметра. Что вы изволили назвать плохим решением. Видимо, с точки зрения "Правильного Дизайна", который вы тут представляете на манер Лебедева. С точки зрения не Дизайна, а Васи, у него есть объект acc, у которого можно нажать точку и посмотреть, что будет. Вывалится список методов, среди которых не будет никакого CurrentBalance. А будет CalcBalance(Date forDate = Date.Now). S>Нет, вы предлагали именно CalcCurrentBalance() — все ходы записаны. Далее, по вашим словам, мне совершенно непонятно, откуда это у Васи вдруг возьмётся объект acc, у которого можно нажать точку и посмотреть, что там выпадет.
Это я сначала предложил CalcCurrentBalance(). А уже потом развил свою мысль до CalcBalance(Date forDate = Date.Now). Дорогу, тыскызыть, осиливает идущий. Но я не настаиваю, пусть будет CalcCurrentBalance() и CalcBalance(Date forDate). Это все равно несравненно лучше суммирования проводок везде, где нужен баланс.
Откуда у Васи acc — как откуда? От AccountingService'а. Как он достукивается до сериса — это платформозависимые вещи. Если Вася пишет плагин (допустим, вебпарт), то и ссылку получает на входе. Если пишет standalone-страницу, просто обращается к сервису и получает у него интерфейс. Затем — что-то типа:
var acc = theService.GetAccountByReportIdentifier('78.01');
S>Сопли, простите, поскипаны. Если вы хотите что-то написать — пишите по делу. А не драму про Васю, который, оказывается, с самого начала ничего не знает, зато каким-то волшебным образом всё узнаёт. И про Синклера, который сначана всё знает, а потом почему-то стремительно тупеет.
Вася этот сидит у меня за спиной сейчас. Только зовут его Катя. Все взято с натуры.
Дальше, а почему Синклер тупеет? Цель была показать, что имплементация полна сюрпризов, а вы от них ограждены. Можете подставить СВ. Я люблю, когда ОМ скрывает от меня реализацию на первых порах и тупым себя по этой причине не считаю. Если и считаю, то не по этой. Главное, чтобы она (ОМ) по мере "врубания" и роста хотелок не становилась гирей на ногах, как это случилось с ShP OM.
SV.>>Гуёвый программист не занимается порождением объектной модели. Он отдает 78.01 в метод хелперного объекта AccountingService, и получает объект Account, который можно изучать через IDE. Оба они, AccountingService и Account, а также все реализации Account, описанные выше, являются частью объектной модели, создавать которую (и упаковывая реализацию в которую) дело архитектора. S>Вопрос: зачем гуёвому программисту этот объект Account? S>Что мешает ему сразу вызвать метод AccountingService.CalcBalance(...)?
А вот ЭТО и будет нарушением SRP, о котором столько говорилось. По сути, будет одна большая общая куча функций. Что-то типа WinAPI. Словами не передать, как я ненавижу изучать такие API.
S>Сколько разных реализаций вы себе представляете у класса Account?
Я привел пример с двумя реализациями: "реального" счета, то есть, счета, который пасется на базе, и агрегирующего счета, который агрегирует "реальные" счета по заданному признаку. Но это, подчеркиваю, не обязательно. Даже если у вас одна реализация, не надо свинячить и пихать в AccountingService everything and kitchen sink.
SV.>>Вы не читаете, что ли? Я же сказал: это зависит от точки зрения дизайнера на responsibility. Если думать о responsibility в терминах "функциональность по расчёту баланса", "функциональность по работе с базой" — тогда да, это нарушение SRP. Если считать responsibility этого класса "предоставить Васе доступ к балансам", тогда нет. Вот когда Account начнет заодно курсы валют возвращать, тогда это будет нарушение SRP. S>Непонятно, где вы проводите границу responsibility. У классиков — всё понятно. Границы responsibility проходят там, где проходят разные причины для изменений. А с вашим подходом запихать вообще всё в функцию main — нормально, потому что ответственность программы это "сделать всё".
Про классиков я не знаю. Можете показать, что надо прочитать и соотнести — я прочитаю и соотнесу.
Запихать вообще всё в функцию main — НЕнормально, как раз потому, что ответственность нельзя описать словами "сделать всё". Сделать что? Декомпозируйте.
S>Я же вам привёл пример: сменили структуру базы или заменили хранилище — поправили код в одном месте. А у вас придётся править Account, Transaction, а то и всяких Person и прочих "активных классов", которые слишком много знают о доступе в базу.
SV.>>Еще раз. Вы просто не ставите такой задачи, которую решает ООП, допустим, в том же самом MS ShP. S>Возможно, возможно. Я не говорю, что ООП вообще не нужно. Но в подавляющем большинстве софта для масс-процессинга ООП — это оверкилл. А бухгалтерия — это типичный пример масс-процессинга, где проводок — сотни и тысячи.
В реальности, вы же знаете, люди пишут код без комментов и переменные называют однобуквенными именами, чтоб с работы не выгнали. В подавляющем большинстве мест, я подозреваю. Какой тут ООП. Но если вы, допустим, архитектор и совладелец?
Про сотни и тысячи я не понял. Да хоть миллионы. ООП же не роняет производительность сама по себе.
