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

I>Сильно частный случай. Локальность плюсовых структур ни одна vm не может обставить. Разница между кешем и доступом к памяти примерно два порядка. Кое где рантаймные оптимизации компенсируют отставание, но это мелочовочка.
Тут надо осторожно выражаться, не так категорично. Скажем, std::vector<std::string> внезапно совсем не локальный, а char[] локальный везде. Потом — компактификация кучи и ArrayList<String> может стать локальнее, чем std::vector<std::string>.

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

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

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

Я тебя попросил показать _другой_ способ для этой же задачи. Например — твой прогрев.


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

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

Суммарно это совсем не обязательно за всё время работы приложения

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

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

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

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

N>>>Но в теме HFT, которую обсуждает твой оппонент, это всё как раз мало значимо, и в сортировке — тоже.
I>>Ему не нравится сам факт наличия нативного кода в дотнете.

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

А по моему он не понимает аргумент про закрытые и открытые технологии.

I>>Более того — значительная часть вещей и по сей день работает без принципиальных изменений.

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

Еще раз — дотнет до недавних пор был прибит гвоздями к винде. Следовательно, без винды ты никак его использовать не можешь. Следовательно, в HFT будут видны проблемы не только дотнета, но и винды.
С учетом того, что винда сама имеет проблемы с LL, удивляться нечему. Задержка в 1мс на винде может спокойно дать и 15 секунд ожидания и это никак не исправить ни дотнетом, ни эрлангом, ни чем угодно. Это особенность ядра винды, планировщика и её работы с железом.
Потому в своём уме винду крайне редко пускают в реалтайм-приложения. Соответственно дотнет пилить, оптимизировать под HFT смысла большого нет. Чего и наблюдаем.

Разумеется, микрософт подпиливает винду то там, то сям, но принципиально картина не меняется.

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

N>>Но в теме HFT, которую обсуждает твой оппонент, это всё как раз мало значимо, и в сортировке — тоже.
I>Ему не нравится сам факт наличия нативного кода в дотнете.
Не сам факт наличия. Показывают что java-решение (притом написанное довольно наивно) медленнее нативного, обёрнутого в фантик c#, и выдают это за достижение dotnet.
Называют quicksort — числодробилкой... Как я понял, теперь числодроблилка это всё, с чем c# не справляется. Для меня теперь новость: СЕНСАЦИЯ! На java можно писать числодробилки! java.util.Collections.sort — во всех кинотеатрах города!

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

I>>>Проверяем. Прогрей GC так, что бы миллиард объектов работал гладко, без проблем с GC. Естетсвенно, не прибегая ко всями пулам и off-heap Решениям.
N>>Про не прибегая к offheap это подтасовка. Я как раз говорил, что offheap — один из методов решения.
I>Я тебя попросил показать _другой_ способ для этой же задачи. Например — твой прогрев.
Можно погонять эксперименты с G1. Но это надо, конечно, быть в теме — что за объекты, что с ними происходит и что с ними надо делать. А то, например, для тупо new long[1_000_000_000] будет работать неплохо само по себе, никакого вычурного gc не надо.

Здравствуйте, Ikemefula, Вы писали:
N>>Ему не нравится, что сравнивают реализации с нативным кодом против чисто VMовских.
I>А по моему он не понимает аргумент про закрытые и открытые технологии.
Нет, netch80 прав. Зачем при обсуждении сабжа в принципе было упоминать native — непонятно.

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

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

Можно. Распределять и бесплатно — разные вещи. Сравни — я у тебя забесплатно беру 1000$ и я беру и возвращаю 1000$ мелкими порциями ?
Тебе какой из двух вариантов больше нравится ?

I>>У меня другие ощущения.
·>Ты просто в среде такой крутишься, скорее всего.

Разумеется.Я ведь не утверждаю, что мой опыт лучше твоего

I>>В дотнете относительно недавно начали появляться либы для работы с конским количеством объектов, миллиард и больше. Более того, даже в пейтоне, и JS тоже пошли такие фокусы, только масштаб меньше.
·>Интересно, что за либы? Что они делают?

Позволяют работать с конским графом объектов, в миллиард и больше количеством. Собственно, все что они делают — разгружают ГЦ.

·>Одну проблему вижу в том, что Collection.Count типа int32, что лишь немногим больше миллиарда. Не уверен насчёт JS, но пайтон это таки обычно клей поверх С-имплементации.

ГЦ складывается уже на 10млн объектов. Дальше нужны всевозможные ухищрения. Collection — во-первых, ты не обязан использовать этот интерфейс, а во-вторых, миллиард объектов совсем не означает, что все объекты будут в одной коллекции.

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

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

Ты продолжаешь путать причины. Нативный код нужен там, где никакой менеджед не даст внятный перформанс. Есть задачи, где перформанса никогда не бывает много.

То есть, нативный код не потому, что C# плохой, а нативный код потому, что он гарантировано быстрее чем менеджед.

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

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

Нет никакой проблемы с нативным кодом. Нативный код говорит о задачах, а не о языке.

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

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

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

Сам подумай — почему HPC, HFT, высоконагруженые приложения пишут на джаве, пейтоне. По уму, если выбирают перформанс, то надо писать исключительно на С++. Опаньки !
Теперь понятно, что если производительность отстаёт не на порядки, то это _дешевле_ пофиксить железом иногда даже виртуальным. Собтсвенно выбор в пользу джавы именно так и делается, а то бы весь софт писали бы на С++.

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

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

Ога, в банках быстродействие не надо ?

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

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

I>>Сильно частный случай. Локальность плюсовых структур ни одна vm не может обставить. Разница между кешем и доступом к памяти примерно два порядка. Кое где рантаймные оптимизации компенсируют отставание, но это мелочовочка.
·>Тут надо осторожно выражаться, не так категорично. Скажем, std::vector<std::string> внезапно совсем не локальный, а char[] локальный везде. Потом — компактификация кучи и ArrayList<String> может стать локальнее, чем std::vector<std::string>.

Может стать, а может и не стать. Зато в С++ у тебя полный контроль — ты сам решаешь, как данных будут размещаться в памяти. Скажем, в С++ сделать эквивалент std::vector<std::string> но с локальным хранением для частного случая это дело пяти минут.
Мне вот надо было в дотнете делать аналогичный фокус — массив больших объектов хранить одним куском, да так что бы объект влазил в одну страницу. И ничего, справился безо всяких ужасов и приседаний. Минут 15 потратил, после того, как от профайлера получил статистику

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

S>>> То что в яблоках используется только натив.
Хорошая гипотеза, но требует доказательств.

S>·>В общем случае — не значит. JIT может иногда давать лучший код, т.к. ему доступно реальная информация времени исполнения. AOT — этого может и не знать. Скажем, типичный пример — virtual call elimination — если используется единственная имплементация виртуальной функции во время работы приложения, то JIT может выкинуть косвенный вызов. AOT — такой информацией просто не обладает.
S> Угу на мобильных то устройствах? Там большинство до сих пор сидит на Java 6.
Да этому уж много лет, думаю с java 5 или как раз с 6.
Но даже если и так, интересно, что быстрее появится на мобильниках — java 8 или .net native?

S> А вот что касается инлайнинга и прочих оптимизаций то тут никакой оптимизатор лучше не сделает.
inline тоже делается. Притом после virtual call elimination. Круто ведь — возможность инлайна виртуальных функций!
https://blog.jooq.org/2016/07/19/the-java-jit-compiler-is-darn-good-in-optimization/

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

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

S>>> Нужна. Здесь на форуме много копий по этому поводу сломано.
S>·>Обсускаторы для java тоже есть.
S> Есть но машинный код лучше.
И компилятор тоже есть, для особо страждущих. https://www.excelsiorjet.com/

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

N>>>Но в теме HFT, которую обсуждает твой оппонент, это всё как раз мало значимо, и в сортировке — тоже.
I>>Ему не нравится сам факт наличия нативного кода в дотнете.
·>Не сам факт наличия. Показывают что java-решение (притом написанное довольно наивно) медленнее нативного, обёрнутого в фантик c#, и выдают это за достижение dotnet.

Предъявляй претензии vdimas.

·>Называют quicksort — числодробилкой... Как я понял, теперь числодроблилка это всё, с чем c# не справляется.

Числодробилка это любой алгоритм сложностью выше O(1). Сортировка, строки, массивы — эти вещи определяют производительность приложения, пропускную способность. Соответственно, их и надо полировать постоянно, а не гордиться тем, что решение менеджед.

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

N>>>Про не прибегая к offheap это подтасовка. Я как раз говорил, что offheap — один из методов решения.
I>>Я тебя попросил показать _другой_ способ для этой же задачи. Например — твой прогрев.
·>Можно погонять эксперименты с G1. Но это надо, конечно, быть в теме — что за объекты, что с ними происходит и что с ними надо делать. А то, например, для тупо new long[1_000_000_000] будет работать неплохо само по себе, никакого вычурного gc не надо.

Обычные объекты, унутре каждого строки, массивы и другие объекты и тд и тд и тд.

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

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

I>Тебе какой из двух вариантов больше нравится ?
Подходящий под конкретные условия. Я вот дом бы без кредита тупо не смог бы купить, жался бы по квартиркам, а на айфон кредит бы брать не стал.

I>>>У меня другие ощущения.
I>·>Ты просто в среде такой крутишься, скорее всего.
I>Разумеется.Я ведь не утверждаю, что мой опыт лучше твоего
Тогда не делай громких заявлений, что gc никому не нужен.

I>>>В дотнете относительно недавно начали появляться либы для работы с конским количеством объектов, миллиард и больше. Более того, даже в пейтоне, и JS тоже пошли такие фокусы, только масштаб меньше.
I>·>Интересно, что за либы? Что они делают?
I>Позволяют работать с конским графом объектов, в миллиард и больше количеством. Собственно, все что они делают — разгружают ГЦ.
Дай почитать, любопытно.

I>·>Одну проблему вижу в том, что Collection.Count типа int32, что лишь немногим больше миллиарда. Не уверен насчёт JS, но пайтон это таки обычно клей поверх С-имплементации.
I>ГЦ складывается уже на 10млн объектов. Дальше нужны всевозможные ухищрения. Collection — во-первых, ты не обязан использовать этот интерфейс, а во-вторых, миллиард объектов совсем не означает, что все объекты будут в одной коллекции.
Он складывается в определённых ситуациях. А более конкретно, когда структура этого графа постоянно изменяется, что инвалидирует соответствующие регионы кучи и их приходится пересканировать во время full gc. А просто лежащий в памяти массивный граф, но неизменяемый (меняешь только примитивные поля объектов, а не ссылки) — gc не мучает. Поэтому общего решения тут быть не может. Нужно понимать структуру этого графа и осторожно ею управлять, видимо эти либы и позволяют это как-то организовывать...

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

N>>>Ему не нравится, что сравнивают реализации с нативным кодом против чисто VMовских.
I>>А по моему он не понимает аргумент про закрытые и открытые технологии.
·>Нет, netch80 прав. Зачем при обсуждении сабжа в принципе было упоминать native — непонятно.

Ты сам спросил а я тебе рассказал про string и array. В дотнете полно таких оптимизаций и это одна из проблем. Оптимизации вполне обоснованы — сишный компилер при ряде условий может выдать и на порядок лучший результат, нежели самый лучший менеджед код.

Джависты в таком случае пишут на джаве и говорят "ну и что что медленнее, зато на джаве !!!"

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

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

Бесплатно это оно и есть. Тут даже возврат не предусматривается

I>>>>У меня другие ощущения.
I>>·>Ты просто в среде такой крутишься, скорее всего.
I>>Разумеется.Я ведь не утверждаю, что мой опыт лучше твоего
·>Тогда не делай громких заявлений, что gc никому не нужен.

А где ты видел у меня такие заявления ? Я от плюсов полностью отошел примерно 8-10 лет назад.

I>>·>Интересно, что за либы? Что они делают?
I>>Позволяют работать с конским графом объектов, в миллиард и больше количеством. Собственно, все что они делают — разгружают ГЦ.
·>Дай почитать, любопытно.

Господи, там обычный off-heap сторадж, навроде мемори маппед файлов. Таких в джаве пруд-пруди. Собственно в джаве эти вещи появились давным давно.

·>Он складывается в определённых ситуациях. А более конкретно, когда структура этого графа постоянно изменяется, что инвалидирует соответствующие регионы кучи и их приходится пересканировать во время full gc. А просто лежащий в памяти массивный граф, но неизменяемый (меняешь только примитивные поля объектов, а не ссылки) — gc не мучает. Поэтому общего решения тут быть не может. Нужно понимать структуру этого графа и осторожно ею управлять, видимо эти либы и позволяют это как-то организовывать...

С т.з. памяти это или обычный хип в несколько гигабайт размером, или просто кусок адресного пространства.
Физически гц видит пару сотен объектов. Логически — твоя модель шустро работает с миллиардом объектов.

Я делал без off-heap, на вычислимых объектах, value-типах и прочих фокусах. Мне удавалось выжать 30-100млн. При том, что ГЦ уверенно складывается уже на 10млн в старом поколении, это уже очень неплохо.

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

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

I>То есть, нативный код не потому, что C# плохой, а нативный код потому, что он гарантировано быстрее чем менеджед.
I>Кроме того, основываясь на более шустрых строках я напишу гораздо более эффективный алгоритм нежели ты на джаве.
Я сравниваю решение одних и тех же задач — реализация sort, реализация коллекции ArrayList, реализация String. А выше по топику vdimas показывал документ, где результаты перформанс тестов Native FIX engine (B2BITS) выдавал те же цифры, что и Java FIX engine (cheetah). Это крутые результаты — managed язык идёт на уровне перформанса unmanaged. c# аналогичных результатов не показывает — чуть что и сразу в кустынатив с воплями: "Числодробилка!".

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

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

I>>>Сильно частный случай. Локальность плюсовых структур ни одна vm не может обставить. Разница между кешем и доступом к памяти примерно два порядка. Кое где рантаймные оптимизации компенсируют отставание, но это мелочовочка.
I>·>Тут надо осторожно выражаться, не так категорично. Скажем, std::vector<std::string> внезапно совсем не локальный, а char[] локальный везде. Потом — компактификация кучи и ArrayList<String> может стать локальнее, чем std::vector<std::string>.
I>Может стать, а может и не стать. Зато в С++ у тебя полный контроль — ты сам решаешь, как данных будут размещаться в памяти. Скажем, в С++ сделать эквивалент std::vector<std::string> но с локальным хранением для частного случая это дело пяти минут.
Не совсем пяти минут. Тебе надо будет знать о том какой у тебя граф в памяти, т.к. если поменяешь время жизни этих самых string, то трудно отследить ломающее ли это изменение.

I>Мне вот надо было в дотнете делать аналогичный фокус — массив больших объектов хранить одним куском, да так что бы объект влазил в одну страницу. И ничего, справился безо всяких ужасов и приседаний. Минут 15 потратил, после того, как от профайлера получил статистику
Это как? Структуру что-ли использовал?

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

I>>>Ему не нравится сам факт наличия нативного кода в дотнете.
I>·>Не сам факт наличия. Показывают что java-решение (притом написанное довольно наивно) медленнее нативного, обёрнутого в фантик c#, и выдают это за достижение dotnet.
I>Предъявляй претензии vdimas.
Ну это ты же мне глупость какую-то приписал о "сам факт".

I>Числодробилка это любой алгоритм сложностью выше O(1). Сортировка, строки, массивы — эти вещи определяют производительность приложения, пропускную способность. Соответственно, их и надо полировать постоянно, а не гордиться тем, что решение менеджед.
В java тоже их полируют постоянно, но не на уровне исходников JDK (хотя исходники тоже полируют, но оставаясь в рамках языка), а на уровне JIT-оптимизатора.

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

I>>Ты продолжаешь путать причины. Нативный код нужен там, где никакой менеджед не даст внятный перформанс. Есть задачи, где перформанса никогда не бывает много.
·>Правильно — _никакой манаджед_. Но у нас другой случай: возьмём sort — почему один манаджед даёт внятный перформанс, а другой — не даёт?

Это враньё. Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код. У тебя даже тупой проход по массиву интов на сишном коде даст вопиющую разницу. Чем сложнее алгоритм, тем больше будет эта разница.

В джаве такие вещи сделали менеджед исключительно из за кроссплатформенности и в ущерб производительности. В дотнете никто про кроссплатформенность, по честному, не думал.

I>>Кроме того, основываясь на более шустрых строках я напишу гораздо более эффективный алгоритм нежели ты на джаве.
·>Я сравниваю решение одних и тех же задач — реализация sort, реализация коллекции ArrayList, реализация String. А выше по топику vdimas показывал документ, где результаты перформанс тестов Native FIX engine (B2BITS) выдавал те же цифры, что и Java FIX engine (cheetah).

Я не знаю, что там за алгоритмы. В обиходе уже лет 5 джава от дотнета мало чем отличается. Разница только в фичах пригодных для специальных кейсов. В джаве ничего такого нет.


I>>·>Нативный код это как крайний случай.
I>>Нет никакой проблемы с нативным кодом. Нативный код говорит о задачах, а не о языке.
·>Чем больше задач managed язык может решить без помощи нативного при сохранении внятного перформанса, тем он лучше.

Если речь про перформанс, то он обязан быть самым лучшим, а не просто внятным. У джавы перформанс никогда не был на первом месте. У ней на первом месте кроссплатформенность, менеджед со своими плюшками. Все что угодно, но не перформанс.
Хочешь перформанс — есть только Си и тот без плюсов.