Здравствуйте, VladD2, Вы писали:
VD>И получите прирост в 5% мксимум, а то и тормоза (если не додумаетесь свои коллекции реализовать).
Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.
VD>И все же. Ты все время говоришь о количестве классов в вашем фреймворке. Но не разу не скзал, о среднем и максимальном количестве объектов в графе подлежещем сериализации. А именно это число важно для оценки. Так же интересно, что считается приемлемым временем сериализации, когда она происходит...
Для рабочего проекта от 20000. Верхняя планка не ограничена. Серилизация должна выполняться за секунды...десятки секунд. У нас 30 секунд...6 минут.
Осталась одна пролема — WriteObjectInfo создается в раз 20...30 больше, чем объектов.
PE>>Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
VD>Ты, знаешь, мы конечно в твоей прикладной области не разбирались, и заключения дать не можем. Но соглесен с АВК в том, что при числе классов в 6 сотен слабо верится, что в них нет общей системы и что их производство нельзя автоматизировать.
Общая система есть. Все, что однотипно и тд, сделано в базовой сборке. Копипейста нет.
Все, что межно сделать — всю матмодель писать в виде метамодели на специальном языке. На выходе будем иметь те же самые классы. Хороший способ. Нужно написать такой язык, отладить, протестировать, научить всех людей писать на нем. При этом неясно, хватит и нам ресурсов PIII-PIV или нет.
Здравствуйте, VladD2, Вы писали:
VD>Вот тебе и говорят, что это и есть ошибка. Стандартная сериализация скорее всего не для вас. Вы забили на ручную сериализацию, а потом ты еще на этом основании делаешь выводы о приемуществах С++ в этой области. Посмотри как выглядит твоя логика со стороны! "Сериализация в дотнете медленная, а в С++ ее вообще нет и мы можем написать ее оптимальнее чем в дотнете. Значит дотнет тормоз, а С++ рулез."
Уже все сильно. RaiseDeserilizationEvent победили — сделать можно в обход кое как. Если дадут добро на использование кастрированого форматтера из ротора — все пучком. В дотнете мне не нравится подход Микрософта. ObjectManager используется во многих классах. Класс публиный. Почему бы не дать возможность использовать наследники от этого ObjectManager ? SerilizationInfo — нет возможности изменить размер внутреннего массива. SerilizationInfo.AddValue вызывает в среднем 4-5 операций расширения массива. Это большие тормоза, с учетом того, что WriteObjectInfo создается на ссылку, а не объект.
Это только два момента. Если будет возможность поработать напильником, эти два узких места будут спилены и модель будет рулить при серилизации!
PE>>Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд. PE>>Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
VD>Тоже неплохое основание для признания бессмысленности создания собственной системы сериализации. Я правельно понял тормоза у вас в этом, а не в вычислениях?
Тормоза с серилизацией мы уже проехали. Модель нужна не для серилизации, а для расчета сети.
В общем случае тесты вообще непригодны. Сидят люди и проверяют правильность расчетов. Если можно написать скрипт для проверки — пишут. Нельзя — проверяется вручную.
Здравствуйте, VladD2, Вы писали:
PE>>Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом. VD>Ты ведь говорил, что у вас сериализация тормзит изза использования делегатов. Вот он тебе и посоветовал решение.
Уже решено другим способом и без делегатов.
PE>>И если один слой мадели будет сохряняться десятки минут — это все геморрой. VD>Назови все же объем средней и большой модели в количестве экхемлпяров объектов учавствующих в грфе.
Средняя модель 20K...40K объектов. После запуска алгорима расчета моджет быть и 100К...200К.
PE>>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой. PE>>Над этим работаем. VD>Он тебе предлагал вообще-то сериализацию вручную написать, возможно с генератором кода. Это училичит производительность в разы, а то и десятки раз.
Это понятно. Но для этого нужен передизайн. И особого выигрыша это не даст.
Мы решили вообще отказаться от серилизации.
Здравствуйте, VladD2, Вы писали:
PE>>Так что всякие FPGA можно сразу засунуть в одно место.
VD>Да в половине ресиверов подобные функции зашиты. Просто если хватает ЦП, то и нефига делать спец. решения.
В том то и дело, что применени очень ограниченное. В твоем винампе, ламе(если ты в мп3 гонишь диски), дсп и тд. программных алгоритмов на порядки раз больше.
VD>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.
copy-paste-replace то зачем? Ну, да тебе решать.
PE>Для рабочего проекта от 20000.
Это просто копейки. Это только для стандартного сериалайзера проблемой может стать.
PE> Верхняя планка не ограничена.
Так не бывает. Всегда можно рассчитать разумный максимум.
PE> Серилизация должна выполняться за секунды...десятки секунд. У нас 30 секунд...6 минут. PE>Осталась одна пролема — WriteObjectInfo создается в раз 20...30 больше, чем объектов.
Могу только сравнить с данными по R#-у. Количество типов в иерархии его CodeDom-а ~ 150 штук. Добавил пдсчет статистики в парсер R#-а. Прогнал на проекте Хоума. Получилось создание ~130 000 объектов. Время 1.2 сек. При этом еще есть огромный простор для оптимизации. Для просто огромного проекта Моно результат таков:
Максимальное количество AST-веток в одном файле: 40 099
Общее количество AST-веток во всех файлах: 2 400 460
Общее время: 13.10397 сек.
В R# правда не строится сложный граф (только даг). Но я просто уверен, что дело тут не в характере графа, а в качестве сериализации. В R# ведь производится полноценный парсинг и генерация текста по AST.
...
Ты можешь классифицировать свои объекты и выделить основные их подклассы?
PE>Общая система есть. Все, что однотипно и тд, сделано в базовой сборке. Копипейста нет. PE>Все, что межно сделать — всю матмодель писать в виде метамодели на специальном языке. На выходе будем иметь те же самые классы. Хороший способ. Нужно написать такой язык, отладить, протестировать, научить всех людей писать на нем. При этом неясно, хватит и нам ресурсов PIII-PIV или нет.
Ну, про ресурсы это ты уже лишку хватил. А про спех язык описания... почему бы и нет? Можно было или ХМЛ припахать. Или взять генератор компиляторов и с его помощью сделать генератон объектов.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>Написали генератор текста(на жаве ) и все пучком. VD>> Для продукта на дотнете? Ну, вы блин даете...
PE>А что делать ? Г
А почему не на том же Шарпе? Странен не сам генератор, а то что он на Яве для дотнетного проекта.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
VD>>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
S> Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
Измерял. И кстати, тут где-то резултаты приводил. 10% — фигня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace. VD>copy-paste-replace то зачем? Ну, да тебе решать.
Для типизированых коллекций. Подскажи способ лучше.
VD>Могу только сравнить с данными по R#-у. Количество типов в иерархии его CodeDom-а ~ 150 штук.
Хорошо, но немного не то. Типы разные бывают.
Вот попробуй что нибудь предложить для моего случая.
Сеть из узлов и линков между ними.
Количество узлов всего 50. Всего два типа узлов — 25 каждого. Все узлы, независиме от типа, связаны на все остальные 49 через линки(их три типа). Линк соединен с узлами чз промежуточные концы(их два типа).
Узлы — тип1 и тип2
Концы — тип1 и тип2
Линк тип1 — тип1, тип2-тип2, смешаные типы.
Естественно, что каждый тип это свой набор пропертей и тд. и тд.
Каждый объект должен держать уведомления от того, на кого указывает.Т.е. объект выставляет эвенты — на изменение пропертей и на удаление. Каждая операция может быть отменена(Changing) и выполнена(Changed). Тот, кто хранит ссылку на этот объект, должен подписаться на эвенты удаления в обязательном порядке. Линк, узел, конец — все выставляют одни и теже эвенты. Линк подписан на эвенты конца. Конец хранит ссылку на узел и подписан на эвента узла. Сам узел хранит коллекцию всех концов и подписан на эвенты каждого из них. Еще есть объект сеть, который является владельцем всех узлов и линков. Он подписан на все их эвенты.
Т.е всего то нужно описать алгоритм, который будет создавать узлы, связывать их линками.
Потом берешь и серилизуешь или десерилизуешь. Меряешь время.
Всего объекв Nузлов*2+(Nузлов*(Nузлов-1)/2)*3 это, влом считать, примерно 4000 объектов.
В объекте хорошо бы предусмотреть возможность удаления объктов, валидации своих пропертей и своего состояния и расширение пропертей(простых типов) этого самого объекта с помощью механизмов.
Для удаления нужно учесть типы объектов. Удаление узла(принудительное) должно влечь за собой удаление концов и линков.Удаление линка влечет за сосбой удаление концов. Кроме того, если узел соединен с узлом, для удаления нужно сначала удалить линк(безопастное), а уже потом узел. Это потому, что неосторожная манипуляция пользователя может снести всю сеть. В любой момент времени в модели не должно быть висящих концов, узлов, линков без владельца и тд. При любом изменении нужно иметь способ оповестить всех, кто прямо или косвенно связан с объектом.
Вот очень-очень примитивная модель — одномерная. Есть двумерная — сети соедины между собой. Есть трехмерная — сеть состоит из уже из сетей, соединенныйх между собой.
У нас трехмерная многоуровневая модель.
После задания сети запускается алгоритм или алгоритмы, во время которого сеть обрастает другими оъектами(тоже источниками событий) — роутинги, трифики и тд. и тд.
VD>Ты можешь классифицировать свои объекты и выделить основные их подклассы?
Это уже сделано.
VD>Ну, про ресурсы это ты уже лишку хватил. А про спех язык описания... почему бы и нет? Можно было или ХМЛ припахать. Или взять генератор компиляторов и с его помощью сделать генератон объектов.
Для этого надо чтобы наши топменеджеры осваивали все эти технологии.
На оффшоре хорошо сидеть. А вот как научить этому американца(, который пишет алгоритм, вместо наследования использует хештейблы для расширения атрибутов объекта, не знает, что такое интерфейс, виртуальный метод, ) я не знаю. Так что выбор невелик.
Re[52]: C++ versus C#
От:
Аноним
Дата:
13.03.04 10:17
Оценка:
Здравствуйте, VladD2, Вы писали:
PE>>>>Написали генератор текста(на жаве ) и все пучком. VD>>> Для продукта на дотнете? Ну, вы блин даете... PE>>А что делать ? Г VD>А почему не на том же Шарпе? Странен не сам генератор, а то что он на Яве для дотнетного проекта.
А там было проще парсить код языка. Такой библиотеки мы не нашли для нета.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
VD>>>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
S>> Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
VD>Измерял. И кстати, тут где-то резултаты приводил. 10% — фигня.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Кстати метаклассы в том числе намного упрощают проблему сериализации и десиреализации.
VD>Ага. Языком.
Ну зачем же так грубо. Нет в Delphi часто используют и я в том числе.
У каждого типа есть конструктор FromStream, а у каждого объекта метод ToStream. Но в Net на рефлексии легко развернуть все методы на этапе компиляции в MSIL а не не этапе сериализации десиреализации, в том числе и для объетов неизвестного типа. VD>Проблема сериализации в дотнете заключается в кривых руках тех кто ее писал.
Согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>>>XML + embedded C# или VB.
PE>>Не пойдет.
AVK>Почему?
На C# можно сделать так, но гораздо удобнее сделать это в специаизированом языке.
PE>> Нужен специализированый язык, нечто вроде UML в текстовом представлении, который будет прятать все, что не относится к математике.
AVK>Вот и построй его на основе XML.
На основе XML неудобно. Я думаю, что это может быть нечто вроде С-подобного языка такого плана.
Здравствуйте, VladD2, Вы писали:
PE>>Это очень сложный механизм. PE>>Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
VD>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
В случае эвентов очень легко скриптовых клиентов уведомлять. Без этого никуда.
) и все пучком.
Для продукта на дотнете? Ну, вы блин даете... 
