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

I>>Ты не заметил, что здесь противоречие ? quicksort в чистом виде числодробилка. Отсюда ясно, что сколько перформанса не дай, всё равно мало. Ассемблерными вставками вылизать трудно прежде всего потому, что это надо делать под разные процессоры, не говоря про семейства процессоров.
I>>Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.
·>Верно. И судя по тому как sort реализован в java и в c# — jvm справляется лучше (обошлись без native) чем dotnet (написано с unsafe).

Правильно понимаю, лучшесть определяется наличием или отсутствием нативного кода ?

Перформанса никогда много не бывает. Потому самые критические участки и нужно полировать в т.ч. нативным кодом, а не доказывать на каждом шагу, что манеджед лучше и его хватит за глаза.

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

I>>Ты не заметил, что здесь противоречие ? quicksort в чистом виде числодробилка.

N>Это ж какие числа она дробит? Сравнение ключей это малая и в принципе не оптимизируемая часть работы. А так — quicksort это чистейшая управляющая, а не вычислительная, задача, причём фактически RAM-bound. Это не формат работы "числодробилок".

Это самая что ни есть вычислительная задача. Только что формула тривиальная.

I>>Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.

N>Сишный компайлер как раз может не понять, что шаблон поведения включает в себя движение назад по памяти, а средства типа JVM вполне способны это увидеть и вставить prefetch на 1-2 предшествующих строки кэша.

Сильно частный случай. Локальность плюсовых структур ни одна vm не может обставить. Разница между кешем и доступом к памяти примерно два порядка. Кое где рантаймные оптимизации компенсируют отставание, но это мелочовочка.

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

I>> Ты в одном сообщении умудряешься сам себе противоречить. Если твоя софтина не вылазит за пределы нулевого поколения, ей off heap не нужен. off heap нужен не для поколений, а для того, что бы gc бегал исключительно по объектам молодого поколения. Для этого надо руками гарантировать небольшое количество выделений в молодом поколении.

N>Не нужно такого гарантировать, можно вообще ничего не выделять после прогрева и принудительного GC перед началом основной работы. А выделения в G0 сами по себе возникнут, к сожалению.

Проверяем. Прогрей GC так, что бы миллиард объектов работал гладко, без проблем с GC. Естетсвенно, не прибегая ко всями пулам и off-heap Решениям. Спасибо !

I>>То есть, off-heap нужен для того, что бы исключить gc по максимуму

N>Не так. Задача — исключить тормозную часть GC,

Когда я пишу "по максимуму" я говорю про частоту вызовов и суммарные временные издержки. Если у тебя есть какой то другой способ оптимизации GC, который не влияет ни на частоту, ни на временные издержки, дай знать.

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

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

_>>>Линуксового дотнета вообще пока нет в природе. Совсем недавно появился некий нестабильный обрезок, который возможно пойдёт для специфических целей.
S>> То есть ты знаток .Net ?

_>Ты с каким конкретно тезисом в моей фразе не согласен? С тем что оно недавно появилось? Или с тем, что это обрезок от полноценного .net'a? Поясни, а то из твоего потока ссылкок и т.п. совершенно не понятна твоя мысль.
Откуда ты взял про нестабильный? Во вторых я тебе дал ссылку, где в скором времени он уже не будет обрезком и сейчас достаточно, для того, что бы писать кроссплатформенные приложения. В отличие не от обрезка, который прибит к Windows. Он то как раз и неполноценный.
Кроме того, .Net Core это новый виток развития .Net, который то как раз и будет развиваться. От то как раз оптимизирован для .Net Native итд.
При компиляции может работать без полноценного фреймворка

https://habrahabr.ru/post/311520/

В директории publish находятся только необходимые библиотеки для данной ОС.
Почитай ссылки для развития. Тот же xamarin тоже идет к .Net Core.
Есть и UI https://blogs.msdn.microsoft.com/dotnet/2016/09/14/the-week-in-net-net-core-1-0-1-on-net-with-peachpie-avalonia-folk-tale/
развивается Unity

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

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

N>Эти слова открыто противоречат идее JIT.

Никакого противоречия. JIT это всего лишь компенсация. Ни один распрекрасных джыт не может в общем случае обогнать хороший плюсовый компилер. Нет у него столько времени.

I>>Более того, с т.з. быстродействия, строки и массивы как раз и определяют всё, вообще всё — 80-90% операций происходит с этими двумя типами.
I>>Особенно критично для маршалинга, интеропа, больших размеров данных и тд.
N>Но в теме HFT, которую обсуждает твой оппонент, это всё как раз мало значимо, и в сортировке — тоже.

Ему не нравится сам факт наличия нативного кода в дотнете.

I>>Это было известно примерно в 2001м году, когда были опубликованы исходники Rotor. Ты как то запоздало срываешь покровы
N>Если речь про мелкомягкую VM с лицензией, которая делает её бесполезной, то я таки не понимаю, при чём она. Можешь подробнее?

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

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

_>Безусловно. ) Но ты же понимаешь, что в реальности в большинстве случаев не будет ни того, ни другого. Будет просто обычный класс (реализующий при этом ещё и кучу каких-нибудь интерфейсов), а в случае возникновения тормозов появится запрос на новое железо (а не на оптимизацию кода). Это же мир Java/C#, а не C++. Так вот этом мире решения на Java могут начать тормозить чуть позже аналогов на C#, как раз за счёт интересных приём в их ВМ.

Я и вижу — Java UI как морозил 15 лет назад, так по сей день морозит. Ни переписывания, ни оптимизации не помогают.

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

N>>Не нужно такого гарантировать, можно вообще ничего не выделять после прогрева и принудительного GC перед началом основной работы. А выделения в G0 сами по себе возникнут, к сожалению.
I>Проверяем. Прогрей GC так, что бы миллиард объектов работал гладко, без проблем с GC. Естетсвенно, не прибегая ко всями пулам и off-heap Решениям.

Про не прибегая к offheap это подтасовка. Я как раз говорил, что offheap — один из методов решения.

I> Спасибо !

Обломись, бабка.

I>>>То есть, off-heap нужен для того, что бы исключить gc по максимуму

N>>Не так. Задача — исключить тормозную часть GC,

I>Когда я пишу "по максимуму" я говорю про частоту вызовов и суммарные временные издержки.

Именно что _суммарные_ совершенно не в контексте данного обсуждения, ты приплёл их только сейчас.
Для задач типа HFT важна равномерность задержек, даже если в сумме их будет больше. А это легко обеспечить инкрементальным GC, что и делают соответствующие VM.
А вот для более традиционных применений тормоза на 200мс почти незаметны, а вот суммарное время работы и затраченная память более существенны.

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

I>>> Как бы ты ни старался, менеджед код не может и никогда не будет работать так же быстро, как и нативный. У него особенность — он менеджед аккурат за счет того, что перформанс на втором месте.
N>>Эти слова открыто противоречат идее JIT.
I>Никакого противоречия. JIT это всего лишь компенсация. Ни один распрекрасных джыт не может в общем случае обогнать хороший плюсовый компилер. Нет у него столько времени.

Зато у него есть данные о реальном поведении приложения, и они часто оказываются важнее.
Причём даже по сравнением с PGO, если PGO не может выбрать между несколькими типичными профилями, или тестовая нагрузка не соответствует реальной.

I>>>Более того, с т.з. быстродействия, строки и массивы как раз и определяют всё, вообще всё — 80-90% операций происходит с этими двумя типами.
I>>>Особенно критично для маршалинга, интеропа, больших размеров данных и тд.
N>>Но в теме HFT, которую обсуждает твой оппонент, это всё как раз мало значимо, и в сортировке — тоже.
I>Ему не нравится сам факт наличия нативного кода в дотнете.

Ему не нравится, что сравнивают реализации с нативным кодом против чисто VMовских.

I>>>Это было известно примерно в 2001м году, когда были опубликованы исходники Rotor. Ты как то запоздало срываешь покровы
N>>Если речь про мелкомягкую VM с лицензией, которая делает её бесполезной, то я таки не понимаю, при чём она. Можешь подробнее?
I> Ранний дотнет и ротор вообще мало чем отличаются. Все родовые травмы, архитектура, навроде обсуждаемых, и там и там идентичные. Фактически, это два разных бранча с одной версии.
I>Более того — значительная часть вещей и по сей день работает без принципиальных изменений.

Спасибо за рассказ, я про Rotor впервые тут услышал. Но если речь идёт всего лишь об открытой версии дотнета — преимущества этих подходов видны на основных целевых задачах дотнета, но не HFT или чём-то другом столь же специализированном.

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

I>>>Ты не заметил, что здесь противоречие ? quicksort в чистом виде числодробилка.

N>>Это ж какие числа она дробит? Сравнение ключей это малая и в принципе не оптимизируемая часть работы. А так — quicksort это чистейшая управляющая, а не вычислительная, задача, причём фактически RAM-bound. Это не формат работы "числодробилок".

I>Это самая что ни есть вычислительная задача. Только что формула тривиальная.

Я эту демагогию не куплю.

I>>>Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.
N>>Сишный компайлер как раз может не понять, что шаблон поведения включает в себя движение назад по памяти, а средства типа JVM вполне способны это увидеть и вставить prefetch на 1-2 предшествующих строки кэша.
I>Сильно частный случай. Локальность плюсовых структур ни одна vm не может обставить.

Это если их так явно писать. Но тогда и на VM можно сделать очень похожее (и мы таки делаем).

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

V>>>·>Блин, я, видимо, неоднозначно выразился. Под утечкой я не утечку памяти имел в виду, а логическую утечку данных или ссылок на них из контекста.
V>>>Я прекрасно понял и поэтому сослался на статическую типизацию того же std::vector<>.
V>>>В общем, поскольку ты не захотел на него посмотреть, скопирую его объявление сюда сугубо для истории аргументов:
V>·>Я знаю об аллокаторах. Говорил бы прямо, а всё то какими-то загадками и увёртками, подловить пытаешься.
V>Подловить?
V>Достаточно было вбить в гугл "std::vector" и по первой же ссылке обнаружить:
Извини. У меня последнее ужасно с телепатией, чакры засорились, похоже. У меня не получилось прочесть твою телепатеграмму о том что ты хотел чтобы я увидел.

V>>>Т.е., определив через typedef некий "региональные вектор":
V>·>А что мне помешает, передать, например, ссылку/указатель на элемент вектора куда-нибудь?
V>Ну тебе же ничто не помешало скипнуть заранее данный ответ на этот вопрос:
V>

V>Такая техника работает для любых пользовательских типов в т.ч.

Что мне запрещает создать экземпляр пользовательского типа с другим аллокатором, содержащий ссылку на элемент массива?

V>>>Увы, увы, никакой "true agile" в таких областях IT не живет, там обитает только водопад и отсутствие внезапности.
V>·>В LMAX живёт. Релизы каждые две недели, все всё коммитят сразу в master. Кстати, java как раз очень способствует agile.
V>Вот поэтому такие тормоза.
Какие тормоза? Факты в студию.

V>>>Там когда что-то меняется — то это совсем из-за сдвигов тектонического масштаба. Например, в Windows 8 и Server 2012 появилось новое АПИ Registered IO. Но это в любом случае голову включать надо и смотреть/экспериментировать — будут ли полезные плюшки для конкретного кейза или нет.
V>·>Причём тут API. Может поменяться бизнес-логика.
V>В сетевом слое? Или в стандартах FIX?
Где угодно. Мы обсуждаем gc, а он может использоваться не только в приложениях с FIX, и даже не только связанных с финансами.

V>·>Кстати, я не даром поменял сабж. Я говорю о разных приложениях, не только HFT.
V>Как удобно-то! Но коллег изволишь ругать, когда они тебе разные примеры приводят.
Цитату.

V>>>·>Согласен. Но я, надеюсь, что ты не будешь спорить с тем, что управление памятью значительно влияет на структуру приложения?
V>>>Если речь об эффективности? Ес-но.
V>·>Эффективности чего? Проиводительности — нет, пусть это не будет первоочередным приоритетом.
V>Пусть мы вообще "в стол" программы писать будем. Вот так будет легко и просто обсуждать. А главное, можно будет делать какие угодно предположения и выводы, верно?
Прошу прощения, я явно не указал что меняю сабж. Я думал что это хорошо видно.

V>·>Может быть. Именно потому что думает только мозжечок, мало кто пишет, скажем, веб-приложение на Плюсах.
V>На плюсах вообще мало кто пишет и как следствие, все в один голос утверждают, что средний уровень программиста резко упал за последние лет 15.
V>Но веб-приложений на плюсах дохрена, ес-но. И что самое прикольное — год от года их всё больше.
Больше в абсолютном значении — верю (хм, но это банально). Больше в относительном — не верю. Доказательства есть?

V>Были грандиозные забеги, так вот, веб-приложухи на плюсовых фреймворках рвут как тузик грелку вообще любые управляемые или скриптовые многократно.
V>Кому надо — пользуется. Кому не надо — нет. Какие проблемы-то?
Логично, нативный по определению должен рвать managed. Проблемы в усилиях, которые требуются при разработке и поддержке нативных решений.

V>>>В C# есть using(IDisposable), а в плюсах так и вовсе RAII — наше фсё. ))
V>·>Ну в java есть try(AutoCloseable), не велика разница.
V>Угу, появилось когда? В 2011-м? Когда уже спасибо не надо? ))
Надо, не надо — дело вкуса, это же просто синт-сахар, можно и тупо try-finally, просто кода на полторы строчки больше.

V>·>Это тривиальный случай, если ресурс хорошо укладывается в синтаксический скоуп. Но когда создание отделено от освобождения (т.е. не on-stack переменная в терминах C++), то начинается шаманство.
V>Зато в С++ не начинается при разделяемом владении ввиду гарантированной своевременной финализации.
Проблема не в финализации как таковой, а в определении момента когда собственно таки можно финализировать.

V>>>·>Вот... А java — пофиг, пиши как пишется и не надо заботиться об этих алгоритмах, ибо он один единственный — gc.
V>>>Но именно в Джава пулы объектов сверх-популярны. Как так?
V>·>Кто тебе это сказал, что популярны?
V>Более опытные товарищи в Джаве.
V>Которые реально смотрят на мир, без вот этих розовых очков.
Опять бла-бла. А доказать?

V>>>·>А в яве — никогда
V>>>О чем и речь. Потому что низзя.
V>·>Можно, но нафиг нужно?
V>Низзя, хотя очень нужно.
Низзя что? Можно без намёков и увёрток?
У них была другая задача, как бы им помогли пулы? Им нужно было специфичное in-memory хранилище, ну они его и сделали без каких-либо сложностей.

V>>>Конечно быстрее, тем более, что дефолный хип в С++ — он многопоточный и вызывает конфликты при аллокации/деаллокации. Но как раз спасает то, что в типичном С++-приложении во многие разы меньше операций выделений памяти (я же уже расписывал — почему).
V>·>Практически любой контейнер — выделение памяти в куче.
V>Характер выделений там однократный.
С однократным выделением и в java проблем нет.

V>Иначе берут какой-нить аллокатор на основе пула.
Закат солнца вручную, особенно если нет критических требований к перформансу.

V>·>А если попытаться замутить что-то с иммутабельными объектами...
V>То доступ к глобальным объектам в С++ — это прямая адресация, в отличие от косвенной в джаве.
Что такое глобальный объект? И причём тут иммутабелные объекты?

V>>>Большинство операций по выделению памяти в С++ можно отнести к разряду "однократных". Вот, подключились к бирже, у нас образовался объект "Сессия", отключились — исчез. По сравнению с десятками тыщ перемалываемых этой сессией событий в секунду (одиночный фид даёт до 40 тыс событий в секунду на некоторых биржах, а фидов может быть много), частоту событий создания/удаления объектов верхнего уровня (Сессий) можно принять нулевой.
V>·>На Java пишут точно так же. Не понимаю что тут особого.
V>На джава постоянно создают объекты в куче.
Так скажи им, чтобы они их не создавали постоянно. Если спросят можно ли, можешь сказать, что я разрешил.

V>>>В общем, в специфике С++ для 99% сценариев самописные аллокаторы нафик не нужны (для объекта-Сессии), но иногда возможность их использовать очень даже в кассу (для объектов-сообщений).
V>·>Ээээ. Зачем? Чем что-то типа преаллоцированного во время создания сессии List<Message> плохо?
V>А если мне надо кучей ордеров оперировать одновременно?
Делай так же (не по конструкциям языка, понятное дело, а логически), как бы ты делал в Плюсах.
А ещё учти, сами FIX сообщения не самое лучшее представление для оперирования. Клади в контейнер удобно подготовленные текущие объекты, которыми надо оперировать в данный момент.

V>Ну и за раз из сокета можем принять несколько сотен сообщений из 10-гигабитной картейки.
new ArrayList<Message>(1000), не?

V>>>Весь твой TLAB — это один из объектов, хранимых в TLS, не более того.
V>>>Вернее, в TLS хранится указатель на TLAB.
V>·>Который именно TLS?
V>А другого механизма не существует.
Который именно TLS?? Их несколько разных в разных местах системы. Ты, надеюсь, не java.lang.ThreadLocal имеешь в виду? А какой тогда?

V>·>Доказать можешь свою фантазию?
V>Мне показалось или ты опять сделал некое утверждение, ась?
Нет, попросил доказательство для твоих утверждений.

V>Кароч, сформулируй СВОЁ утверждение относительно TLAB таким образом, чтобы мне было удобно на него потом ссылаться, т.е. тыкать тебя в него, когда тебе опять захочется похамить.
Моё утверждение: TLAB лежит к структуре треда и не требует никакого дорогого доставания из TLS.

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

V>>>Да ладно, если тебе письмо вовремя не дошло, то это редко бывает проблемой. А если ордера вовремя не снял, то потерять десятки-сотни тыщ за один день можно запросто.
V>·>Но не из-за JPG иконки, инфа 146%.
V>Теперь ты видишь, как мне сложно? ))
V>Десяток постов пришлось потратить на то, чтобы ты и сам понял, что не в нейтивном коде обычно засада.
Потому что хорошо задизайненая торговая система от иконок не зависит.

V>>>·>Ты среднюю температуру по больнице посчитай. И как скоро и как часто выходят патчи после первой версии какой-либо игры.
V>>>Ну вот как раз в данных и патчат более всего.
V>·>Хотя да, согласен. В игромире тоже десяток игровых движков, а игра это по сути скрипты, да текстуры, а нативного кода пишут всё меньше, везде дураки — нет бы написали на Плюсах и порвали бы всех, ведь там библиотеки под все случаи жизни.
V>Ну да. Типичная современная игра на каком-нить движке — это миллионы строк исходника движка и десяток тыщ строк сриптов.
V>Именно такие игры и рвут всех, не знаю, чего ты так разбушевался-то...
И эти движки отлаживаются и пилятся годами. Как собственно и vm.

V>>>Возможно. Но на практике проход по памяти в С++ случается на порядки реже, чем ошибки типизации в сильно динамическом джавовском коде.
V>·>Мнение. С док-вами этого фактоида возникнут трудности, не так ли?
V>Так и ты себя не утруждаешь от слова совсем.
Я и не собираюсь утруждать себя доказательством твоих слов.

V>А у меня есть весьма активно наполняемая система баг-трекинга конторы с кучей программеров. Там за несколько лет ни одной ошибки выхода за границы массива, зато куча типичных логических ошибок. И на динамическом коде их намного больше, ес-но.
И с памятью никаких проблем не было? Утечек не было? К неинициализированнй/освобождённой памяти не обращались? И segfault-ы не падали?

В каком ещё "динамическом" коде? javascript что-ли? Причём тут вообще динамический код?
Тебя куда-то заносит постоянно. Вначале в dotnet vs java запихал native, а теперь ещё и динамику.

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

V>А это вообще минимальная граница, с которой только можно начинать хоть как-то полагаться на тестирование. На типичные джавовские юнит-тесты без слёз не взглянешь.
Давай я напишу слёзогонные тесты на Плюсах, это улучшит Джаву в твоих глазах?
Кстати, скажи тем, кто пишет слезогонные тесты, чтобы они их писали получше, если чё — скажешь, что я разрешил.

V>>>Ну т.е. доступ к элементам вектора по индексу — это что-то из ряда вон выходящее и причина обратить внимание на происходящее.
V>·>Так на практике элементарные случаи типа "for(Elem elem : elemList)" на раз оптимайзятся RangeCheckElimination.
V>Я привел аргументы, почему явным образом итераторы используются редко.
Так используются же, а ошибки падают редко... но метко.

V>·>А в нетривиальных случаях, когда RangeCheckElimination ниасиливает — человеку тоже асилить непросто. Хотя да, ведь зачем напрягать компьютер, девушки С++-сники хорошо справляются.
V>Открой для себя т.н. "алгоритмы" буста и STL. Прекрасно компьютер справляется. Просто JIT-у некогда справляться, в отличие от полноценного оптимизатора С++.
Доказательства есть?

V>>>>>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().
V>>>·>В каких? Кто сравнивает? std::vector — не сравнивает.
V>Алгоритмы сравнивают:
Не понимаю чем это будет принципиально отличаться от java.

V>Пример использования голый массивов не трогая явным образом элементы по индексу:
V>http://www.boost.org/doc/libs/1_62_0/libs/geometry/doc/html/geometry/quickstart.html


V>>>Любой алгоритм сравнивает два итератора.
V>·>Ну т.е. явно делает range check (который, кстати, может и остаться в runtime, в отличие от RangeCheckElimination).
V>OMG ))
V>Ты эта... В общем, хоть бы предварительно почитал бы, о чем пишешь.
V>Твой RangeCheckElimination убирает ДОПОЛНИТЕЛЬНУЮ (т.е. избыточную) сугубо джавовскую проверку. Но основная никуда не девается, ес-но.
V>В приведенных мною примерах (там по ссылке их множество) избыточной проверки и не было никогда.


V>>>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.
V>>>Дык, уровень косвенности на единицу меньше.
V>·>Расшифруй.
V>Ы?
Я не понял твоё высказывание. косвенность чего? Почему на единицу, а не на 0.99 или 42?

V>>>·>Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы.
V>>>90% кода типичной HFT-системы не требует вообще ничего из того, что дают управляемые среды.
V>·>Неправда. Скажем, в HFT-системе может быть несколько web-интерфейсов, работа с субд, гейты с разными WebService/Rest. А ещё, скажем, может быть инфраструктура мониторинга, тестирования, деплоймента и т.п. Ты правда считаешь, что native для этого лучше, чем managed??
V>Конечно.
V>В реалтайме идёт заливка в файл в транзакционную файловую систему,
FileOutputStream.write?

V>а не в БД. Там никакая БД не справится, ес-но.
Смотря где. Вести бд счетов, движение средств, и контактные и прочие данные клиентов. Архивы трейдов. Описание инструментов. Еженедельные отчёты. Конфигурация клиентских соединений. Аудит действий в админке.
Ты уверен, что это всё требует реалтаймную заливку в транзакционную фс?

V>Ес-но это всё происходит через нейтив. Периодически в БД сливают только снапшоты. Это другой процесс/узел, ему надо проводить бешеную агрегацию исходных данных, там ничего кроме нейтива не выживает. Инфраструктура мониторинга так и работает, как отдельный узел, куда в бешеном режиме сливаются вообще все данные и на этом узле обычно и происходит та самая суровая агрегация и потом неторопливая выдача данных по запросам в XML или другом текстовом формате. В том числе клиентам на Джаве, ес-но.
А почему таки на Джаве? Писали бы уж всё на плюсах, ведь там Алгоритмы есть.

V>Инфраструктура тестирования/сертифицирования, все эти эмуляторы — это нейтивное АПИ с выходом на скрипт, там нечего делать никакой джаве, потому что требуется работать БЕЗ развернутых ср-в разработки, т.е. подправил скрипт — тут же запустил.
А какие средства разработки надо разворачивать для Явы? Ну там git скачать, чтобы исходники из репо забрать и.... ну можно ещё Идею поставить, чтобы подправлять "скрипты" пришлось не в тупом notepad, а с автодоплнениями и подсказками. Собственно всё.

V>Деплойментом тоже обычно занимаются скриптовые утилиты (сейчас их много, в т.ч. писаных на руби), джавовские тут самые неуниверсальные, хорошо работают только для экосистемы джавы, а не гетерогенность сценария.
Т.е. создать гетерогенную среду, месиво из кучи технологий, и потом начать радоваться тому, что оно всё какое-то неуниверсальное.

V>Кароч, добро пожаловать в реальный мир, Нео. ))
Мир настоящих комсомольцев!

V>>>А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но.
V>·>Верно. Но обратное-то не верно. Бывают и не сложные системы, которые тоже могут быть требовать.
V>Ну вот ты снова спутал необходимое с достаточным и проиграл. ))
Это ты спутал. Не обязательно иметь "действительно" сложную систему, чтобы в ней потребовалась java с целью минимизировации затрат на разработку и поддержку.

V>>>Давнее заблуждение, родом из 95-го года, когда объем библиотек в поставке джавы натурально поражал воображение. ))
V>>>Сейчас библиотек под С++ уже просто тонны под все случаи жизни.
V>·>Ах, ну да-да, ведь все те джавовские библиотеки — испарились. И с 95-го запретили писать новые злобные С++-ники.
V>Увы, в плане доступа к БД ничего круче Hibernate джава-сообщество до сих пор не родило, остальное — это более простые ORM-мапперы. Кароч, тут в джаве творится сплошное позорище какое-то. В плюсах давно есть намного более мощные, чем Hibernate системы. Ну т.е. действительно на порядки более мощные и удобные. А уж более простых мапперов/хелперов — как собак нерезанных.
Не в курсе. А что там нового? Универсальный коннектор сделали наконец-то по типу jdbc?

V>А если взять дотнетный linq, то про джаву вообще вспоминать стыдно.
Да много всякого уже напридумывали, честно говоря не слежу за этим. Ещё и другие jvm языки есть, в scala вроде аналог линка.

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

I>>>И это оно же. Если речь про перформанс, то такие методы вообще говоря и должны быть платформенно-зависимым, это в чистом виде числодробилка.
N>·>Не должны (но могут, если язык недостаточно быстр). Как quicksort зависит от платформы? quicksort не числодробилка. Почему реализация std::sort в C++ не зависит от платформы? Могли бы уж вылизать ассемблерными вставками...
N>В случае, когда даже подставление компаратора выливается неизвестно во что?
Конечно, компаратор тоже ассеблерными вставками, ведь это, известное дело, тоже числодробилка.

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

S>>> Которые взрыватюся
S>·>А ты не пори чушь, что "На яблоках кстати Java нет, а .Net есть.", и увиливать не придётся.
S> Ну заметь яблоки меньше взрываются.
Причём тут взрывы? В смысле яблоки меньше взрываются потому что там есть и Java и .net? Что сказать-то хотел?

S> На самом деле смысл в .Net Native не только в скорости и меньше расхода батареи,
У тебя есть сравнение? Или опять голословные утверждения?
ART (Android Runtime) уже давно занимается компиляцией java в натив, install time — под конкретный девайс.

S> но и главное это обфускация.
Кому нужна это обфускация? Студентам, которые боятся, что кто-то украдёт их нетленку?

S>И распространение приложений только через магазин. С привязкой к телефону.
Для этого натив не нужен.

S>·>Я не интересовался.
S> Главное, что бы было.
Другой вопрос. Я вообще с embedded дела не имел, я не могу тебе ничего интересного рассказть, но утверждать, что это никому не нужно — не стану.

S>>> В .Net може есть https://ru.wikipedia.org/wiki/.NET_Micro_Framework
S>·>Это аналог https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition , Java Card ещё микрее.
S> Только непонятно зачем.
В смысе .NET MF — понятно зачем, а JME — непонятно?

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

I>·>Если откалибровать во время разработки.
I>·>Почему аллокаторы калибровать можно, а параметры gc вдруг нельзя?
I>Дай мне забесплатно 1000$ ? Ну как предложение ? Калибровать — можно. И это очень дорого, только издержки переносятся в разработку.
I>Когда говорят "бесплатно" это значит всё само работает, искаропки и пилить ничего не надо. А у тебя постоянный майнтенанс, соответсвенно, часть фич приходится откладывать на потом, ибо этот тюнинг требует времени и его просто так не выбросишь.
В большинстве случаев оно работает нормально и так. Т.е. бремя оптимизации распределяется в течение разработки. Тебе не нужно сразу закладывать в архитектуру приложения "тут нам, наверное, понадобятся хитрые аллокаторы". А решать можно в процессе обнаружения проблем, притом начать с того, что просто покрутить ключики gc, это всё же проще, чем перекраивать архитектуру.

I>>>Разница в частоте срабатываний примерно 2-3 порядка. Это и есть "исключить". Необходимость не только offheap падает, но и растёт Объемы данных растут быстрее, чем улучшаются алгоритмы и соответсвенно качество работы GC.
I>>>Сейчас вобщем не редкость, когда приходится хранить миллиарды объектов в памяти. Самый распрекрасный GC сосёт не нагибаясь.
I>·>Отношение количества таких специфичных задач к общему числу задач падает, могу смело предположить.
I>У меня другие ощущения.
Ты просто в среде такой крутишься, скорее всего.

I>В дотнете относительно недавно начали появляться либы для работы с конским количеством объектов, миллиард и больше. Более того, даже в пейтоне, и JS тоже пошли такие фокусы, только масштаб меньше.
Интересно, что за либы? Что они делают?
Одну проблему вижу в том, что Collection.Count типа int32, что лишь немногим больше миллиарда. Не уверен насчёт JS, но пайтон это таки обычно клей поверх С-имплементации.

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

I>>>Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.
I>·>Верно. И судя по тому как sort реализован в java и в c# — jvm справляется лучше (обошлись без native) чем dotnet (написано с unsafe).
I>Правильно понимаю, лучшесть определяется наличием или отсутствием нативного кода ?
Да, это значит что на java можно написать больше эффективных алгоритмов, чем на c#.

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

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

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

S>>>> Которые взрыватюся
S>>·>А ты не пори чушь, что "На яблоках кстати Java нет, а .Net есть.", и увиливать не придётся.
S>> Ну заметь яблоки меньше взрываются.
·>Причём тут взрывы? В смысле яблоки меньше взрываются потому что там есть и Java и .net? Что сказать-то хотел?
То что в iPhone используется только натив. А значит меньше потребление электричества.

S>> На самом деле смысл в .Net Native не только в скорости и меньше расхода батареи,
·>У тебя есть сравнение? Или опять голословные утверждения?
Ну быстрее загружается, быстрее работает. Есть цифры на сайте MS.
Вот здесь тоже https://habrahabr.ru/post/201346/
http://lifehacker.com/android-art-vs-dalvik-runtimes-effect-on-battery-life-1507264545
·>ART (Android Runtime) уже давно занимается компиляцией java в натив, install time — под конкретный девайс.
Спасибо. Интересно. Но там вроде компиляция на самом девайсе, в отличеие от Microsoft.
А это значит, что качество компиляци оствляет желать лучшего. В .Net Core используется С++ компилятор.
Скорее всего ART это аналог NGEN. Тот же JIT компилятор.
И тот же сборщик мусора. То есть ART все равно выполняется в среде VM?
Или у них отдельный сборщик мусора как в .Net Native?



S>> но и главное это обфускация.
·>Кому нужна это обфускация? Студентам, которые боятся, что кто-то украдёт их нетленку?
Нужна. Здесь на форуме много копий по этому поводу сломано.

S>>И распространение приложений только через магазин. С привязкой к телефону.
·>Для этого натив не нужен.
Ну взломать и поставить то проблем больше с нативом.

S>>·>Я не интересовался.
S>> Главное, что бы было.
·>Другой вопрос. Я вообще с embedded дела не имел, я не могу тебе ничего интересного рассказть, но утверждать, что это никому не нужно — не стану.

S>>>> В .Net може есть https://ru.wikipedia.org/wiki/.NET_Micro_Framework
S>>·>Это аналог https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition , Java Card ещё микрее.
S>> Только непонятно зачем.
·>В смысе .NET MF — понятно зачем, а JME — непонятно?
Зачем Java Card

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

S>·>Причём тут взрывы? В смысле яблоки меньше взрываются потому что там есть и Java и .net? Что сказать-то хотел?
S> То что в Java используется только натив.
Ты хотел сказать "в .net" или "в яблоках"?

S> А значит меньше потребление электричества.
В общем случае — не значит. JIT может иногда давать лучший код, т.к. ему доступно реальная информация времени исполнения. AOT — этого может и не знать. Скажем, типичный пример — virtual call elimination — если используется единственная имплементация виртуальной функции во время работы приложения, то JIT может выкинуть косвенный вызов. AOT — такой информацией просто не обладает.

S>>> На самом деле смысл в .Net Native не только в скорости и меньше расхода батареи,
S>·>У тебя есть сравнение? Или опять голословные утверждения?
S> Ну быстрее загружается, быстрее работает. Есть цифры на сайте MS.
Покажи.

S>·>ART (Android Runtime) уже давно занимается компиляцией java в натив, install time — под конкретный девайс.
S> Спасибо. Интересно. Но там вроде компиляция на самом девайсе, в отличеие от MicroSoft
При желании компиляцию можно и до закачки делать — но непонятно зачем, тебе придётся компилировать под все возможные платформы, а их чуть больше чем дофига и постоянно клепают новые.

S>>> но и главное это обфускация.
S>·>Кому нужна это обфускация? Студентам, которые боятся, что кто-то украдёт их нетленку?
S> Нужна. Здесь на форуме много копий по этому поводу сломано.
Обсускаторы для java тоже есть.

S>>>И распространение приложений только через магазин. С привязкой к телефону.
S>·>Для этого натив не нужен.
S> Ну взломать и поставить то проблем больше с нативом.
Ну это заблуждение, подогреваемое продавцами обфускаторов. Я уверен, что .net native будет делать какие-то серьёзные усилия в сторону усложнеия декомпиляции.

S>>>·>Это аналог https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition , Java Card ещё микрее.
S>>> Только непонятно зачем.
S>·>В смысе .NET MF — понятно зачем, а JME — непонятно?
S> Зачем Java Card
Да хз, говорю же, я слышал о нём, но подробностей не смотрел.
We do what we must
Because we can.
For the good of all of us.

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

>>Быстродействие для таких задач не принципиально в 99% случаев, а для оставшегося одного процента (всякие там гуглы, яндексы, социальные сети и т.п. высоконагруженный веб) выбирают как раз между Java или вообще C++.
I>'для оставшегося одного процента' выбирают в основном открытые технологии, даже в ущерб производительности. Производительность можно компенсировать разными способами, а ущерб от закрытой технологии может привести к смерти самого бизнеса.

Ну насчёт "в ущерб" я бы не был столько уверен. А вот то, что при прочих равных предпочтут открытое, несомненно. Я собственно и сам так предпочитаю. )

I>Кроме того, этот 'оставшийся процент' гораздо больше 1%. В банковской отрасли полно дотнета, от этого никуда не деться.

Один процент — это было про часть веба (в котором скриптам уже тяжеловато). А так то у Java/C# естественно есть и другие области (энтерпрайзные формочки — это их родная стихия), в которых и быстродействия особого не надо и скрипты не особо наступают.

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

_>>Ты с каким конкретно тезисом в моей фразе не согласен? С тем что оно недавно появилось? Или с тем, что это обрезок от полноценного .net'a? Поясни, а то из твоего потока ссылкок и т.п. совершенно не понятна твоя мысль.
S> Откуда ты взял про нестабильный? Во вторых я тебе дал ссылку, где в скором времени он уже не будет обрезком и сейчас достаточно, для того, что бы писать кроссплатформенные приложения. В отличие не от обрезка, который прибит к Windows. Он то как раз и неполноценный.

Что значит не будет обрезком? На Линухе заработает WPF? В какой из тех ссылок про это сказано?

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

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

S>>·>Причём тут взрывы? В смысле яблоки меньше взрываются потому что там есть и Java и .net? Что сказать-то хотел?
S>> То что в Java используется только натив.
·>Ты хотел сказать "в .net" или "в яблоках"?
Экий ты быстрый. Я уже подправил. Конечно в яблоках.
S>> А значит меньше потребление электричества.
·>В общем случае — не значит. JIT может иногда давать лучший код, т.к. ему доступно реальная информация времени исполнения. AOT — этого может и не знать. Скажем, типичный пример — virtual call elimination — если используется единственная имплементация виртуальной функции во время работы приложения, то JIT может выкинуть косвенный вызов. AOT — такой информацией просто не обладает.
Угу на мобильных то устройствах? Там большинство до сих пор сидит на Java 6.
А вот что касается инлайнинга и прочих оптимизаций то тут никакой оптимизатор лучше не сделает.

S>>>> На самом деле смысл в .Net Native не только в скорости и меньше расхода батареи,
S>>·>У тебя есть сравнение? Или опять голословные утверждения?
S>> Ну быстрее загружается, быстрее работает. Есть цифры на сайте MS.
·>Покажи.
https://msdn.microsoft.com/ru-ru/library/dn643729(v=vs.110).aspx
https://social.msdn.microsoft.com/Forums/en-US/f650e4d4-578f-4ef9-84d1-0d3eac9147c9/uwp-net-native-vs-net-jit-benchmark?forum=wpdevelop

По сборке мусора здесь
https://msdn.microsoft.com/pl-pl/windows/uwp/debug-test-perf/improve-garbage-collection-performance
S>>·>ART (Android Runtime) уже давно занимается компиляцией java в натив, install time — под конкретный девайс.
S>> Спасибо. Интересно. Но там вроде компиляция на самом девайсе, в отличеие от MicroSoft
·>При желании компиляцию можно и до закачки делать — но непонятно зачем, тебе придётся компилировать под все возможные платформы, а их чуть больше чем дофига и постоянно клепают новые.

Так компилируется на стороне магазина. С мобильного указываются параметры и под него уже компилится или бертся из уже скомпиленных. Количество марок аппаратов ограничено.

S>>>> но и главное это обфускация.
S>>·>Кому нужна это обфускация? Студентам, которые боятся, что кто-то украдёт их нетленку?
S>> Нужна. Здесь на форуме много копий по этому поводу сломано.
·>Обсускаторы для java тоже есть.
Есть но машинный код лучше.

S>>>>И распространение приложений только через магазин. С привязкой к телефону.
S>>·>Для этого натив не нужен.
S>> Ну взломать и поставить то проблем больше с нативом.
·>Ну это заблуждение, подогреваемое продавцами обфускаторов. Я уверен, что .net native будет делать какие-то серьёзные усилия в сторону усложнеия декомпиляции.

Посмотрим. Так или иначе .Net Native под UWP которая пока не сильно то используется