Здравствуйте, grosborn, Вы писали:
G>Тьфу-ты. То есть речь идет просто об общей эффективности работы с большим количеством типов и алгоритмы GC тут не при чем. "Протухание кэша" Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?
Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.
Здравствуйте, Ikemefula, Вы писали:
V>>Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...
I>Ты бы замерил что ли
Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns.
I>>>да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел. V>>Это от неумения готовить GC. А у нас более 50ms никогда не выходило. Как и почему — уже объяснял.
I>Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100) I>Повторяю — это особенность виндовса.
Я получаю паузы в 3-5 сек только когда некая железка, обращение с которой идет через DMA, выходит из сна. Например, винт. Конкретно винды тут не при чем, на Линухах можно повторить. Больше нигде я таких пауз не наблюдал...
Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести.
V>>Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша. I>Интересно, для вычисления зависимости скорости работы GC от количества типов оказывается GC не надо дёргать
Ничего смешного. Ты не можешь достоверно управлять дотнетным асинхронным GC. Поэтому, чтобы воспроизвести сценарий какой-нить сложной проги... это надо брать саму прогу, которую вполне можно тестировать на конкретной технике.
Здравствуйте, Ikemefula, Вы писали:
I>Разница межу O(1) и O(N) стала мелочью ? А ты, непростой
Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ, то бишь собственно затраты на каждый шаг тоже... бо обработка данных по большей части порционная, где размеры самих порций не так, чтобы очень большие. И вот в этой самой оценке снизу IList сливает по самое нехочу.
>>А как только я попросил всех отказаться от IList<> в коде (и оп-па!!! это произошло абсолютно безболезненно), то тот же самый код на конкретных типах стал давать прирост до 50 раз в ручной бинарной сериализации в сравнении со встроенной. И сама задача обрела черты заведомо решаемой на дотнете. До этого были обоснованные сомнения.
I>Зеваю. Такое утверждение требует некоторых жостких данных, которые я вряд ли дождусь.
Цифры приведены. Ну и потестировать List<> и IList<> можно самому, не?
I>>>Иммутабельный не IList, а пустой массив, это именно то что говорил Синклер V>>Синклер-то прекрасно знает, на какой неиммутабельный дизайн я ему намекал. Недавно я показывал всю кривизну такого подхода в споре о const. То бишь, все эти рассуждения у меня вызывают только иронию и мысль о поговорке "мыши плакали, кололись...", а далее ты в курсе. ))
I>А по моему ты просто хочешь увильнуть в сторону.
Здравствуйте, Ikemefula, Вы писали:
V>>Кстате, твой тест, судя по твоему же описанию, всё еще некорректен, то бишь исходные 2 порядка надо делить не на 8, а на 16? То бишь, 100/16=~6, так? I>А почему на 16 а не на 1023429879345 ?
Здравствуйте, elmal, Вы писали:
E>Это считаем ОО подходом или нет?
В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
Причем, я сильно подозреваю, что без ущерба для ООП такие сообщения могут быть даже иммутабельными.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, elmal, Вы писали:
E>>Это считаем ОО подходом или нет?
V>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
Конечно же это бурная фантазия
Здравствуйте, samius, Вы писали:
V>>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. )) S>Конечно же это бурная фантазия
Здравствуйте, samius, Вы писали:
V>>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. )) S>Конечно же это бурная фантазия
На всяк случай для ленивых:
Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения.
Здравствуйте, DarkGray, Вы писали:
DG>Меняет пространственное положение участков веревки в вертикальной плоскости, если считать, что сама веревка растянута в горизонтальной плоскости.
А зачем?
S>> А по поводу идентити — у вас есть Equals, который зачем-то отличается от ReferenceEquals. Кто из них определяет Identity в вашем случае? DG>Идентити определяется с помощью функции Equals.
Прекрасно.
DG>>>вот, например, объект RopePoint с нечеткой границей и нечетким положением относительно Rope, какие у него проблемы с identity? S>>Ну какой же он нечёткий? Он вполне чёткий. Вы порезали верёвку на целое количество частей. Смысл этого непонятен — у реальной верёвки между любыми двумя точками есть ещё одна. DG>Повторю, что есть два различных свойства(и понятия): классы эквивалентности элементов, и нечеткость положения и границ элемента. DG>Но положение и граница каждого элемента RopePoint-а уже нечеткая. Попробуй ответить на простые вопросы: DG>- где центр каждого RopePoint-а относительно веревки, исходя из поведения функции Chnage?
Да нету там никакого поведения у функции Change. Понятия "центр" тоже нету. DG>- где начинается и заканчивается каждый RopePoint относительно веревки, исходя из поведения функции Change?
Ну как где? Это же дискретные объекты — значит, RopePoint "заканчивается" ровно там, где начинается второй.
У вас нет никакой меры близости RopePoint.
Поймите, реальная верёвка не состоит из счётного количества фрагментов (если мы не переходим на уровень молекулярного моделирования).
Река — не состоит из счётного количества капелек. Между любыми двумя точками верёвки можно найти ещё одну.
Чтобы смоделировать Rope Point с нечёткими границами, вам придётся заменить результат функции Equals с bool на double. И это всё ещё будут полумеры — потому, что double на самом деле тоже дискретен.
DG>на эти два вопроса можно ответить только используя вероятностное распределение, а это и есть симптом нечеткости и неопределенности.
Да ничего полезного на эти риторические вопросы ответить нельзя. Ваши RopePoint изоморфны натуральным числам. Где заканчивается 4 и начинается 5?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Лучше реализуйте процедуру Cut, которая режет верёвку на две верёвки, причём идентичность концов сохраняется.
DG>постановка непонятна — идентичность чего с чем должна сохраниться?
Ну как же? Концов верёвки. Одним концом верёвка привязана к DarkGray:
darkGray.tie = ropeEnd1;
Другим концом — к батарее:
heatTube.tie = ropeEnd2;
Мы можем убедиться, что DarkGray никуда не сбежит:
А теперь разрежьте верёвку пополам. При этом heatTube.tie и darkGray.tie менять нельзя — они уже привязаны.
Но в результате у нас должны получиться две верёвки:
Здравствуйте, Ikemefula, Вы писали:
I>Это не важно. Минимум 90% не читают вообще ничего и это не мешает им освоить ООП и это же мешает освоить ФП.
1. Да, не читают. Это понятно и очевидно. В частности, видно по вопросам вокруг JS — из них видно, что большинство программистов на нём садятся и начинают писать. Поведение машины выясняется методом проб и ошибок, а не чтением литературы.
2. Не понятно, как оно помогает одному и мешает другому?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. )) S>>Конечно же это бурная фантазия
V>На всяк случай для ленивых: V>
V>Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения.
Да, с фантазиями я поспешил. В оригинальной концепции сообщения тоже были объектами, нашел подтверждение у Кея. А у Пирса в минимальном можестве фич ничего такого уже не упоминается. Да и во множестве ООЯ идентифицировать method invoke не представляется возможным.
верно?
S>А теперь разрежьте верёвку пополам. При этом heatTube.tie и darkGray.tie менять нельзя — они уже привязаны. S>Но в результате у нас должны получиться две верёвки: S>
Здравствуйте, DarkGray, Вы писали:
DG>странный дизайн. Почему у каждого объекта только одна привязка?
В общем случае — сколько угодно привязок.
S>>Мы можем убедиться, что DarkGray никуда не сбежит: S>>
DG>>- где начинается и заканчивается каждый RopePoint относительно веревки, исходя из поведения функции Change? S>Ну как где? Это же дискретные объекты — значит, RopePoint "заканчивается" ровно там, где начинается второй.
и мы можешь доказать это утверждение, что всегда из первого следует второе? ты можешь доказать, что всегда из дискретности следует четкость границы?
Здравствуйте, DarkGray, Вы писали:
DG>и мы можешь доказать это утверждение, что всегда из первого следует второе? ты можешь доказать, что всегда из дискретности следует четкость границы?
Не очень понял, что именно нужно доказать. Аксиому?
У вас над точками не определено никаких бинарных операций, кроме Equals. А для неё границы совершенно чётко очерчены: каждая "точка" эквивалентна только самой себе, и абсолютно неэквивалентна любой другой точке.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, samius, Вы писали:
S>В оригинальной концепции сообщения тоже были объектами, нашел подтверждение у Кея. А у Пирса в минимальном можестве фич ничего такого уже не упоминается. Да и во множестве ООЯ идентифицировать method invoke не представляется возможным.
Да фиг с ним, с Пирсом. Как ты собрался вообще представлять сообщения в своём ООЯ? Тупл неких значений-аргументов obj.f(x, y, x)? Какое же это ООП? )))
Хотя, де-факто так имеем в мейнстиме.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Разница межу O(1) и O(N) стала мелочью ? А ты, непростой
V>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ.
Давай, покажи на примере Enumerable.ElementAt, вперёд.
I>>Зеваю. Такое утверждение требует некоторых жостких данных, которые я вряд ли дождусь.
V>Цифры приведены. Ну и потестировать List<> и IList<> можно самому, не?
Здравствуйте, vdimas, Вы писали:
V>>>Кстате, твой тест, судя по твоему же описанию, всё еще некорректен, то бишь исходные 2 порядка надо делить не на 8, а на 16? То бишь, 100/16=~6, так? I>>А почему на 16 а не на 1023429879345 ?
V>Т.е. в плане некорректности теста возражений нет?
Я говорю о том, что аргументы у тебя высосаны из пальца, ни пояснить, ни подтвердить кодом у тебя не получается.
Здравствуйте, Sinclair, Вы писали:
I>>Это не важно. Минимум 90% не читают вообще ничего и это не мешает им освоить ООП и это же мешает освоить ФП. S>1. Да, не читают. Это понятно и очевидно. В частности, видно по вопросам вокруг JS — из них видно, что большинство программистов на нём садятся и начинают писать. Поведение машины выясняется методом проб и ошибок, а не чтением литературы.
S>2. Не понятно, как оно помогает одному и мешает другому?
"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия. А вот с ФП нужно уже что называется долбить.
Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?
