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

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

Заменяют. Раньше логику "взять сумму со счета и раскидать по другим счетам" писали на плюсах в полный рост. Сейчас на с++ остался всего лишь драйвер к БД и кишки управляемой платформы. Т.е. С++ ушел в системно-зависимые слои.

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

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

_>У тебя не было никаких уточнений, что речь только про финансы.
Тут вроде упоминались dxFeed и LMAX, и что типа они постоянно борятся с GC. А они вроде как именно финансы.

_> Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.
Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.
И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.

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

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

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

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

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

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

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

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

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

Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? )

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

Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

S> Обычно проблема в учетных системах это уже готовые модули для ведения учета, которые состоят из миллиона кода плюс изменения расчетов при сильноизменяющемся нашем законодательстве. Поэтому 1С так просто не сдвинуть.

Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки.

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

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

Если ты про Microsoft Dynamics ERP, то причём тут .net? )

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

·>Дело вкуса, а не усилий. Простота языка Явы позволяет писать "нечитаемые тыквы" только там где надо. По сравнению с Явой, практически весь сишный код выглядит как нечитаемая тыква.

опять 25. и как же легко у вас тема сменилась на сравнение вкусов Явы и "сишного кода"

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

Хорошо, признали GС помехой, с остальным можно мириться. Ну а вызов через unsafe или JNI вас нисколько не настораживает? Ооок.

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

Я понимаю, что вас лень читать предыдущие 20 страниц темы, но мне так же лень еще раз повторять их.

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

Расскажите это игрокам каких-нибудь MMORPG, которые тратят там реальные деньги Думаю они, как и биржевые игроки, оценят ваш оптимизм.

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

EP>>>> vector<Widget> values(N);
_>>·>И молись что N не слишком большой и не получится stack overflow на пустом месте.
_>>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
·>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.

В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности.

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

Да, и это ты там с Евгением беседовал, а не со мной. ))) Я просто влез, увидев вектор с данными на стеке.)))

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

_>>Если под управляемыми ты имеешь в виду в том числе и все скриптовые, то да, есть такое дело. Просто вследствие развития ниши для этих языков. Ну и кстати говоря они в большинстве случаев не заменяют, а дополняют (работают кастомизаторами) нативный код.
I>Заменяют. Раньше логику "взять сумму со счета и раскидать по другим счетам" писали на плюсах в полный рост. Сейчас на с++ остался всего лишь драйвер к БД и кишки управляемой платформы. Т.е. С++ ушел в системно-зависимые слои.

Я лично не в курсе (никогда не занимался финансами), но сильно сомневаюсь. Насколько я знаю для этой специфической области и в те времена существовали свои решения. Типа всяких Коболов и т.п. ужастиков. )))

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

I>>·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.
I>>Назови такую область.
·>Enterprise apps, web apps, finance, IDE в конце концов.

Кроме finance, С++ уже давно ушел из этих областей, там нет. IDE и по сей день пишутся на плюсах. finance — в HFT плюсы в полный рост.

I>>·>Заблуждаешься.
I>>Разве не ты говорил про off-heap приседания ?
·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.

Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap

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

_>>У тебя не было никаких уточнений, что речь только про финансы.
·>Тут вроде упоминались dxFeed и LMAX, и что типа они постоянно борятся с GC. А они вроде как именно финансы.

Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области.

_>> Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.
·>Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.

Всё правильно описано. Только я не понял что из этого следует. Да, между этими задачами есть разница, но они обе требуют low latency.

·>И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.

Это не я мешаю, а реальные задачи возникают такие, что требуют этого всего одновременно. )))

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

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

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

_>Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? )

А зачем переписывать? Если можно сразу писать на C#? Мало того можно сравнить Питон на C++ и IronPython на C#

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

_>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.
Зато сравнивать C# и С++ это нормально. У них разная ниша. Если на C# написать код аля 1С это не далеко от оригинала. Приблизительно как TS от JC
то разница между 1С и С++ это уже разные миры.

S>> Обычно проблема в учетных системах это уже готовые модули для ведения учета, которые состоят из миллиона кода плюс изменения расчетов при сильноизменяющемся нашем законодательстве. Поэтому 1С так просто не сдвинуть.

_>Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки.
Я утвеждаю, что C# для решения подобных задач удобнее как TS vs JS. А я пишу на этих языках. Единственно, что нужно заменить англоязычные операторы на русские.

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

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

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

_>Если ты про Microsoft Dynamics ERP, то причём тут .net? )
Например https://msdn.microsoft.com/en-us/library/hh547453.aspx

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


_>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

Казалось бы. Вот посмотри http://rsdn.ru/forum/dotnet/6185588.1

Автор: Serginio1
Дата: 17.09.15

С помощью этого можно делать Сайт, Вэб сервисы на Asp.Net но никому это не нужно. 1С ник не знает .Net, а писатели Вэб приложения не знают структуру 1С.
Поэтому проще написать вэб сервис на 1С, чем использовать быстрый доступ через Net.
А ты говоришь скорость. Никому она не нужна. Ни одного комментария.

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

PM>·>Дело вкуса, а не усилий. Простота языка Явы позволяет писать "нечитаемые тыквы" только там где надо. По сравнению с Явой, практически весь сишный код выглядит как нечитаемая тыква.
PM>опять 25. и как же легко у вас тема сменилась на сравнение вкусов Явы и "сишного кода"
Это ты первый заговорил о нечитаемых тыквах. Да, признаюсь — я легко повёлся на смену темы.

будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.
PM>·>Ты пишешь будут трудности больше, чем в плюсах. Это неверно, ибо большинство упомянутых трудностей к языку не относятся. Единственное существенное отличие — это наличие GC, да, в каких-то случаях он создаёт проблемы, но в других случаях он значительно упрощает решение других проблем.
PM>Хорошо, признали GС помехой, с остальным можно мириться.
Он не помеха, а инструмент, которым можно научиться пользоваться. Но тут ведь как... Можно научиться, а можно и не научиться, вот тогда он будет только помехой.

PM> Ну а вызов через unsafe или JNI вас нисколько не настораживает? Ооок.
А почему он должен настораживать как-то? Любое внешнее действие типа записи в файл или работа с сетью — jni.

PM>>>Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/
PM>·>Не понял. И причём тут java vs C++?
PM>Я понимаю, что вас лень читать предыдущие 20 страниц темы, но мне так же лень еще раз повторять их.
Как я понял, ты убеждаешь, что вот user-space какой-то настолько магический, что из явы почему-то не доступный. Хотя я вроде приводил тебе ссылку. Так причём тут java vs C++?

PM>>>Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.
PM>·>Там совсем другие требования, всё гораздо проще, какой же это LL. С играми вообще всё пофиг — сломалось, так сломалось, да и большинство там вообще сейчас 99% LUA и прочий скриптинг. Видео|аудио — фигня, не нужны миллисекунды отклика для 99.99% и потеря пакетов не смертельна. Это всё high throughput и параллелизация.
PM>Расскажите это игрокам каких-нибудь MMORPG, которые тратят там реальные деньги Думаю они, как и биржевые игроки, оценят ваш оптимизм.
Пфф.. Реальные деньги — это какой объём? Хоть $1B в день наскребётся? Если чё, биржевой рынок порядка на три больше.
Но это всё не в тему. Т.е. ты хочешь сказать, раз Явы в MMORPG нет (кроме Minecraft), то значит она для LL не работает?

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

_>·>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.
_>В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности.
_>В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора.
Если ты в коде сделаешь ArrayList<MyClass> то объект ArrayList может так же разместиться на стеке, ибо он маленький — содержит только ссылку на MyClass[] и пару примитивов. Мало того, если размер самого Object[] так же окажется маленьким, то EA тоже может решить разместить на стеке. И в итоге вместо тройной косвенности может получиться та же одинарная.
А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.

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

I>>>·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.
I>>>Назови такую область.
I>·>Enterprise apps, web apps, finance, IDE в конце концов.
I>Кроме finance, С++ уже давно ушел из этих областей, там нет
Не "ушел" а тупо не взлетел. Взлетали всякие бейсики, перлы, питоны, пхп, и прочее.

I>IDE и по сей день пишутся на плюсах.
Eclipse? IntelliJ? Да даже Студию уже на # переписывают.

I> finance — в HFT плюсы в полный рост.
Наравне с Java.

I>>>·>Заблуждаешься.
I>>>Разве не ты говорил про off-heap приседания ?
I>·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.
I>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.

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

I>>>>>Это просто твоё мнение, ничем не аргументированое.
EP>>>>Это аргумент. Ты можешь быть согласен с ним или нет.
I>>>А противоположная формулировка, хочешь ты или нет, тоже аргумент или как ?
EP>>А смысл просто так повторять противоположную формулировку? Скажи что не согласен потому-то и тому-то, или хотя бы попроси разъяснения — зачем кирпичом прикидываться?
I>Начни с себя. Ты ведь начал голословно вещать, что всё де миф и тд и тд.

Так я сразу же пояснил почему

EP>>На C можно писать как с "контролем над временем", так и без него — это ортогональное свойство. Точно также и для C++. Поэтому контроль над временем ортогонален "как на Си".
EP>>Вот есть бы сказал что "как на блаб", при этом блаб бы использовался исключительно для задач контролем над временем — был бы другой разговор.
I>"Как на Си" это в первую очередь использования явных механизмов. Нет никаких скрытых фокусов, магии конструкторов-деструкторов-исключений и тд и тд и тд.
I>Контролировать легче именно потому, что все делается явно. Разумеется, при желании любую идею можно опаскудить.

Даже если отобрать деструкторы и исключения у C++ (и то, и то кстати в некоторой степени реализуется, и даже используется и на C) — то всё равно до "как на C" будет очень далеко.
При этом деструкторы даже не запрещены в Joint Strike Fighter C++ Coding Standards, а исключения запрещены только условно, то есть с условием выполнив которое их можно использовать.

I>>>У твоей подстраховки один побочный эффект — время выполнения может быть недетерминированым.
EP>>Эта подстраховка никак не влияет на порядок вызова деструкторов, он остаётся таким же как было бы и без неё.
I>Я про количество и глубину, а не порядок вызова.

Глубина тоже никак не меняется от введения этой подстраховки

I>>>Я же сказал, что каскадная очистка это один из возможных вариантов реализации. Тебе её удобно делать деструкторами. Отсюда ясно, что хрен его знает, какое будет время работы.
EP>>Нет, ты потерял контекст. Мы сейчас рассматриваем случай где использование ref-counting избыточно, то есть не продиктовано самой задачей, как в случае с разделяемым владением(а такие задачи сами по себе редки). В этом случае ref-counting никак не влияет на порядок вызова деструкторов.
I>Это ты хочешь понамекать, что якобы единтсвенная проблема это инкремент-декремент относительно общей массы. Я говорю совсем про другое.

В случае когда ref-counting используется исключительно для подстраховки, а не для решения проблемы разделяемого владения — да, единственная проблема это inc/dec, которых начиная с C++11 мало.

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

_>>>У тебя не было никаких уточнений, что речь только про финансы.
_>·>Тут вроде упоминались dxFeed и LMAX, и что типа они постоянно борятся с GC. А они вроде как именно финансы.
_>Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области.
Вот возьми что-нибудь из http://codedependents.com/2014/01/27/11-best-practices-for-low-latency-systems/ и подумай что именно тут java-specific? Все те же извраты будут и в плюсах.

_>>> Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.
_>·>Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.
_>Всё правильно описано. Только я не понял что из этого следует. Да, между этими задачами есть разница, но они обе требуют low latency.
И они потребуют всех тех же извращений. За что яву-то опустили?

_>·>И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.
_>Это не я мешаю, а реальные задачи возникают такие, что требуют этого всего одновременно. )))
Но почему ты решил, что выход один единствтвенный — С++? Как видно из опыта тех компаний — java тоже подходит, и даже лучше.