Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>Тиражи они разные, если исключить студентов и преподавателей, то вобщем выбор невелик. Для оытного разработчика что по ООП, что по ФП почти ничего нет.
Изначально речь шла о букварях
S>>Вот тебе еще одна косвенная оценка.
I>То есть, если некто ищет и читает про монады в эту статистике не попадёт, правильно ?
Смотря как искать. Если q="monad object oriented programming", то попадет и скажется на графике ООП.
Здравствуйте, samius, Вы писали:
I>>Тиражи они разные, если исключить студентов и преподавателей, то вобщем выбор невелик. Для оытного разработчика что по ООП, что по ФП почти ничего нет. S>Изначально речь шла о букварях
Это не важно. Минимум 90% не читают вообще ничего и это не мешает им освоить ООП и это же мешает освоить ФП.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Изначально речь шла о букварях
I>Это не важно. Минимум 90% не читают вообще ничего
Слова этой песни с припевом про нужды отрасли я уже слышал.
I> и это не мешает им освоить ООП и это же мешает освоить ФП.
А это из анекдота про Изю и скрипку (там где он отвечает что еще не пробовал играть на ней).
Меняет пространственное положение участков веревки в вертикальной плоскости, если считать, что сама веревка растянута в горизонтальной плоскости.
S> А по поводу идентити — у вас есть Equals, который зачем-то отличается от ReferenceEquals. Кто из них определяет Identity в вашем случае?
Идентити определяется с помощью функции Equals.
DG>>вот, например, объект RopePoint с нечеткой границей и нечетким положением относительно Rope, какие у него проблемы с identity? S>Ну какой же он нечёткий? Он вполне чёткий. Вы порезали верёвку на целое количество частей. Смысл этого непонятен — у реальной верёвки между любыми двумя точками есть ещё одна.
Повторю, что есть два различных свойства(и понятия): классы эквивалентности элементов, и нечеткость положения и границ элемента.
Классов эквивалентности для RopePoint — здесь, да — четкое кол-во.
Но положение и граница каждого элемента RopePoint-а уже нечеткая. Попробуй ответить на простые вопросы:
— где центр каждого RopePoint-а относительно веревки, исходя из поведения функции Chnage?
— где начинается и заканчивается каждый RopePoint относительно веревки, исходя из поведения функции Change?
на эти два вопроса можно ответить только используя вероятностное распределение, а это и есть симптом нечеткости и неопределенности.
Здравствуйте, Ikemefula, Вы писали:
I>Мне интересно, как ты делал такие задежрки в виндовсе ? Известно, что винда не умеет делать точные задержки длиной менее кванта,
Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...
Понятно, что из-за особенностей общего использования ресурсов в многозадачной ОС всегда будет некая погрешность и некое распределение... примерно такая же, как на "родном" sleep(x), даже если x кратен системному тику. То бишь всё ок, ка в реальной жизни. Нужную картинку ты увидишь все-равно, даже с учетом всех погрешностей, бо статистика она и в Африке статистика.
I>да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел.
Это от неумения готовить GC. А у нас более 50ms никогда не выходило. Как и почему — уже объяснял.
Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша.
Здравствуйте, samius, Вы писали:
I>>Это не важно. Минимум 90% не читают вообще ничего S>Слова этой песни с припевом про нужды отрасли я уже слышал.
Это реальность.
I>> и это не мешает им освоить ООП и это же мешает освоить ФП. S>А это из анекдота про Изю и скрипку (там где он отвечает что еще не пробовал играть на ней).
Здравствуйте, vdimas, Вы писали:
V>Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле... V>Понятно, что из-за особенностей общего использования ресурсов в многозадачной ОС всегда будет некая погрешность и некое распределение... примерно такая же, как на "родном" sleep(x), даже если x кратен системному тику. То бишь всё ок, ка в реальной жизни. Нужную картинку ты увидишь все-равно, даже с учетом всех погрешностей, бо статистика она и в Африке статистика.
Ты бы замерил что ли
I>>да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел. V>Это от неумения готовить GC. А у нас более 50ms никогда не выходило. Как и почему — уже объяснял.
Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100)
Повторяю — это особенность виндовса.
V>Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша.
Интересно, для вычисления зависимости скорости работы GC от количества типов оказывается GC не надо дёргать
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>Это не важно. Минимум 90% не читают вообще ничего S>>Слова этой песни с припевом про нужды отрасли я уже слышал.
I>Это реальность.
I>>> и это не мешает им освоить ООП и это же мешает освоить ФП. S>>А это из анекдота про Изю и скрипку (там где он отвечает что еще не пробовал играть на ней).
I>Это реальность.
Пока ты не привел подтверждающих фактов (пусть даже косвенно указывающих на утверждаемое тобой), это твоя субъективная реальность.
Здравствуйте, samius, Вы писали:
I>>Это реальность.
S>Пока ты не привел подтверждающих фактов (пусть даже косвенно указывающих на утверждаемое тобой), это твоя субъективная реальность.
Я поделился тем что вижу на собеседованиях, в числе стран есть и Россия, если тебе интересно.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>Это реальность.
S>>Пока ты не привел подтверждающих фактов (пусть даже косвенно указывающих на утверждаемое тобой), это твоя субъективная реальность.
I>Я поделился тем что вижу на собеседованиях, в числе стран есть и Россия, если тебе интересно.
Ты лишь подтверждаешь написанное мной — ты опираешься не на данные о программистах вообще, а на твои субъективные впечатления о программисах, прошедших через твои собеседования. Выборка нерепрезентативна.
Здравствуйте, samius, Вы писали:
I>>Я поделился тем что вижу на собеседованиях, в числе стран есть и Россия, если тебе интересно. S>Ты лишь подтверждаешь написанное мной — ты опираешься не на данные о программистах вообще, а на твои субъективные впечатления о программисах, прошедших через твои собеседования. Выборка нерепрезентативна.
Это тебе хочется додумывать чего то. Я кроме собеседований еще и общаюсь с людьми которые такие же собеседования проводят. Разные страны, разные города, разные организация а ситуация примерно одна и та же.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Ты лишь подтверждаешь написанное мной — ты опираешься не на данные о программистах вообще, а на твои субъективные впечатления о программисах, прошедших через твои собеседования. Выборка нерепрезентативна.
I>Это тебе хочется додумывать чего то. Я кроме собеседований еще и общаюсь с людьми которые такие же собеседования проводят. Разные страны, разные города, разные организация а ситуация примерно одна и та же.
А ничего что на том же rsdn согласных с твоей оценкой ситуации еще поискать придется?
DG>>или это всё устаревшие примеры GUI? что тогда не устаревший GUI? S>Интерфейс гмейла построен, в первую очередь, на search & navigation.
Не понятно откуда взялось противопоставление парадигмы Search&Navigation парадигме OOUI. Это две ортогональные друг другы парадигмы — и использование одной из них никак не отрицает и не уменьшает использование другой.
В gmail явно используется OOUI парадигма.
Есть объекты — папка, цепочка-писем, письмо, набор цепочек-писем, адресат и т.д.
У объектов есть методы, которые можно вызвать.
Например, у цепочки-писем есть методы:
— Archive
— Report Spam
— Delete
— Move to ..
— Label as ..
— Mark as unread
— Mark as read
— Mark as important
— Mark as not important
— Add to Tasks
— Add star
— Filter messages like these
— Mute
Здравствуйте, samius, Вы писали:
I>>Это тебе хочется додумывать чего то. Я кроме собеседований еще и общаюсь с людьми которые такие же собеседования проводят. Разные страны, разные города, разные организация а ситуация примерно одна и та же.
S>А ничего что на том же rsdn согласных с твоей оценкой ситуации еще поискать придется?
Ты опросил людей не менее сотни, согласны ли они с моей позицией, изложив перед этим мою позицию без передергиваний ?
В этой сотне, буде таковая в наличии, люди помногу проводят собеседования а не просто поговорить ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>А ничего что на том же rsdn согласных с твоей оценкой ситуации еще поискать придется?
I>Ты опросил людей не менее сотни, согласны ли они с моей позицией, изложив перед этим мою позицию без передергиваний ? I>В этой сотне, буде таковая в наличии, люди помногу проводят собеседования а не просто поговорить ?
I>Шота мне кажется и там и там ответ "нет".
Если ты считаешь что раз твою позицию оспорило всего N человек << M числа посетителей сайта означает что остальные с ней согласны, то не буду шатать твой мирок.
Здравствуйте, samius, Вы писали:
I>>Шота мне кажется и там и там ответ "нет".
S>Если ты считаешь что раз твою позицию оспорило всего N человек << M числа посетителей сайта означает что остальные с ней согласны, то не буду шатать твой мирок.
Я считаю, что N в данном случае пока что равно 1, это ты, по той простой причине что по озвученому вопросу выдал свою позицию ровно один раз. Подумай хорошенько, что это значит
Конкретно про "N << M". Если ты опросил некие N человек выбраных случайно и обладающих признаками дадеными в предыдущем посте и при этом N позволяет обобщить результаты...
Но у тебя ведь ничего такого нет, правда ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Если ты считаешь что раз твою позицию оспорило всего N человек << M числа посетителей сайта означает что остальные с ней согласны, то не буду шатать твой мирок.
I>Я считаю, что N в данном случае пока что равно 1, это ты, по той простой причине что по озвученому вопросу выдал свою позицию ровно один раз. Подумай хорошенько, что это значит I>Конкретно про "N << M". Если ты опросил некие N человек выбраных случайно и обладающих признаками дадеными в предыдущем посте и при этом N позволяет обобщить результаты... I>Но у тебя ведь ничего такого нет, правда ?
Правда в том, что я видел что другие тоже не соглашались с твоим мнением. А защитников твоего мнения кроме тебя не нашлось.
По поводу опросов мной случайной выборки — естественно этого не было. Но это не аргумент в пользу реальности твоей оценки.
Здравствуйте, samius, Вы писали:
S>Правда в том, что я видел что другие тоже не соглашались с твоим мнением.
Повторяю еще раз — мнение по вопросу кто чего читает или не читает я озвучил ровно один раз — сегодня.
>А защитников твоего мнения кроме тебя не нашлось.
Ты не то прочитать не можешь, не то еще что, разбирайся сам.
I>Если весь эффект это "сумма отдельных слагаемых не равна сумме" то этим свойством обладает любой отрезок кода который затрагивает кеш. Делаешь прогоны через паузу — опаньки, суммарное время прогонов меньше суммарного времени прогонов без пауз. GC здесь ничего не меняет.
Паузы не в счет, ес-но. Интересует сугубо полезная нагрузка. И да, в тесте можно выявить зависимость по двум координатам — по паузам и по кол-ву повторно неиспользуемого кода. Просто для второй координаты есть некий минимум, с которого эффект начинает наблюдаться устойчиво. То бишь, коль меня спросили о самом существовании эффекта — я ответил как на него посмотреть.
I>Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем.
Я не зря тебе дал вполне жОсткую (С) временную сетку. Тебе уже не надо гадать и нащупывать нужные области. Предлагаю проводить тест тогда, когда вообще "ничего такого" с машиной не происходит. То бишь, когда она ничем больше не занята. Результаты тебя всё-равно удивят.
I>Если в кеше в основном метаданные, очевидно, разнообразие типов заставит кеш "протухать" чаще. Но это только теория. На практике GC сам по себе осязаемо замедляется при большом расходе памяти.
На практике GC удачно обслуживает поколения даже при большом расходе памяти. А вообще, основная мысль верная — надо заставлять GC опрашивать как можно меньше памяти в абсолютном выражении на каждой итерации уборки мусора. Именно поэтому, запустив вечный цикл создания/уборки объектов нулевого поколения ты получаешь описанное тобой быстродейтсвие, что (1) циклы уборки 0-го поколения относительно частые и короткие, сам тест ты гоняешь без пауз. Создатели GC не дураки. Но как только уходим за пределы 0-го поколения, то... таки да, пулы объектов даже в Джава и Дотнете поднимают быстродействие некоторых сценариев в 2-3 раза. Сведения из биржевой области, там, где счет идет на на десятки микросекунд (для нейтива — на единицы микросекунд).
I>Это ожидаемый эффект и хотелось бы увидеть адекватную модель, которая позволит сравнить разницу между временем прогонов с большим количеством типов и с маленьким.
А что тебе мешает написать модель интерпретатора метаинформации и погонять ее при различном кол-ве обходимых структур описания метаинформации на каждом шаге?
I>У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.
GC не пробегает все экземпляры за каждый цикл, а при уборке 0-го поколения кол-во интерпретируемых типов вообще минимально. Да и сами объекты обычно еще в кеше. И да, у нас (в описанном сценарии) ни о каких десятков миллионов речи быть не могло, ес-но. В среднем десятки тясяч объектов составляют пул для медиа для тысячи одновременных подключений и примерно столько же составляют описание самих подключений. Выделения из GC происходят только когда соединения меняют состояния, что происходит невероятно редко в сравнеии с частотой поступления пакетов медиа. По пути медиа в коде не встречается ни одного new. )) В общем, борьба шла за то, чтобы вложить самые тяжелые паузы GC в ~50ms. Больше — нельзя.
V>>Че-то ты уже совсем потерялся. Выделение в GC быстрое. Оптимизировать всегда надо затраты на уборку. GC интерпретирует метаинформацию о типах по мере обхода графа объектов. Чем больше разнообразие типов, тем вероятнее будет эффект, который ты увидишь в приведенном сценарии теста. Почему речь о вероятности? Потому что размеры кеш-памяти разные. На какой-то машине эффект уже начнет проявляться, на какой-то еще нет или слабо.
I>Ты для начала внятно опиши, что же это за эффект такой.
Ты уже сам его описал — эффект от выталкивания полезных данных из кеша. Кеш многоуровневый, эффект тоже.
I>На мой взгляд единственные адекватные характеристики которые отражают время работы GC I>1 это глубина дерева объектов.
Ну да, это степенная ф-ия к суммарному кол-ву объектов, начиная от объектов самого верхнего уровня. Про "выпрямление" объектов в памяти я тоже упоминал. Очень много в дизайне value-type, которые, однако, безопасно использовать только в кач-ве приватных полей других объектов.
I>2 количество узлов в дереве
Поправлю, кол-во постоянно обновляемых объектов.
I>3 глубина стека
Непринципиально. У тебя глубже 2-3-х десятков уровней во вменяемой программе будет мало вызовов. И даже отклонение в 2 раза от этой цифры ничего не изменит.
I>4 степень фрагментации
При нашем малом кол-ве объектов, да еще устойчиво живущих во 2-м поколении + крайне редком выделении памяти, считай, что фрагментации нет совсем. От дотнетного сетевого стека с его пинами тоже отказались. В общем, мое дело было лишь обрисовать эффект, ваше дело — принять во внимание или нет. До всех оптимизаций сервер принимал буквально 3-4 десятка клиентов, если больше — звук периодическя "вякал" и "квакал", после указанных оптимизаций — держал под тысячу на той же технике. ХЗ сколько будет на современной.
