Здравствуйте, alex_public, Вы писали:

_>>>Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.
_>·>Полная загрузка процессора в low latency как раз частенько используется — для того, чтобы операционка не вздумала вытеснить критичный тред. Ещё этот тред к одному ядру привязывается.
_>Это подходит только для простенькой задачки, в которой она единственная на системе и при этом сами вычисления не тяжёлые. Для более сложных случаев (например обработке видео в реальном времени) такие фокусы только помешают.
Я говорил о low latency/finance, а ты тут "обработка видео" — вообще из другой области. Обрабатывать видео с явой я и не собирался. Такие софистические фокусы только мешают.

Здравствуйте, alex_public, Вы писали:

EP>>>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.
_>·>Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.
_>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.
Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.
В java есть JNI, unsafe режим — издевательство какое-то.

Здравствуйте, ·, Вы писали:

PM>>>>>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>
PM>>·>Война была, да и до сих пор ведётся не с java, а с архитектурой и железом. 90% тех решений подходит и для С++.
PM>>Только цена усилий по улучшению быстродействия в проекте на C++ гораздо меньше.
·>Не правда.

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

PM>> Понадобилось попадание в кэш-линию и исключение false sharing — выровняли структуру. Не нужно переключение контекста — привязали поток к конкретному ядру.
PM>> SIMD, вычисления на GPU, сетевой стек в user space. В Java с этим будут трудности. И героически преодолевать их — см. выделенное.
·>И что из этого невозможно сделать ява?

Я разве где-то утверждал что это невозможно? Возможно, ведь в Java есть JNI, а в C# есть unsafe. Но если требуется писать unsafe class Program { static main() {...} } или значительная часть кода будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.

·>А какие именно трудности? Можно по пунктам?
·>SIMD инструкции генерятся JIT (хотя интересно услышать о их полезности в low latency/finance).
·>сетевой стек — это этот что-ли? http://docs.oracle.com/javase/tutorial/sdp/sockets/
·>GPU — тоже непонятна полезность, да и тоже куча всего http://stackoverflow.com/questions/22866901/using-java-with-nvidia-gpus-cuda
·>С остальным вообще не ясно что за проблемы, не рокет сайнс.

Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/

·>Я и не утверждало всём мире. Мир не завоевала, но LL нишу занимает прочно.

Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.

Здравствуйте, Ikemefula, Вы писали:

PM>>Да, да, "write once, run anywhere", Java завоюет мир... Когда-то читал про такое, лет 20 назад. По-моему ниша Java всё та же — корпоративные и банковские приложения. Может андроид слегка добавил, пока разработчики не выяснили, что писать мобильные приложения выгоднее с общим ядром на C++ и пользовательским интерфейсом под конкретную платформу.

I>Идея "write once, run anywhere" здохла. Тем не менее Джава с тех пор внятно пролезла и в микроконтроллеры, HPC, HFT, реалтайм, операционные системы, бортовая электроника и много куда еще.

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

Так что вас конечно же не затруднит привести список реальных продуктов где еще кроме энтерпрайза сейчас используется Java. Только, пожалуйста, без JME, фантомОс, кофеварок со встроенным Oak.

Здравствуйте, alex_public, Вы писали:

_>·>Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).
_>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?
Что иммутабельный объект после вызова деструктора меняет своё состояние.

Здравствуйте, T4r4sB, Вы писали:

TB>·>Тут в топике мне предлагают использовать голые указатели. Это правильное использование? А cyclic references тоже правильное?
TB>Если ты знаешь хозяина (unique_ptr) и его время жизни — то да.
Как это знание выразить в коде?

TB>>>Как можно грохнуть объект, пока он ещё кем-то используется? По-моему, это косяк программиста куда более серьёзный, чем просто какой-то битый указатель.
TB>·>В С++ — запросто. В java — никак.
TB>Как страшно жить!
А кто обещал, что будет легко...

TB>>>(я хз, к чему это, просто разговор поддержать)
TB>·>Конечно нельзя. Но обратиться к объекту, попавшему ГЦ на растерзание — тоже нельзя.
TB>И обратиться к объекту, который уничтожается — тоже нельзя, если программист понимает, что он делает.
TB>Если не понимает — то и жаба не поможет.
В смысле не поможет? Язык не позволяет обращаться к объекту, который уничтожается, без всяких "если".

TB> В целом в С++ напортачить проще, из-за чего он и не стал популярнее жабы.
Точнее он стал менее популярным, чем жаба.

Здравствуйте, Ikemefula, Вы писали:

I>>>Есть куча проектов, которые загнулись из за того, что так и не смогли сбороть этот GC.
I>·>А конкретнее? Ни одного С++ проекта не загнулась из-за сложности кода?
I>Джава приходит в реалтайм, трейдинг и тд и тд с большим опозданием. Во многих областях джавы и близко нет.
I>Собтсвенно, пытаются писать много, но взлетает далеко не все. Там где не взлетела джава, как правило уже лет 10 и больше С++ в полный рост.
А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.

I>>> Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.
I>·>Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.
I>Это заблуждение. У тебя практически вся архитектура приложения нацелена на минимизацию проблем с GC. Ты или забыл про это, или еще не понял.
Заблуждаешься.

Здравствуйте, ·, Вы писали:

·>Как это знание выразить в коде?
Ну типа тим-лид с линейкой чтоб ходил и по пальцам бил XD

·>А кто обещал, что будет легко...
Дык никто и не обещал, о чём спор-то?

·>В смысле не поможет? Язык не позволяет обращаться к объекту, который уничтожается, без всяких "если".
Ты упёрся лишь в одну проблему. В С++ она вполне решается при правильной организации. Вопрос лишь в цене этой организации. Из-за этого где-то один язык предпочтительнее, где-то другой.

Здравствуйте, PM, Вы писали:

PM>>>Только цена усилий по улучшению быстродействия в проекте на C++ гораздо меньше.
PM>·>Не правда.
PM>Ваше утверждение не выглядит убедительно. В этой и похожих темах уже показывалось, как код на Java превращается в нечитаемую тыкву в попытках оптимизации. В то время как C++ код остается на том же уровне абстракции не теряя общности.
Дело вкуса, а не усилий. Простота языка Явы позволяет писать "нечитаемые тыквы" только там где надо. По сравнению с Явой, практически весь сишный код выглядит как нечитаемая тыква.

PM>>> Понадобилось попадание в кэш-линию и исключение false sharing — выровняли структуру. Не нужно переключение контекста — привязали поток к конкретному ядру.
PM>>> SIMD, вычисления на GPU, сетевой стек в user space. В Java с этим будут трудности. И героически преодолевать их — см. выделенное.
PM>·>И что из этого невозможно сделать ява?
PM>Я разве где-то утверждал что это невозможно? Возможно, ведь в Java есть JNI, а в C# есть unsafe. Но если требуется писать unsafe class Program { static main() {...} } или значительная часть кода будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.
Ты пишешь будут трудности больше, чем в плюсах. Это неверно, ибо большинство упомянутых трудностей к языку не относятся. Единственное существенное отличие — это наличие GC, да, в каких-то случаях он создаёт проблемы, но в других случаях он значительно упрощает решение других проблем.

PM>·>А какие именно трудности? Можно по пунктам?
PM>·>SIMD инструкции генерятся JIT (хотя интересно услышать о их полезности в low latency/finance).
PM>·>сетевой стек — это этот что-ли? http://docs.oracle.com/javase/tutorial/sdp/sockets/
PM>·>GPU — тоже непонятна полезность, да и тоже куча всего http://stackoverflow.com/questions/22866901/using-java-with-nvidia-gpus-cuda
PM>·>С остальным вообще не ясно что за проблемы, не рокет сайнс.
PM>Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/
Не понял. И причём тут java vs C++?

PM>·>Я и не утверждало всём мире. Мир не завоевала, но LL нишу занимает прочно.
PM>Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.
Там совсем другие требования, всё гораздо проще, какой же это LL. С играми вообще всё пофиг — сломалось, так сломалось, да и большинство там вообще сейчас 99% LUA и прочий скриптинг. Видео|аудио — фигня, не нужны миллисекунды отклика для 99.99% и потеря пакетов не смертельна. Это всё high throughput и параллелизация.

Здравствуйте, Serginio1, Вы писали:

_>>Эээээ, как вообще можно указывать подобные цифры без точного описания железа? ) Как бы Atom с 1 GB RAM и 18-и ядерный Xeon с 256 GB RAM дают очень разную производительность и стоят очень разные деньги...
S> Ну я озвучил стоимость сервера равной ЗП программиста. Так что выбирай из этих условий.

Что за зарплата? За неделю, за месяц или за год? )

И кстати говоря, в вебе чаще арендуют сервера в дата-центрах, а не покупают свои.

_>>А что, тут кто-то предлагал писать бухгалтерские отчёты на C++? Естественно такое пишут на скриптовых языках (где-то это свой язык, как в 1C или SAP, а где-то и обычный, типа Python/JS) соответствующей платформы. А вот саму платформу пишут уже на C++, ну если конечно хочется хоть какого-то быстродействия. )))
S> Мы говорим о производительности. Так производительности скриптовых языков хватает в большинстве задач. А скорость .Net намного выше при этом дает динамическую типизацию через dynamic. Очень удобно при работе с неопределенными типами.
S>http://habrahabr.ru/post/144330/

Что-то я не понял про что ты конкретно говоришь. Вот у тебя сейчас есть нормальная работающая система: быстродействующая платформа (написанная на C++) и скриптовой язык в ней, для кастомизации на месте. Куда конкретно в этой схеме ты хочешь всунуть .net? )

Здравствуйте, Ikemefula, Вы писали:

_>>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.
I>Главное помнить о том, что нативные и управляемые решения за последние 20 лет практически поменялись местами, если смотреть долю рынка.

Если под управляемыми ты имеешь в виду в том числе и все скриптовые, то да, есть такое дело. Просто вследствие развития ниши для этих языков. Ну и кстати говоря они в большинстве случаев не заменяют, а дополняют (работают кастомизаторами) нативный код.

Здравствуйте, Serginio1, Вы писали:

_>>В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.
S>Какая разница какой. Он есть и в большинстве скорости хватает. Вот сравнение с C#
S>http://www.forum.mista.ru/topic.php?id=704876#4
S> И это просто пустого метода. Правда в 1С к каждому подключению идет инициализация юзера, но в этом тесте на пустой конфигурации. В Net это решается через токены авторизации, кэшировании клиента на сервере итд.
S> То есть в самом простом случае это 8-10 раз без вызова кода.
S>При этом сложность написания кода на C# не намного выше. Правда и возможностей выше. А вот скорость написания может быть даже выше за счт интеллисенсе и статическая проверка кода. Например многие используют TS вместо голого JS.

Редкостная бредятина. Как можно сравнивать законченный продукт (типа 1C) и голый язык. Вот пускай такие сравниватели в начале напишут на C# полноценный аналог 1C со всеми его возможностями, а потом уже проводят сравнения быстродействия.

Здравствуйте, ·, Вы писали:

EP>> vector<Widget> values(N);
·>И молись что N не слишком большой и не получится stack overflow на пустом месте.

Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:

_>>>Эээээ, как вообще можно указывать подобные цифры без точного описания железа? ) Как бы Atom с 1 GB RAM и 18-и ядерный Xeon с 256 GB RAM дают очень разную производительность и стоят очень разные деньги...
S>> Ну я озвучил стоимость сервера равной ЗП программиста. Так что выбирай из этих условий.

_>Что за зарплата? За неделю, за месяц или за год? )
Месяц.
_>И кстати говоря, в вебе чаще арендуют сервера в дата-центрах, а не покупают свои.

_>>>А что, тут кто-то предлагал писать бухгалтерские отчёты на C++? Естественно такое пишут на скриптовых языках (где-то это свой язык, как в 1C или SAP, а где-то и обычный, типа Python/JS) соответствующей платформы. А вот саму платформу пишут уже на C++, ну если конечно хочется хоть какого-то быстродействия. )))
S>> Мы говорим о производительности. Так производительности скриптовых языков хватает в большинстве задач. А скорость .Net намного выше при этом дает динамическую типизацию через dynamic. Очень удобно при работе с неопределенными типами.
S>>http://habrahabr.ru/post/144330/

_>Что-то я не понял про что ты конкретно говоришь. Вот у тебя сейчас есть нормальная работающая система: быстродействующая платформа (написанная на C++) и скриптовой язык в ней, для кастомизации на месте. Куда конкретно в этой схеме ты хочешь всунуть .net? )
Быстродействующая система на С++ которая проигрывает в 100-1000 раз .Net рассмешил.

У меня они работают параллельно http://infostart.ru/public/238584/ когда нужна скорость или расширение возможностей.
Я показал на разницу в скорости 1С и C#. То есть сейчас скорости для большинства задач хватает и для 1С. Если нужно увеличить, то проще увеличить за счет применения Net. Например уже готовых microsoft dynamics.
Обычно проблема в учетных системах это уже готовые модули для ведения учета, которые состоят из миллиона кода плюс изменения расчетов при сильноизменяющемся нашем законодательстве. Поэтому 1С так просто не сдвинуть.

Кроме того использую прямой доступ через Linq http://infostart.ru/public/402038/
Очень удобно на asp.Net
Во многом проблема даже не в скорости и возможностях, а поддержке существующих решений и количестве специалистов.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:

_>>>В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.
S>>Какая разница какой. Он есть и в большинстве скорости хватает. Вот сравнение с C#
S>>http://www.forum.mista.ru/topic.php?id=704876#4
S>> И это просто пустого метода. Правда в 1С к каждому подключению идет инициализация юзера, но в этом тесте на пустой конфигурации. В Net это решается через токены авторизации, кэшировании клиента на сервере итд.
S>> То есть в самом простом случае это 8-10 раз без вызова кода.
S>>При этом сложность написания кода на C# не намного выше. Правда и возможностей выше. А вот скорость написания может быть даже выше за счт интеллисенсе и статическая проверка кода. Например многие используют TS вместо голого JS.

_>Редкостная бредятина. Как можно сравнивать законченный продукт (типа 1C) и голый язык. Вот пускай такие сравниватели в начале напишут на C# полноценный аналог 1C со всеми его возможностями, а потом уже проводят сравнения быстродействия.
Давай сравним с Microsoft Dynamics решающий аналогичную задачу

Здравствуйте, ·, Вы писали:

_>>Это подходит только для простенькой задачки, в которой она единственная на системе и при этом сами вычисления не тяжёлые. Для более сложных случаев (например обработке видео в реальном времени) такие фокусы только помешают.
·>Я говорил о low latency/finance, а ты тут "обработка видео" — вообще из другой области. Обрабатывать видео с явой я и не собирался. Такие софистические фокусы только мешают.

У тебя не было никаких уточнений, что речь только про финансы. Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.

Здравствуйте, ·, Вы писали:

_>>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.
·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.
·>В java есть JNI, unsafe режим — издевательство какое-то.

Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. )))

Здравствуйте, ·, Вы писали:

_>>·>Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).
_>>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?
·>Что иммутабельный объект после вызова деструктора меняет своё состояние.

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

Здравствуйте, alex_public, Вы писали:

EP>>> vector<Widget> values(N);
_>·>И молись что N не слишком большой и не получится stack overflow на пустом месте.

_>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.

Здравствуйте, ·, Вы писали:

I>>Собтсвенно, пытаются писать много, но взлетает далеко не все. Там где не взлетела джава, как правило уже лет 10 и больше С++ в полный рост.
·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.

Назови такую область.

I>>>> Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.
I>>·>Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.
I>>Это заблуждение. У тебя практически вся архитектура приложения нацелена на минимизацию проблем с GC. Ты или забыл про это, или еще не понял.
·>Заблуждаешься.

Разве не ты говорил про off-heap приседания ?