На чём сейчас пишут erp (незнаю, какой подобрать нормальный термин, программы управления предприятием)? Действительно ли производительность erp систем уже отошла на второй план, а на первый: функциональность + расширяемость?
Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки).
Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta). Если брать С++ то надо писать парсер маппирования данных, новую компонентную систему (COM/CORBA не подходит). Рвусь писать на .Net — так как это там всё гораздо проще, но вот его производительность и прожорливость меня останавливает.
зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
11.01.05 10:38: Перенесено из 'Философия программирования'
Здравствуйте, Максим Зелински, Вы писали:
МЗ>зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
А зря. Из-за таких нежданчиков на моей памяти сроки проектов вырастали в разы.
Здравствуйте, AndrewVK, Вы писали:
AVK>А зря. Из-за таких нежданчиков на моей памяти сроки проектов вырастали в разы.
Это уже 4 мой проект с этими ребятами (хотя сейчас я может буду работать с C#). Там QA настолько жестокий, что аж искры летят
Так что мне выбрать? Можно ли смериться с гипотетической потерей производительности C#?
Здравствуйте, AndrewVK, Вы писали:
AVK>Мы смирились. Тем более что производительность обычно не в процессор упирается.
В память?
А вобще, какие сейчас "мировые" тенденции в области erp софта? В смысле языков.
Здравствуйте, Максим Зелински, Вы писали:
AVK>>Мы смирились. Тем более что производительность обычно не в процессор упирается. МЗ>В память?
В БД.
МЗ>А вобще, какие сейчас "мировые" тенденции в области erp софта? В смысле языков.
Если говорить об относительно свежем софте, то Java. О .NET пока говорить рановато, но о создании платформ на нем в России объявили несколько крупных контор.
Здравствуйте, AndrewVK, Вы писали:
AVK>но о создании платформ на нем в России объявили несколько крупных контор.
Извените, что использую вас за места гугля, но я первый раз это слышу, не могли бы вы написать кто они?
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Надо написать такую, есть выбор между C++ (производительность) и C# (простота разработки).
C++ — даже не думай об этом.
МЗ>Нюанс в том, что эта erp — по сути "конструктор" (наподобии 1С или Axapta). Если брать С++ то надо писать парсер маппирования данных, новую компонентную систему (COM/CORBA не подходит). Рвусь писать на .Net — так как это там всё гораздо проще, но вот его производительность и прожорливость меня останавливает.
Забей. Во первых, языки дотнета довольно шустры, посмотри тесты. На численных расчетах они на равных с С++.
К тому же, все равно твоя еэрпя упрется в базу данных, это не численные методы. Это во вторых. Если ты запустишь профайлер на 1С-коде (там очень тормозной интерпретатор), ты сможешь сам увидеть раскладку 90/10%. Да и вообще, такая раскладка имеет место быть в большинстве правильно написанных приложений БД. Это если говорить о двухзвенке.
В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака) того стоит, чтобы на него плюнуть, не говоря о том, что ты просто его не заметишь. К тому же, аллокатор дотнета работает в целом лучше, чем стандартный плюсовый . Бояться надо другого. Большие boxed массивы маленьких объектов — в этом проблема (решаемая), а не в сборщике мусора.
Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
МЗ>зы. Я буду писать в комманде (я главный архитектор), у меня есть как С++ программисты, так и C# программисты. Бяков утечек памяти/крахов указателей я от С++ не жду.
А это как раз не проблема. Ты с компонентной моделью и скриптингом гораздо больше натрахаешься.
Здравствуйте, Максим Зелински, Вы писали:
МЗ>Так что мне выбрать? Можно ли смериться с гипотетической потерей производительности C#?
При грамоном использовании дотнета и наличии достаточного количества памяти, и естественно, при условии что в одном из случаев вы не сделаете каких-нибудь глупостей... можно ожидать потерю в скорости до 1.1-1.5 раз. Если высвободившееся время пустить на оптимизацию алгоритмов и поиск более грамотных проектных решений, то... ну, думаю ты понял.
Ну, и главное! От С++ как средства оптимизации отказыватьс совершенно не нужно. Если вы обнаружите узкие места которые, по вашему мнению, могут быть устранены реализацией узких мест на С++, то спокойно переисывайте их на нем и смотрите что получилось.
Скорсоть MC++ практически идентична анменеджед VC той же версии.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Согласен со всем сказанным. Но...
G>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
Практика показывает, что в реальной системе гораздо большее влияние на производительность оказывают такие вещи, как архитектура системы, оптимальность запросов к СУБД, сама СУБД. На фоне всего этого падение производительности от managed кода C# ничтожна. А вот GUI на С#/WinForms может здорово тормозить здорово, по сравнению с MFC/VCL.
G>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака)
Хм.. Я вот поглядывал process explorer'ом — он часто показывает время GC посущественнее — процентов 20 бывает, а в пике — и того больше. Это все на глаз, конечно, так что несерьезно.
G>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал.
Я тут подумал, а что мешает организовать программируемую бизнес-логику на С#. Вроде особых проблем не вижу (только плюсы).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
G>>Поэтому не парься, пиши все на шарпах, а в качастве языка программируемой бизнес-логики возьми JScript.NET — это динамически типизированный язык с аннотацией типов — то, что доктор прописал. GZ>Я тут подумал, а что мешает организовать программируемую бизнес-логику на С#. Вроде особых проблем не вижу (только плюсы).
Ее можно организовать вообще на чем угодно, принципиальных проблем нет.
Первое. Динамическая типизация избавит вас от необходимости делать приведения типов "вниз" по иерархии наследования и запрашивать интерфейсы, что (в ряде случаев) очень положительно сказывается на том, как выглядит пользовательский код.
Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.
Для простых объектных моделей разницы между С# и JScript.NET как языков бизнес-логики действительно не будет (как и каких-либо плюсов от использования С# — JScript.NET язык с аннотицаей типов), а столнетесь со сложными — сами поймете, когда и где вам поможет динамическая типизация.
Здравствуйте, Igor Trofimov, Вы писали:
G>>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака)
iT>Хм.. Я вот поглядывал process explorer'ом — он часто показывает время GC посущественнее — процентов 20 бывает, а в пике — и того больше. Это все на глаз, конечно, так что несерьезно.
Это в пике, это не считается.
iT>А ваши 5% — откуда померяны/прочитаны?
Из статей о современных GC, сейчас уже не помню где именно. Кажется, такие цифры приводились для GC под С++ (там вообще пессемистическая схема — все проверяется на "живой" указатель. Тормозить должно больше чем с метаинформацией).
В принципе, не составит труда написать приложение которое загрузит GC по самое не балуйся, если поставить себе такую задачу специально. А можно постараться вообще память выделять по минимуму и реюзать все что возможно (как делают программисты под J2ME, чтобы не нагружать GC). Так что цифры условные, все конечно зависит от приложения.
Здравствуйте, Igor Trofimov, Вы писали:
G>>В случае трехзвенки — утечки памяти и крэши на серваке (где цена ошибки гораздо выше) — неприятная штука. Совсем небольшой минус от сборщика мусора (не более 5% от времени полезной работы сервака)
iT>Хм.. Я вот поглядывал process explorer'ом — он часто показывает время GC посущественнее — процентов 20 бывает, а в пике — и того больше. Это все на глаз, конечно, так что несерьезно.
Хм, а сколько времени занимала бы в тех же случаях "ручная" аллокация-деаллокация, вот что интересно . Она же тоже не бесплатна. Надо бы и это принять во внимание, по хорошему, а не просто смотреть время GC.
iT>А ваши 5% — откуда померяны/прочитаны?
В этом свете данные о 5% оверхэде для плюсовых сборщиков наиболее корректны — это как раз замеряно сравнением с "ручной сборкой" на тех же программах. Что проблематично сделать в случае дотнета.
Кстати, удивительное рядом. В статьях о GC также иногда пишут как о чем-то само-собой разумеющемся, что сборка мусора на основе подсчета ссылок менее эффективна, чем анализ графа зависимостей (mark-and-sweep и stop-and-copy). Несколько раз встречал.
Gaperton пишет:
> Кстати, удивительное рядом. В статьях о GC также иногда пишут как о > чем-то само-собой разумеющемся, что сборка мусора на основе подсчета > ссылок *менее *эффективна, чем анализ графа зависимостей > (mark-and-sweep и stop-and-copy). Несколько раз встречал.
Так и есть, в подавляющем большинстве случаев. Так как в многотредных
приложениях каждое присваивание refconted-ссылки будет требовать
блокировки ДВУХ мьютексов.
Здравствуйте, Gaperton, Вы писали:
G>Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.
Какие-же преимущества он дает? Возможность использование системы менее квалифицированными программистами?
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Второе (менее очевидное) — динамически типизированный язык в качестве языка бизнес логики дает больше свободы при разработке объектной модели.
S>Какие-же преимущества он дает? Возможность использование системы менее квалифицированными программистами?
, Галактика, МС 
