Re[5]: Сложный язык для сложных срограмм.
От: dmz Россия  
Дата: 29.01.07 14:19
Оценка: +3
АХ>>Примеры?

J>У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была J>переписана с жавы на С++, обычно по соображениям производительности.


Ну я тоже видел этот софт — и мне лично кажется, что эти "соображения производительности" — фигня
на постном масле. Едва ли там делался сильно глубокий анализ узких мест и как их устранять. Как известно,
у любой задачи есть простое и неправильное решение.

Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места,
и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо.

А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у
который то тёк, то коредампился, и так — в течение длительного срока.

И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается
указателю, разыменовывается и возвращается ссылка — я тоже видел.,

Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак.

Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо —
являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали
все мощности сервера, и почти никак не масштабировался на несколько серверов.

Что же касается производительности... В одном известном тебе операторе сотовой связи,
большинство серверного софта, даже в части, связанной с телефонией, было написано на языках
высокого уровня — на Java и, немного, на C#.

И оно работает быстро, и при очень высокой нагрузке. И, что самое главное, в случае, когда производительности начинает не хватать — ставится новый сервер, вместо переписывания всего на C++, потом на C, потом на ASM, потом ...

Кстати, есть один большой показательный пример — из соображений "производительности" одну большую систему реализовали поверх С++ middleware, который по стилю очень похож на одну очень хорошо известную тебе систему.

Так вот, в результате поимели: длительный период нестабильности софта, очень долгую (для подобного объема функционала) разработку, несколькикратное превышение сроков и бюджетов.

При этом конечный результат не является чем-то запредельным по производительности, на фоне других приложений, реализованных на Java. Возможно, для обслуживания равного количества запросов ему требуется на пару серверов меньше — но что такое эта пара серверов по сравнению с парой месяцев разработки...

J>С остальным согласен.