Здравствуйте, AndrewVK, Вы писали:
PE>>Ну протестирую я генератор колекций, и что с того ? AVK>То что генеренный код после этого при изменении входных данных особо тестировать не надо.
То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.
PE>>А новые люди сколько в этом разбираются ? AVK> Нету у нас таких.
Когда будут — расскажешь.
PE>>Если ваша с сеть однороная, то хоть миллиарды.
AVK>Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.
AVK>Да, естественно ни о какой автоматической сериализации я даже не думал. Запись целиком собственная, в БД, с кешированием и сериализацией только измененных частей. Иначе это при любом варианте автоматической тормоза. А мне надо чтобы сохранение изменений занимало не более 1-2 секунд.
PE>> У нас примерно 600 классов, писаных от руки.
AVK>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?
Аналогия та же самая.
PE>>По какому принципу генерировать — непонятно.
AVK>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
PE>>Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
AVK>ИМХО это сигнал для серьезного пересмотра дизайна программы.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?
PE>А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.
Одновременно и одинаковых? Так у тебя же sender есть, по нему и разруливай.
AVK>>Не, ну до маразма что угодно можно довести.
PE>Сложность задачи определяет кастомер, а не мы. PE>Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети.
Маразм не в модели оптической сети, а в создании классов на каждую подписку.
PE>>>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет. AVK>>О том и речь.
PE>Так а зачем лишний код ?
Чтобы не тормозило, ты же этого хотел?
PE>Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос.
Нет тут никакой сложности. Быстрее, причем очень заметно быстрее.
PE>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.
Зная размер модели я бы это делал с самого начала.
Здравствуйте, AndrewVK, Вы писали:
AVK>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
Серилизацию мы не пишем. На все написано два суррогата.
PE>>Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
AVK>ИМХО это сигнал для серьезного пересмотра дизайна программы.
Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд.
Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс? PE>>А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких. AVK>Одновременно и одинаковых? Так у тебя же sender есть, по нему и разруливай.
Одновременно. Могут быть разных типов. Могут быть одинаковых типов.
Сендер у нас один — в базовом классе. А приемников нужно столько, сколько пропертей.
PE>>Сложность задачи определяет кастомер, а не мы. PE>>Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети.
AVK>Маразм не в модели оптической сети, а в создании классов на каждую подписку.
Подписка — это не просто обратная связь. Это кусочек математики, которую придется выпонять при возникновении эвента. Для каждой проперти она своя.
PE>>Так а зачем лишний код ? AVK>Чтобы не тормозило, ты же этого хотел?
PE>>Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос.
AVK>Нет тут никакой сложности. Быстрее, причем очень заметно быстрее.
Серилизация и десерилизация умрет вообще.
PE>>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой. AVK>Зная размер модели я бы это делал с самого начала.
Это очень сложный механизм.
Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>То что генеренный код после этого при изменении входных данных особо тестировать не надо.
PE>То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.
Ну вот, значит нужно продолжать двигаться в том же направлении.
AVK>>Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
PE>У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.
Ну так тем более. Я то сразу делал собственную загрузку/выгрузку. И в вашем случае поступил бы точно так же, вне зависимости от того какой язык и платформу я использую.
AVK>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
PE>Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?
Здравствуйте, AndrewVK, Вы писали:
PE>>То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.
AVK>Ну вот, значит нужно продолжать двигаться в том же направлении.
На дженериках мы первое, что сделаем, это повыбрасываем все коллекции.
PE>>У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи. AVK>Ну так тем более. Я то сразу делал собственную загрузку/выгрузку. И в вашем случае поступил бы точно так же, вне зависимости от того какой язык и платформу я использую.
Если использовать оптимизированый вариант форматтера из ротора, то все пучком. Остается устранить лишние WriteObjectInfo(их столько, сколько ссылок на объект — в 20...30 раз больше). Опосля доработать напильником, убрать лишнее в смысле, и обфусцировать.
AVK>>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
PE>>Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ? AVK>В смысле?
Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
Мне вот в свете вышесказанного еще интересно как приживется C++ CLI
Ведь писать на нем будет практически также просто как и на C# а возможностей побольше будет
все таки.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Про COM ты сам вспомнил. Я ничего не говорил. Я предложил идею реализации, аналогичную комовской.
Вот тебе и сказали, что он тут не причем. Конекшон-поинты в ком нужны для избавления от проблемы циклической ссылки. В дотнете она или вообще не стоит или решается вик-реверенсами.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
Полностью согласен.
AVK>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
Как минимум все они состоят из свойст и коллекций. Так что уж сериализацию то точно можно автоаматизировать если не придерживаться собственных догм и не упавать на собственную не последовательность.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>На дженериках мы первое, что сделаем, это повыбрасываем все коллекции.
И получите прирост в 5% мксимум, а то и тормоза (если не додумаетесь свои коллекции реализовать).
PE>Если использовать оптимизированый вариант форматтера из ротора, то все пучком. Остается устранить лишние WriteObjectInfo(их столько, сколько ссылок на объект — в 20...30 раз больше). Опосля доработать напильником, убрать лишнее в смысле, и обфусцировать.
И все же. Ты все время говоришь о количестве классов в вашем фреймворке. Но не разу не скзал, о среднем и максимальном количестве объектов в графе подлежещем сериализации. А именно это число важно для оценки. Так же интересно, что считается приемлемым временем сериализации, когда она происходит...
PE>Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
Ты, знаешь, мы конечно в твоей прикладной области не разбирались, и заключения дать не можем. Но соглесен с АВК в том, что при числе классов в 6 сотен слабо верится, что в них нет общей системы и что их производство нельзя автоматизировать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Серилизацию мы не пишем. На все написано два суррогата.
Вот тебе и говорят, что это и есть ошибка. Стандартная сериализация скорее всего не для вас. Вы забили на ручную сериализацию, а потом ты еще на этом основании делаешь выводы о приемуществах С++ в этой области. Посмотри как выглядит твоя логика со стороны! "Сериализация в дотнете медленная, а в С++ ее вообще нет и мы можем написать ее оптимальнее чем в дотнете. Значит дотнет тормоз, а С++ рулез."
PE>Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд. PE>Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
Тоже неплохое основание для признания бессмысленности создания собственной системы сериализации. Я правельно понял тормоза у вас в этом, а не в вычислениях?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.
Ты ведь говорил, что у вас сериализация тормзит изза использования делегатов. Вот он тебе и посоветовал решение.
PE>И если один слой мадели будет сохряняться десятки минут — это все геморрой.
Назови все же объем средней и большой модели в количестве экхемлпяров объектов учавствующих в грфе.
PE>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой. PE>Над этим работаем.
Он тебе предлагал вообще-то сериализацию вручную написать, возможно с генератором кода. Это училичит производительность в разы, а то и десятки раз.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Серилизация и десерилизация умрет вообще.
...
PE>Это очень сложный механизм. PE>Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
ЗЫ
Вот только тормоза сериализатора далеко не только в событиях заключаются.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Фремворк на шарпе создать еще проще. НО ! В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм. PE>Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху. PE>Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд. PE>Так что всякие FPGA можно сразу засунуть в одно место.
Да в половине ресиверов подобные функции зашиты. Просто если хватает ЦП, то и нефига делать спец. решения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>такой как тут невозможно просто на шарпе, нужно разрабатывать ещё один язык для нета, впринципе одно из решений
И? На поверку это может оказаться проще, чем извращаться на плюсах. Обычно нужен не новый язык, а специализированный генератор кода. Его и эмулируют на новеших возможностей шаблонов.
Вот интересно, ваш код компилируется на VC6? И уверен ли ты в том, что если бы в воспользовались, например, вот этим, у вас не плучилось бы все проще, надежнее и быстрее?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, maq, Вы писали:
maq>Мне вот в свете вышесказанного еще интересно как приживется C++ CLI maq>Ведь писать на нем будет практически также просто как и на C# а возможностей побольше будет maq>все таки.
maq>Что народ думает?
Я думаю, что возможностей особо больше не будет. А читать и присать на Шарпе удобнее уже. Так что C++ CLI станет тем же чем Дельфи.НЭТ — средством вербовки в веру дотнета программистов плохо хранящим излишнюю приверженность своим привычкам.
Единственное что мне действительно нехвататет из С++ на сегодня — это средств метапрограммирования. Но они и в С++ очень слабы. Сдается мне, что будущее за вот такими расширениями
Здравствуйте, VladD2, Вы писали:
PE>>Написали генератор текста(на жаве ) и все пучком. VD> Для продукта на дотнете? Ну, вы блин даете...
А что делать ? Генераторы текста, которыми обладают всякие UML-тулы, весьма кривые. Мы написали постпроцесор. То, что нагенерировал UML, обрабатывается постпроцесором, и мы имеем файл, в котором нужно только функции заполнить. С коллекциями свой случай — они сделаны чз. copy-paste-replace. Другой способ, когда мы задавали этот вопрос, никто не смог предложить.
Здравствуйте, VladD2, Вы писали:
AVK>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает. VD>Полностью согласен.
AVK>>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора. VD>Как минимум все они состоят из свойст и коллекций. Так что уж сериализацию то точно можно автоаматизировать если не придерживаться собственных догм и не упавать на собственную не последовательность.
Проблема с серилизацией не самая емкая проблема. Мы использовали бинариформаттер. Нам это стоило сотни две строк вместе с суррогатами. Сейчас избавимся от гемора с RaiseDesirilizationEvent и все пучком.
Нету у нас таких.
) и все пучком.
Для продукта на дотнете? Ну, вы блин даете... 