Здравствуйте, AndrewVK, Вы писали:
AVK>Суммарное? Да ничего специального не делать. В десятки раз замедляется собственно вызов, а не все. Остается еще время работы самого алгоритма.
Стоп, если мне предложили держать формулы в одном домене, а данные — в другом, то как мне передать код из домена формул в домен с данными? Очевидно надо делать наоборот, поэтому я и говорю про сериализацию гига данных.
AVK>Если ты хочешь там затюнить все насмерть, то достаточно не мучаться танцами с бубном вокруг выгрузки, а просто изредка рециклить основной домен вместе с сервером, возможно сохраняя твой драгоценный кеш. Но вобще то лучше оцени потери памяти на твои формулы за любой разумный промежуток времени, а потом сравни со своим многогигабайтным кешем.
AVK>И вобще смешно слышать разговоры о быстродействии после предложения использовать интерпретатор и рассказов об 1С.
У меня стоит двоякая задача:
1. решить эту конкретную задачу
2. разжиться эффективным скрипт-движком
Второе я смогу использовать, например, в бухгалтерских системах. Ведь там недостаточно будет перегенерить одну формулу при смене оной, надо будет так же перегенерить все остальные формулы, ее использующие, а со скриптингом — нет.
AVK>Может ты не в курсе, но даже бейсик БК-0010 в замшелые времена тоже работал подобным образом. Только это не спасает интерпретатор от чудовищной разности в производительности по сравнению с компилятором. На ее фоне кроссдоменные потери не заметны под микроскопом.
Я в этой же ветке Владу ответил довольно развернуто показав технику, которую использую. Мне интересно так же и твое мнение, где именно в той системе у меня могут быть чудовищные проседания в производительности. Мне кажется, что разница будет раза в 2-3 максимум.
V>>В конкретном случае о котором идет речь — десятки тысяч вариантов формул до рестарта.
AVK>Мощные у тебя юзеры, набить десятки тысяч формул, я таких не встречал. В любом случае это все равно копейки.
Аналитическая on-line система. Не знаю насчет десяток, но несколько тысяч различных формул в день — запросто. В принципе, посмотрим, если не получим приемлимое быстродействие, то буду периодически выгружать и загружать домен (примерно раз в неделю).
Здравствуйте, VladD2, Вы писали:
V>>(в принципе, может зайти далеко, в MS есть открытый проект оптимизирующего бэк-энда компиляторов для дотнета, насколько я понял Nemerle пока его не юзает, но теоретически ничего не мешает)
VD>Ты все перепутал. Есть Феникс. Феникс — это бэкэнд, но не оптимизирующий или для дотнета, а общий бэкэнд для всех компиляторов МС. Его можно использовать и для генерации MSIL-а, и для пре- или джит-компиляции готовых дотнетных сборок. Кроме того его можно применять для модификации МСИЛ-а готовых сборок и для генерации кода компиляторами. В частности планируется перевести VС++ на Феникс.
What is Phoenix?
Phoenix is a software optimization and analysis framework that is the basis for all future Microsoft compiler technologies. The Phoenix framework is an extensible system that can be adapted to read and write binaries and MSIL assemblies and to represent the input files in an IR, which can be analyzed and manipulated by applications by using the Phoenix API. The code can then be written in binary or JITable form for execution.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[28]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, vdimas, Вы писали:
AVK>>Суммарное? Да ничего специального не делать. В десятки раз замедляется собственно вызов, а не все. Остается еще время работы самого алгоритма.
V>Стоп, если мне предложили держать формулы в одном домене, а данные — в другом, то как мне передать код из домена формул в домен с данными? Очевидно надо делать наоборот, поэтому я и говорю про сериализацию гига данных.
Ну и? Сериализация конечно довольно медленная вещь, но по масштабам скомпилированного кода. И даже ее можно ускорить. Можно реализовать ISerializable, избавившись от львиной доли рефлекшена. А можно вобще свой форматтер специализированный создать, вобще рефлекшен не использующий и работающий с максимальной скоростью.
V>У меня стоит двоякая задача: V>1. решить эту конкретную задачу V>2. разжиться эффективным скрипт-движком
Ну так не надо оправдывать свой исследовательский интерес тем, что якобы стандартными средствами твою задачу не решить.
V>Я в этой же ветке Владу ответил довольно развернуто показав технику, которую использую.
Поверь мне, Америку ты не открыл. Без подобных вещей мы вобще получим замедление на несколько порядков. Но и с ними все будет медленно. Фактически любой вызов внешней функции превращается в аналог рефлекшена.
V> Мне интересно так же и твое мнение, где именно в той системе у меня могут быть чудовищные проседания в производительности. Мне кажется, что разница будет раза в 2-3 максимум.
Тебе кажется, а я пробовал.
AVK>>Мощные у тебя юзеры, набить десятки тысяч формул, я таких не встречал. В любом случае это все равно копейки.
V>Аналитическая on-line система.
И? Ты всерьез веришь что кто то будет десятки тысяч формул набивать? Да даже если и так — у него фантазии не хватит набить десятки тысяч разных формул. Ну и наконец десять тысяч микроклассов это совсем немного памяти.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну и? Сериализация конечно довольно медленная вещь, но по масштабам скомпилированного кода. И даже ее можно ускорить. Можно реализовать ISerializable, избавившись от львиной доли рефлекшена. А можно вобще свой форматтер специализированный создать, вобще рефлекшен не использующий и работающий с максимальной скоростью.
V>>У меня стоит двоякая задача: V>>1. решить эту конкретную задачу V>>2. разжиться эффективным скрипт-движком
AVK>Ну так не надо оправдывать свой исследовательский интерес тем, что якобы стандартными средствами твою задачу не решить.
Ок, попробуем мой вариант vs сериализация. Даже суррогаты свои для сериализации напишу, дабы ускорить это дело... когда баловался ранее с вызовами из другого домена то мне показалось что все это очень медленно.
AVK>И? Ты всерьез веришь что кто то будет десятки тысяч формул набивать?
Сотни юзверей в день.
AVK>Да даже если и так — у него фантазии не хватит набить десятки тысяч разных формул.
Кстати, да, ведь формулы можно кешировать Действительно, тогда рост числа вариантов может быть не столь большим.
В общем, обсуждение откладывается до получения результатов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[31]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Andir, Вы писали:
A>Откуда это взято? Я вроде как слежу за развитием монодевелопера, но ни разу не слышал о том, что он отпочковался от SharpDevelop ...
Честно говоря точно не скажу. Точно попадалось на сайте шарп-девелопера да и на go-mono по-моему было. На icsharpcode.net можно еще вики посмотреть — там помнб была какая-то трогательная история о том, как они хотели сделать шарп-девелоп межплатформенным и что из этого вышло.
А вообще мне казалось, что это общеизвестный факт. Даже вот на википедии пишут — http://en.wikipedia.org/wiki/MonoDevelop
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[32]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А вообще мне казалось, что это общеизвестный факт. Даже вот на википедии пишут — http://en.wikipedia.org/wiki/MonoDevelop
К слову — этот самый MonoDevelop вроде имеет какую-то встроенную поддержку Nemerle. Вот только потрогать его у меня нету возможности, а ставить 'nix только ради него неохота.
Re[30]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, vdimas, Вы писали:
AVK>>И? Ты всерьез веришь что кто то будет десятки тысяч формул набивать?
V>Сотни юзверей в день.
И? При одних и тех же данных вероятность того, что они будут набивать одинаковые формулы очень высока.
V>Кстати, да, ведь формулы можно кешировать Действительно, тогда рост числа вариантов может быть не столь большим.
Здравствуйте, Oyster, Вы писали:
O>К слову — этот самый MonoDevelop вроде имеет какую-то встроенную поддержку Nemerle. Вот только потрогать его у меня нету возможности, а ставить 'nix только ради него неохота.
А разве его нельзя запустить под виндой? Поставить Моно и ГТК-шарп.. Мне казалось, можно.
Вообще учитывая отсутсвие (если конечно ничего не поменялось) нормальной интеграции с дебагером толку от этой поддержки не шибко много.
Перспективнее ИМХО будет тогда скооперироваться с разработчиками Немерле и шарп-девелопа, чтобы там появилась поддержка Немерле. Благо, #D 2.0 производит уже достаточно функциональное, скажем так, впечатление.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[34]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А разве его нельзя запустить под виндой? Поставить Моно и ГТК-шарп.. Мне казалось, можно.
Я не знаю, если честно. Можно, говоришь? Тогда я попробую, конечно...
ВВ>Вообще учитывая отсутсвие (если конечно ничего не поменялось) нормальной интеграции с дебагером толку от этой поддержки не шибко много. ВВ>Перспективнее ИМХО будет тогда скооперироваться с разработчиками Немерле и шарп-девелопа, чтобы там появилась поддержка Немерле. Благо, #D 2.0 производит уже достаточно функциональное, скажем так, впечатление.
А я верю в плагин к студии 2005
Re[34]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Перспективнее ИМХО будет тогда скооперироваться с разработчиками Немерле и шарп-девелопа, чтобы там появилась поддержка Немерле. Благо, #D 2.0 производит уже достаточно функциональное, скажем так, впечатление.
У них в репозитории есть corsavy-addin. Похоже, правда, что давно не обновлялся. И подсветка синтаксиса у меня не работает
И еще есть Asper — IDE для Nemerle написанная на Nemerle. Бинарники в репозитории для 1.1. А под 2.0 я ее не смог собрать.
Здравствуйте, Воронков Василий, Вы писали:
A>>Откуда это взято? Я вроде как слежу за развитием монодевелопера, но ни разу не слышал о том, что он отпочковался от SharpDevelop ...
ВВ>Честно говоря точно не скажу. Точно попадалось на сайте шарп-девелопера да и на go-mono по-моему было. На icsharpcode.net можно еще вики посмотреть — там помнб была какая-то трогательная история о том, как они хотели сделать шарп-девелоп межплатформенным и что из этого вышло. ВВ>А вообще мне казалось, что это общеизвестный факт. Даже вот на википедии пишут — http://en.wikipedia.org/wiki/MonoDevelop
Вот так вот, век живи — век учись Никогда бы не подумал. Спасибо.
Здравствуйте, alive, Вы писали:
A>У них в репозитории есть corsavy-addin. Похоже, правда, что давно не обновлялся. И подсветка синтаксиса у меня не работает
Не знаю, мне кажется, что если разработчиков этого самого корсави (он же #D 2.0) заинтересовать немерле, то дело может пойти куда быстрее чем с плагином для студии. Благо, исходники среды полностью открыты.
Не думаю, что Nemerle стал стандартом, чтобы диктовать стандарты для других. Правила форматирования едены для всех языков донтета. И мы на сайте старамся их придерживаться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не знаю, мне кажется, что если разработчиков этого самого корсави (он же #D 2.0) заинтересовать немерле, то дело может пойти куда быстрее чем с плагином для студии. Благо, исходники среды полностью открыты.
Здравствуйте, vdimas, Вы писали:
V>Да, чистая интерпретация всяко медленнее компиляции. Однако, представим себе, что многие операторы и ф-ии уже вшиты в систему. Реально проигрыш примерно в 2-3 раза у нас (субъективно, точно пока не замеряли).
Если сравнивать скорость выполнения кода, то интепретация (любая) будет где-то от 10 раз и выше. Ну, а вызов гтовой функции добротно реализованной на языке с хорошим компилятором конечно может быть не заметен на фоне времени работы этой функции. Это я уже говорил. только о каких 2-3 раза тут можно говорить? Но формулы подразумевают под собой именно вычисления. А раз так, то при интенсивных вычислениях... короче, я повторяюсь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>В случае необходимости, для какого-либо типа BLToolkit генерирует и создаёт экземпляр наследника от TypeAccessor. Этот объект предназначен для создания экземпляров изсходного типа и доступа к его членам в обход Reflection. Т.е. в TypeAccessor'е генерируется пара методов CreateInstance, а для каждого члена исходного типа наследник MemberAccessor, который содержит сгенерированные методы GetValue, SetValue и ещё некоторые служебные методы. Далее это используется для маппинга, валидации, баиндинга и прочих вещей, которые требуют динамическое создание и доспут к членам какого-либо объекта.
Это плохой подход. Если в руках есть такой мощьный инструмент как метапрограммирование, лучше не использовать доступ через object-ы, а создавать специальные объекты владеющие информацией о структуре тех объектов с которыми нужно работать. Я не соображу как называется этот паттерн, но он здесь очень кстати.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Ты все перепутал. Есть Феникс. Феникс — это бэкэнд, но не оптимизирующий или для дотнета, а общий бэкэнд для всех компиляторов МС. Его можно использовать и для генерации MSIL-а, и для пре- или джит-компиляции готовых дотнетных сборок. Кроме того его можно применять для модификации МСИЛ-а готовых сборок и для генерации кода компиляторами. В частности планируется перевести VС++ на Феникс.
V>Мне показалось, что я ничего не перепутал: http://research.microsoft.com/phoenix/faq.aspx
V>
V>What is Phoenix?
V>Phoenix is a software optimization and analysis framework that is the basis for all future Microsoft compiler technologies. The Phoenix framework is an extensible system that can be adapted to read and write binaries and MSIL assemblies and to represent the input files in an IR, which can be analyzed and manipulated by applications by using the Phoenix API. The code can then be written in binary or JITable form for execution.
Ну, вот и прочти все по внимательнее. И оптимизация, и анализ — это всего лишь фичи.
Короче говорю открытым текстом. Если уже есть МСИЛ-ные модули, то они и так будут способны компилироваться или модифицироваться с помощью Феникса.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Действительно, тогда рост числа вариантов может быть не столь большим.
