Здравствуйте, greenpci, Вы писали:
G>КУДА на подойдет, это же GPU, как я понимаю. У этого приложения распределение идет на workers и облако.
А тогда тем более не подойдёт. Платформа для распределённых вычислений под шарп (orleans) появилась только недавно и на сегодня местами не допилена (например, низзя обновить код без остановки хоста) плюс прибита гвоздями к Azure. Не, если пойти на принцип, то можно конечно, но никаких причин кроме как "поискать приключений" я не вижу
Здравствуйте, Sinix, Вы писали:
S>А тогда тем более не подойдёт. Платформа для распределённых вычислений под шарп (orleans) появилась только недавно и на сегодня местами не допилена (например, низзя обновить код без остановки хоста) плюс прибита гвоздями к Azure. Не, если пойти на принцип, то можно конечно, но никаких причин кроме как "поискать приключений" я не вижу
Если нашим боссам дать гарантию, что время и пространство (имею ввиду пямять и количество нодов для вычислений) не увеличится, то они с радостью перейдут на дотнет. На наш сишный код была потрачена куча времени для его оптимизации. Программисты профайлили исполнение в ВиТюне и ускоряли тайт люпы, то есть все куски кода, которые выполняются много раз. Так же, делали всякие хитрые вещи для сокращения памяти.
Я предполагаю, что можно напрячься и написать супер оптимизированный дотнет код, но для этого надо очень хорошо знать, что дотнет делает "под капотом" и писать так, что бы все это работало так же быстро, как и написанный "напрямую" сишный код. Трудоемкость такой работы не будет меньше, чем писать на сях напрямую, а может быть даже и больше. А работая над нашим продуктом три года, я не встретил сколько нибудь существенных сложностей, только из-за того, что это си плюс плюс, а не дотнет. Ну кроме только того, что в голове у менеджера, были программисты с этикеткой "могу си" и "не могу си" и он не может их всех "бросать" на одну амбразуру, а так хочется крикнуть "Сегодня все на Core. А не получится, ведь вася и петя не могут си". Нынешний менеджмент такого препятсвия очень не любит.
Поэтому, в этой переписке на дотнет, была бы только маркетинговая привлекательнось. Многие удивятся, но зарплата плюсника в Австралии меньше, чем шарпера при прочих равных. Плюсистов на рынке тьма. Честно говоря, я не понимаю, зачем все так хотят переписать все на дотнет и джаву. Я понимаю, что гуй и все где "пямять- не ресурс" писать на дотнете быстрее и дешевле. А там где это ресурс, затраты такие же, как минимум, а то и выше. Есть знакомый джавист, который пишет быстрый коннективити на джаве. Он рассказывал, как они там извращяются, что бы сделать это действительно быстрым. По его рассказам, трудоемкость не меньше, чем писать на плюсах и думают они так же, как плюсисты. Просто делают все через призму джавы, то есть еще один уровень абстракции, с которым нужно иметь дело.
Здравствуйте, Sinix, Вы писали:
Aё>>Я бы не был уверен насчёт жита дотнета- взять хотя бы его неспособность житить лишь горячие участки. Насчёт до предела оптимизаций- Matematica написана на Java и умеет CUDA, т.е. работает быстрее, а память- не ресурс.
S>Hotspot jit во многом нужен из-за отсутствия value types в яве.
Это открытие тянет на Нобелевскую премию
S> Без них разница с шарпом непринципиальна (что как бы очевидно, в рамках времени, отводимого на jit, ничего сильно пристойного всё равно не сделать).
Просто уточню, что стандартные коллекции Java боксят любой элемент, потому они медленнее, чем в .NET где есть реализация коллекций под встроенные типы. Но для Java есть сторонние коллекции- под встроенные типы. Теперь по JIT-у — .NET-й не может интерпретировать, потому он всё подряд житит. А качественно оптимизировать jit-й код требует ресурсов, значит есть компромиссы. В отличие от Java JIT, где житятся только горячие участки и может неоднократно jit-ть поверх на критических вещах.
S>В свежих релизах с .NetCore и RyuJit положение потихоньку выправляется, особенно с учётом .net native и возможности трансляции в llvm. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть.
В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.
Здравствуйте, greenpci, Вы писали:
G>Если нашим боссам дать гарантию, что время и пространство (имею ввиду пямять и количество нодов для вычислений) не увеличится, то они с радостью перейдут на дотнет. На наш сишный код была потрачена куча времени для его оптимизации. Программисты профайлили исполнение в ВиТюне и ускоряли тайт люпы, то есть все куски кода, которые выполняются много раз. Так же, делали всякие хитрые вещи для сокращения памяти.
1) И все-все алгоритмы оптимальные использовали?
2) Правда? А что, byte[] и прочие примитивные массивы уже отменили в дотнете / яве ?
G>Я предполагаю, что можно напрячься и написать супер оптимизированный дотнет код, но для этого надо очень хорошо знать, что дотнет делает "под капотом" и писать так, что бы все это работало так же быстро, как и написанный "напрямую" сишный код. Трудоемкость такой работы не будет меньше, чем писать на сях напрямую, а может быть даже и больше. А работая над нашим продуктом три года, я не встретил сколько нибудь существенных сложностей, только из-за того, что это си плюс плюс, а не дотнет. Ну кроме только того, что в голове у менеджера, были программисты с этикеткой "могу си" и "не могу си" и он не может их всех "бросать" на одну амбразуру, а так хочется крикнуть "Сегодня все на Core. А не получится, ведь вася и петя не могут си". Нынешний менеджмент такого препятсвия очень не любит.
Путаешся в показаниях. То у тебя ядро оптимизированное и его нельзя трогать, то все морды на ПХП пишут
В реальности ядра того не сильно много окажется
Хотя прекрасно понимаю, что нахрена что-то менять, если оно работает.
Кстати, судя по распределенности, у вас совсем не реалтайм, а просто молотилка, которой важнее пропускная способность. А вот это уже территория, где выбор плюсов совсем не очевиден.
G>Поэтому, в этой переписке на дотнет, была бы только маркетинговая привлекательнось. Многие удивятся, но зарплата плюсника в Австралии меньше, чем шарпера при прочих равных. Плюсистов на рынке тьма. Честно говоря, я не понимаю, зачем все так хотят переписать все на дотнет и джаву.
Потому шта развивать продукт на управляемых языках оказывается дешевле. Time to market короче.
G>Я понимаю, что гуй и все где "пямять- не ресурс" писать на дотнете быстрее и дешевле. А там где это ресурс, затраты такие же, как минимум, а то и выше. Есть знакомый джавист, который пишет быстрый коннективити на джаве. Он рассказывал, как они там извращяются, что бы сделать это действительно быстрым. По его рассказам, трудоемкость не меньше, чем писать на плюсах и думают они так же, как плюсисты. Просто делают все через призму джавы, то есть еще один уровень абстракции, с которым нужно иметь дело.
Ну давай, расскажи *мне* как коннекторы на Яве писать Я тут connectivity framework-ами развлекаюсь
Коннектор, жрущий больше 50 мег памяти (на Яве) — это уже очень подозрительный коннектор. Даже если *вообще* ничего не оптимизировать, то мусор с 20-40 меговой кучи собирается с практически нулевым stop-the-world (например с G1 сборщиком). Это, повторю, *без оптимизаций*.
Если надо совсем мусора избегать, то под отправляемые / принимаемые блоки выделяешь память в начале дня / добавляешь в течении дня в случае пиков и переиспользуешь эти объекты (вместо new T делаешь T.set(...) ).
Дальше даешь сразу памяти при помощи Xms=Xmx, чтобы при выделении памяти затыков не было посреди дня, и это, в принципе, все.
Здравствуйте, mapnik, Вы писали:
M>"С# такая няшечка, в нем столько красивых рюшечек...". Все это в целом мило, но что насчет реально нужных фич, которые имеют действительно сильные проверенные временем ОО-языки? M>Простейший пример оператор const в С++ в применении к функциям (Constant Member Functions).
M>Discuss, господа, discuss
Здравствуйте, mik1, Вы писали:
M>Если надо совсем мусора избегать, то под отправляемые / принимаемые блоки выделяешь память в начале дня / добавляешь в течении дня в случае пиков и переиспользуешь эти объекты (вместо new T делаешь T.set(...) ).
Мне пока что не удавалось совсем уж избегать создания объектов-обёрток над байтами. Т.е. коллектор таки работает всегда и прибивает коротко живущие обёртки на потоке.
M>Где тут твои "призмы" — хз.
Значит greenpci имел в виду не тебя? А я так вообще программировать не умею.
Здравствуйте, mik1, Вы писали:
G>>Если нашим боссам дать гарантию, что время и пространство (имею ввиду пямять и количество нодов для вычислений) не увеличится, то они с радостью перейдут на дотнет. На наш сишный код была потрачена куча времени для его оптимизации. Программисты профайлили исполнение в ВиТюне и ускоряли тайт люпы, то есть все куски кода, которые выполняются много раз. Так же, делали всякие хитрые вещи для сокращения памяти.
M>1) И все-все алгоритмы оптимальные использовали?
где надо
M>2) Правда? А что, byte[] и прочие примитивные массивы уже отменили в дотнете / яве ?
G>>Я предполагаю, что можно напрячься и написать супер оптимизированный дотнет код, но для этого надо очень хорошо знать, что дотнет делает "под капотом" и писать так, что бы все это работало так же быстро, как и написанный "напрямую" сишный код. Трудоемкость такой работы не будет меньше, чем писать на сях напрямую, а может быть даже и больше. ...
А что объявить byte[] и работать с ним на плюсах труднее?
M>Путаешся в показаниях. То у тебя ядро оптимизированное и его нельзя трогать, то все морды на ПХП пишут
не понял. Да морда на WPF, ядро на сях. В чем противоречие?
M>В реальности ядра того не сильно много окажется
И чем это противоречит тому, что я сказал?
M>Хотя прекрасно понимаю, что нахрена что-то менять, если оно работает.
Возьми время, пространство и результат вычислений за константу. Предположим, для академического интереса, ты перепишешь это все на дотнет с сохранением констант. И что ты думаешь, с этим дотнет кодом быстрее или дешевле будет работать? Тайм ту маркет будет лучше?
M>Кстати, судя по распределенности, у вас совсем не реалтайм, а просто молотилка, которой важнее пропускная способность. А вот это уже территория, где выбор плюсов совсем не очевиден.
дело не в абстрактной территории, а в нашей специфической задаче. Клиенты не хотят, что бы увеличивалось время и пространство.
M>Потому шта развивать продукт на управляемых языках оказывается дешевле. Time to market короче.
Речь не идет о продукте в целом, а об отдельной его части.
M>Ну давай, расскажи *мне* как коннекторы на Яве писать Я тут connectivity framework-ами развлекаюсь
M>Коннектор, жрущий больше 50 мег памяти (на Яве) — это уже очень подозрительный коннектор. Даже если *вообще* ничего не оптимизировать, то мусор с 20-40 меговой кучи собирается с практически нулевым stop-the-world (например с G1 сборщиком). Это, повторю, *без оптимизаций*. M>Если надо совсем мусора избегать, то под отправляемые / принимаемые блоки выделяешь память в начале дня / добавляешь в течении дня в случае пиков и переиспользуешь эти объекты (вместо new T делаешь T.set(...) ). M>Дальше даешь сразу памяти при помощи Xms=Xmx, чтобы при выделении памяти затыков не было посреди дня, и это, в принципе, все.
И что?
M>Где тут твои "призмы" — хз.
ты прямо в машинных кодах лабаешь? Или у тебя другое понимание выражения "уровень абстракции"?
1) Time to market уменьшается для последующих изменений.
2) Я не думаю, что с byte[] в Яве управляться труднее, чем в плюсах. Соот-но, время и пространство не факт, что ухудшатся.
3) То, что на Яве молотилки / near realtime делать труднее, чем на плюсах — миф.
Здравствуйте, greenpci, Вы писали:
G>Все равно останется одна проблема, программисты на дотнете стоят дороже программистов на сях в австралии
Зарплата зависит от предметной области. Таким образом, даже если абстрактный программист на сях с опытом железок или MFC-кала попробует устроиться на проект, где финансы на шарпе- его не возьмут, даже задёшево не возьмут. А с релевантным опытом плюсника оторвут с руками- и ещё вопрос, захочет ли он сам переходить на калософт .net.
Здравствуйте, greenpci, Вы писали:
G>Здравствуйте, mik1, Вы писали:
M>>Еще раз повторю. M>>1) Time to market уменьшается для последующих изменений. G>не надо повторять.
Надо, к сожалению надо. До многих это не доходит годами.
M>>2) Я не думаю, что с byte[] в Яве управляться труднее, чем в плюсах. Соот-но, время и пространство не факт, что ухудшатся. G>я и не говорил, что труднее и не говорил, что ухудшатся. M>>3) То, что на Яве молотилки / near realtime делать труднее, чем на плюсах — миф. G>я не говорил, что труднее. G>Все что я сказал: [b]Трудоемкость такой работы не будет меньше, чем писать на сях напрямую[/b]
Из выделенного очевидно следует равенство сложностей? Я вот знаком с >1 перебежчиков из C++ HPC, считающих что они не менее качественный код пишут заметно быстрее (по времени написания) на Яве.
G>Даже если исходить из того, что G>трудоемкость си = трудоемкость дотнет
Не "даже", а именно так исходя из написанного тобой выше.
G>в нашей задаче Все равно останется одна проблема, программисты на дотнете стоят дороже программистов на сях в австралии, например.
Ну это ты нашел чем гордиться, да... А потом создаешь темы о дорогом жилье в Сиднее.
Здравствуйте, mik1, Вы писали:
M>Из выделенного очевидно следует равенство сложностей? Я вот знаком с >1 перебежчиков из C++ HPC, считающих что они не менее качественный код пишут заметно быстрее (по времени написания) на Яве.
Значит, в их проектах не было таких жестких ограничений, как в моем случае. У них был плюсный, оптимизированный продукт, который изначально замерили и после переписки нельзя было ничего добавить, ни памяти ни количество нодов? Скорее всего, окажется, что у них "память- не ресурс". И разговор не о качестве, а об ограничениях.
G>>Даже если исходить из того, что G>>трудоемкость си = трудоемкость дотнет
M>Не "даже", а именно так исходя из написанного тобой выше.
А ты утверждаешь, что можно написать все тоже самое на дотнете, сохранив все ограничения и после этого будет быстрее и легче, с этим работать, чем на сях. Смелое утверждение. Особенно от человека, который не видел наш продукт и даже не знает, что он делает. То есть, я так понимаю, ты говоришь так: все числодробилки на сях, можно переписать на дотнет, сохранив их показатели и в них будет легче и быстрее делать изменения.
G>>в нашей задаче Все равно останется одна проблема, программисты на дотнете стоят дороже программистов на сях в австралии, например.
M>Ну это ты нашел чем гордиться, да... А потом создаешь темы о дорогом жилье в Сиднее.
Переход на личности, однако. Ну ладно, только причем здесь гордость? Не говоря уже о том, что я в такой же мере дотнет программист, как и плюсист. В данный момент, я могу выбирать с чем мне работать.
Здравствуйте, Aртём, Вы писали:
Aё>Зарплата зависит от предметной области. Таким образом, даже если абстрактный программист на сях с опытом железок или MFC-кала попробует устроиться на проект, где финансы на шарпе- его не возьмут, даже задёшево не возьмут. А с релевантным опытом плюсника оторвут с руками- и ещё вопрос, захочет ли он сам переходить на калософт .net.
То есть ты говоришь, что нигде не берут без релевантного опыта. Ну тебя же взяли. Или ты с рождения имел релевантный опыт?
Здравствуйте, greenpci, Вы писали:
G>То есть ты говоришь, что нигде не берут без релевантного опыта. Ну тебя же взяли. Или ты с рождения имел релевантный опыт?
У меня релевантный опыт был почти 4 года в финансах на тот момент (из общего овер 9000).
Здравствуйте, Aртём, Вы писали:
S>>Hotspot jit во многом нужен из-за отсутствия value types в яве. Aё>Это открытие тянет на Нобелевскую премию
Если тебе похамить — это к другому плиз. По факту ява (ClientVM) с -Xint и дотнет показывают примерно одинаковые результаты, пока дело не доходит до числомолотилок и структур. Там после некоторых приседаний всё тоже одинаково, но уже на server vm с соответствующими флагами
S>> Без них разница с шарпом непринципиальна (что как бы очевидно, в рамках времени, отводимого на jit, ничего сильно пристойного всё равно не сделать). Aё>Просто уточню, что стандартные коллекции Java боксят любой элемент, потому они медленнее, чем в .NET где есть реализация коллекций под встроенные типы. Но для Java есть сторонние коллекции- под встроенные типы.
Ну да, во времена первого дотнета так же было. Лет 10 назад.
Aё>Теперь по JIT-у — .NET-й не может интерпретировать, потому он всё подряд житит. А качественно оптимизировать jit-й код требует ресурсов, значит есть компромиссы. В отличие от Java JIT, где житятся только горячие участки и может неоднократно jit-ть поверх на критических вещах.
Спасибо, кэп
Ещё раз — на практике вся эта радость даёт 10-20% разброс, и не обязательно в плюс. Я видел и примеры кода, которые с -xInt выполнялись быстрее, ради справедливости, это было на jre 1.5 что ли.
Ну и с ".NET-й не может интерпретировать" — всё оно умеет, просто не выходило особо из недр MS Research. Разве что в .net micro остался (не помню, уже убрали или нет).
S>>В свежих релизах с .NetCore и RyuJit положение потихоньку выправляется, особенно с учётом .net native и возможности трансляции в llvm. Но, очевидно, в ближайщую пару релизов ничего сильно не изменится — сначала надо переползти толком на новые платформы, ничего сильно не потеряв. Дальше — будем посмотреть. Aё>В переводе на русский- Майкрософт, как всегда, налажал и не спешит исправляться.
*Заинтересованно* а ты вообще умеешь общаться без передёргиваний? Как в анекдоте блин, "дорогая, ты не права ... ... мама, он меня сукой назвал!!!"
Что-то я не вижу логики в "текущий шарп и ява по производительности в основном одинаковы" => "Майкрософт, как всегда, налажал".
S>> Без них разница с шарпом непринципиальна (что как бы очевидно, в рамках времени, отводимого на jit, ничего сильно пристойного всё равно не сделать). Aё>Просто уточню, что стандартные коллекции Java боксят любой элемент, потому они медленнее, чем в .NET где есть реализация коллекций под встроенные типы. Но для Java есть сторонние коллекции- под встроенные типы. Теперь по JIT-у — .NET-й не может интерпретировать, потому он всё подряд житит. А качественно оптимизировать jit-й код требует ресурсов, значит есть компромиссы. В отличие от Java JIT, где житятся только горячие участки и может неоднократно jit-ть поверх на критических вещах.
Что за бред? Java, кроме самого первого релиза, всегда джитила всё. Hotspotting — это повторный пере-jit горячих участков. А вы пишете так, как будто java всё интерпретирует, джиття только некоторые фрагменты.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Что за бред? Java, кроме самого первого релиза, всегда джитила всё. Hotspotting — это повторный пере-jit горячих участков. А вы пишете так, как будто java всё интерпретирует, джиття только некоторые фрагменты.
Прямо таки все? И прямо таки сразу? Как насчет static конструкторов?
И ключик -XX:+PrintCompilation очевидно совершенно бесполезен?
Здравствуйте, Sinclair, Вы писали:
S>Что за бред? Java, кроме самого первого релиза, всегда джитила всё. Hotspotting — это повторный пере-jit горячих участков. А вы пишете так, как будто java всё интерпретирует, джиття только некоторые фрагменты.
Adaptive optimization is a technique in computer science that performs dynamic recompilation of portions of a program based on the current execution profile. With a simple implementation, an adaptive optimizer may simply make a trade-off between Just-in-time compilation and interpreting instructions. At another level, adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion.
A Virtual Machine like HotSpot is also able to deoptimize a previously JITed code. This allows it to perform aggressive (and potentially unsafe) optimizations, while still being able to deoptimize the code and fall back on a safe path later on.
Aё>Adaptive optimization is a technique in computer science that performs dynamic recompilation of portions of a program based on the current execution profile. With a simple implementation, an adaptive optimizer may simply make a trade-off between Just-in-time compilation and interpreting instructions. At another level, adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion.
Aё>A Virtual Machine like HotSpot is also able to deoptimize a previously JITed code. This allows it to perform aggressive (and potentially unsafe) optimizations, while still being able to deoptimize the code and fall back on a safe path later on.
Угу. Вики такая вики.
Давайте посмотрим правде в глаза:
JRockit does not include an interpreter; so the JIT compilation of the byte code into native machine code has to occur before a method executes. The JIT compilation is performed the first time a Java method is called.
Т.е. в приличных JVM интерпретатора вовсе нет. То, что теоретически можно построить simple implementation, это хорошо. Но реальная Java уже лет 20 как устроена at another level, то есть HotSpot применяет оптимизации различной агрессивности в зависимости от наблюдений sampling-а. В частности, ЕМНИП (а я на Jave не писал года, примерно, с 2000го) спекулятивный инлайнинг и переупорядочивание бранчей в if и case стейтментах. Вряд ли за истекшие 15 лет JVM стали сильно тупее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я тут connectivity framework-ами развлекаюсь 
