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

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

S>>·>Или ehcache, или JCS, или OSCache, или Terrastore, или Cassandra или любую другую систему написанную на java.
S>>·>А потом закопать эту .net-недоплатформу обратно.
S>> Да можно такую же БД написать и на Net только какой в этом смысл,
·>Можно ли? Есть ли БД написанные на .net? Если нет, то почему?

S>> Просто для данной задачи когда данные постоянно обновляются, проще держать данные в БД, что бы не дефрагментировать постоянно по 200 мб
·>А что значит "держать данные в БД"? БД это не волшебный сундук подаренный инопланетянами, а тоже программа, и тоже написанная на ЯП. Притом есть БД написанные и на C/C++ и на Java, в этих языках почему-то 200мб без проблем дефрагментируются. А вот в .net ВНЕЗАПНО появляются сложности и надо просить помощи у native или java... место проклятое, не иначе.
Ты молодец. Игнорируешь мои записи прямо касающиеся проблемы.

Например в твоем примере массив byte[] имеет тот же размер. Можно копировать данные в текущий массив. Но вот общая скорость выполнения при этом уменьшится.

Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.

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

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

S>>·>И нибудь уже замерял производительность? Или даже не стоит?
S>> Для моих задач производительность не самое главное. Главное это замена COM под Линукс.
·>Допустим... ты не измерял. Но неужели никто больше не догадался померить?
Так тебе Ikemefula уже примеры приводил, где .Net Core быстрее?

Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.

S>>·>Если ты мне не веришь, не веришь приведённой статье, а так же не хочешь обращать на отстутствие c# LL-систем в мире, то проведи тесты сам — единственный надёжный способ доказать тебе этот факт.
S>> Еще раз на заборе тоже написано.
·>Что написано? "LL c# систем в мире нет", но на самом деле власти скрывают и за забором их даже куры не клюют. Так что-ли?
А ты не абстрактый LL а конкретный пример на который ссылаешься. Я не верю в дефрагментацию 200 мб за 4 мс.
S>>Ты должен и доказывать своё утверждение.
·>А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
·>Себе я доказывать уже не должен, себе я доказал на практике, видел собственными глазами.
·>Здесь в форуме я тоже не должен, не веришь статьям, не веришь заявлениям azul — твоё дело.
Я ничего доказывать не должен. Ты утверждаешь что приведенный пример будет работать без задержек на Java/

S>>Я верю статье. Но суть то этом примере, что ГС нужно постоянно дефрагментировать по 200 мб. Это не типичная работа для GC. Для этого проще использовать NoSQL или свой аналог.
·>Суть статьи в том, что gc создаёт паузы. Что не допустимо в LL. Суть теста в том, чтобы напрячь gc и убедиться, что с обещанным режимом Sustained Low Latency он и правда работает как Low Latency. Однако это не так.
Ну так приведи пример на Java где он будет постоянно без задержек дефрагментировать постоянно по 200 мб

S>> Например в твоем примере массив byte[] имеет тот же размер. Можно копировать данные в текущий массив. Но вот общая скорость выполнения при этом уменьшится.
S>>Тут уж выбирай, что важно общая скорость или задержки.
·>В статье общая скорость и не измеряется, измеряются задерки.
В статье задержки на C#. Ты утверждаешь, что на Java задержек не будет. Именно с этим примером по дефрагментации 200 мб. При этом память должна забиваться тоже быстро иба за цикл добавляется по 200 мб, при этом поток не один.
Но опять, же проблему с задержками можно решать либо через определенные структуры данных, либо через БД.
Но зачем тогда C++? Или Java уже и натив обгоняет.
Мне просто интересно справится Java как ты утверждаешь или нет.

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

I>Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.

Какая прелесть! А всего пару лет назад мне тут с пеной у рта доказывали, что .Net медленее С++ максимум в 2-3 раза... Выходит, core в 3-4 раза быстрее плюсов

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

I>> Более того, благодаря type erasure джавовские контейнеры мягко говоря не блещут производительностью в менеджед мире. Там где в дотнете будет одна страница памяти благодаря генерикам, в джаве будет граф рандомно разбросаный по памяти.
·>type erasure тут не причём. Причём тут только отличие primitive types vs objects. Но есть библиотеки эффективной реализации коллекций для примитивных типов.
·>А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.

На регистры и ассемблер это передёргивание, впрочем как и на стэк. Речь про локальность данных, необязательно на стэке — это может быть массив в куче, но без кучи индерекций.
Никакой ассемблер для этого не нужен — на C++ всё работает без проблем, на C# более ограниченно но таки есть. В Java же приходится вручную нарезать буфера на структуры — муторно, но таки реализуется без всякого ассемблера и регистров.
Уверен ты и сам всё это понимаешь — тогда к чему эти сказки про регистры и ассемблер?

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

AS>Где почитать стратегию microsoft на ближайшую пятилетку?

AS>А то есть мнение, что Микрософт стал Борландом (и поэтому его ждёт та же участь — скупка конкурентами).

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

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

I>>Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.

IID>Какая прелесть! А всего пару лет назад мне тут с пеной у рта доказывали, что .Net медленее С++ максимум в 2-3 раза... Выходит, core в 3-4 раза быстрее плюсов
У нас система двоичная. Порядок это в 2 раза.

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

I>>Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.
IID>Какая прелесть! А всего пару лет назад мне тут с пеной у рта доказывали, что .Net медленее С++ максимум в 2-3 раза... Выходит, core в 3-4 раза быстрее плюсов

Сейчас ещё замедлят в три раза, и вообще C++ догонит

	Скрытый текст
	Идет лекция по математике, в аудитории лектор и 3 студента. Внезапно встают 5 человек и уходят. Лектор: — Вот сейчас придут еще двое, и вообще никого не останется.

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

EP>Сейчас ещё замедлят в три раза, и вообще C++ догонит
EP>

	Скрытый текст
	EP>Идет лекция по математике, в аудитории лектор и 3 студента. EP>Внезапно встают 5 человек и уходят. EP>Лектор: EP>- Вот сейчас придут еще двое, и вообще никого не останется.

0A программистов продукт решили сделать,
Один спросил "А деньги где?", и их осталось 9.


9 программистов предстали перед боссом,
Один из них не знал FoxPro, и их осталось 8.


8 программистов купили IBM,
Один сказал "Мак лучше!", и их осталось 7.


7 программистов хотели help прочесть,
У одного покрылся винт, и их осталось 6.


6 программистов пытались код понять,
Один из них сошел с ума, и их осталось 5.

5 программистов купили CD-ROM,
Один принес китайский диск — остались вчетвером.


4 программиста работали на Си,
Один из них хвалил Паскаль, и их осталось 3.


3 программиста в сети играли в DOOM,
Один чуть-чуть замешкался, и счет стал равен двум.


2 программиста набрали дружно: "win"
Один устал загрузки ждать — остался лишь 1.


1 программист все взял под свой контроль,
Hо встретился с заказчиком, и их осталось 0.


0 программистов ругал сердитый шeф,
Потом уволил одного, и стало их FF.

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

S> Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.
Ты всё ещё не понимаешь суть LL. Пусть хоть 4 дня дефрагментирует. Главное — без единовременных задердек всех тредов приложения на время большее сотен микросекунд.
Т.е. LL GC должен работать по-другому, не так как бы ты ожидал от "быстрого и эффективного" GC. Он должен не пытаться сделать всё сразу при первом шансе пока все ждут, а размазать это на много небольших кусочков, чтобы исключить единовременные задержки. Т.е. улучшение latency обычно происходит за счёт ухудшения throughput.

Вот тебе аналогия. Представь себе тебе нужно на машине доставить груз из точки А в точку Б по городу, куча светофоров, поворотов, етс.
Есть два варианта движения.
1. Груз — дрова. Лучше всего — давать резко газу на зелёный, тормозить в пол перед красным, входить в повороты на скорости, и т.п. да — ты довезёшь груз быстрее, обеспечишь хороший throughput.
2. А теперь представь что груз тарелка с супом. С обычным стилем езды ты всё разольёшь на первом же светофоре. Поэтому тебе нужно тормозить заранее, хорошо предсказывая когда зажжется красный, ускорятся плавно, подтормаживать перед поворотами. Доедешь ты медленнее, но супа в тарелке останется больше. Вот это latency.

Разные задачи — разное решение.

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

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

I>>> Более того, благодаря type erasure джавовские контейнеры мягко говоря не блещут производительностью в менеджед мире. Там где в дотнете будет одна страница памяти благодаря генерикам, в джаве будет граф рандомно разбросаный по памяти.
EP>·>type erasure тут не причём. Причём тут только отличие primitive types vs objects. Но есть библиотеки эффективной реализации коллекций для примитивных типов.
EP>·>А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.

EP>На регистры и ассемблер это передёргивание, впрочем как и на стэк. Речь про локальность данных, необязательно на стэке — это может быть массив в куче, но без кучи индерекций.
EP>Никакой ассемблер для этого не нужен — на C++ всё работает без проблем, на C# более ограниченно но таки есть. В Java же приходится вручную нарезать буфера на структуры — муторно, но таки реализуется без всякого ассемблера и регистров.
EP>Уверен ты и сам всё это понимаешь — тогда к чему эти сказки про регистры и ассемблер?
Это ты у меня спрашиваешь? Здесь я с тобой согласен.
Тут просто меня убеждают, что без регистров java быстро работать не может, а в шарпе обещают какие-то хаки, чтобы регистрами управлять. Ха. Три раза.

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

EP>>Уверен ты и сам всё это понимаешь — тогда к чему эти сказки про регистры и ассемблер?
·>Это ты у меня спрашиваешь? Здесь я с тобой согласен.
·>Тут просто меня убеждают, что без регистров java быстро работать не может, а в шарпе обещают какие-то хаки, чтобы регистрами управлять. Ха. Три раза.

Речь о том что локальность (в частности C#-ский struct) позволяет более эффективно использовать железо — кэш, регистры и т.п. А не о том что нужно вручную колупаться в регистрах чтобы получить локальность.

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

·>Кстати, я почитал твои ссылки с графиками. Не понял что именно ты хотел доказать. Это что-ли?
·>The Java based FIX engine closely matched the native C++ code
·>Вполне ожидаемый результат.

Сам движок был написан как порт сишной реализации, поэтому по поведению она близка нашей нейтивной.
Про близкие результаты там ни слова, это ты сам себя уже уговариваешь. ))


·>Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать?

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


·>По-моему, результат отлично доказывающий мою позицию.

Плавание по сразу многим вопросам не может называться позицией. Сначала надо перестать плавать, потом обязательно стоит начать смотреть на вещи объективно (хотя бы перестать передёргивать и врать самому себе) и только потом заявлять о некоей "своей позиции".

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

I>>>>Где, по твоему, БД хранит буфер транзакций и в какой момент она его сбрасывает на диск ?
EP>>>Знаешь что означает D в ACID?
I>>Во первых, вопрос задвался не тебе

EP>Какая разница? Здесь форум вообще-то

Ну вот, снова, с места и в лужу.

I>>Во вторых, раз уж влазишь, научись на прямой вопрос отвечать прямо

EP>Захочу прямо, а захочу сошлюсь на букварь из которого всё следует. Здесь опять-таки форум, а не Q&A

Ты выбрал что-то среднее. См выше.

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

S>·>Допустим... ты не измерял. Но неужели никто больше не догадался померить?
S> Так тебе Ikemefula уже примеры приводил, где .Net Core быстрее?
S>

S>Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.

Ага, спасибо. Было смешно, все посмеялись.

S>·>Что написано? "LL c# систем в мире нет", но на самом деле власти скрывают и за забором их даже куры не клюют. Так что-ли?
S> А ты не абстрактый LL а конкретный пример на который ссылаешься. Я не верю в дефрагментацию 200 мб за 4 мс.
В LL не надо дефрагментировать 200мб за 4мс.

S>·>А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
S>·>Себе я доказывать уже не должен, себе я доказал на практике, видел собственными глазами.
S>·>Здесь в форуме я тоже не должен, не веришь статьям, не веришь заявлениям azul — твоё дело.
S> Я ничего доказывать не должен. Ты утверждаешь что приведенный пример будет работать без задержек на Java/
Уверен. Если не сработает — зарепорчу баг в azul.

S>>>Я верю статье. Но суть то этом примере, что ГС нужно постоянно дефрагментировать по 200 мб. Это не типичная работа для GC. Для этого проще использовать NoSQL или свой аналог.
S>·>Суть статьи в том, что gc создаёт паузы. Что не допустимо в LL. Суть теста в том, чтобы напрячь gc и убедиться, что с обещанным режимом Sustained Low Latency он и правда работает как Low Latency. Однако это не так.
S> Ну так приведи пример на Java где он будет постоянно без задержек дефрагментировать постоянно по 200 мб
В статье не "постоянно 200мб", а примерно раз в минуту задержки по >100мс на сборку этих самых мб.
Кстати, ты указывал на возможность, что это windows вызывает паузы, а не gc. Периодичность пиков может служить доказательством, что это связанно именно с gc, вряд ли винда что-то вот так периодично шалит. Хотя ещё неплохо было бы график пауз сопоставить с графиком занятости памяти — они должны совпасть.

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

S>Но опять, же проблему с задержками можно решать либо через определенные структуры данных,
Нельзя. Это особенность работы алгоритма gc.
Единственное что можно теоретически сделать — полностью 100% zero garbage код, но это сложно, очень связывает по рукам и ногам, лишаешься многих удобностей.

S>либо через БД.
Т.е. признать, что .net эта задача не под силу и взять native или java. Собственно к этому я и клоню.
Никакая мне известная БД не может использоваться в LL, там вообще жуткие задержки бывают, похуже самого плохого gc, да ещё и локи.

S> Но зачем тогда C++? Или Java уже и натив обгоняет.
S> Мне просто интересно справится Java как ты утверждаешь или нет.
Я видел, что справлялась. У на одном из наших сервисов очистка примерно 1гб мусора происходила примерно раз в час, притом потоки не останавливались на время большее 1мс. Да, кстати, 1мс — это точность измерений, сколько точно микросекунд были задержки — не знаю, всё что меньше 1мс просто не регистрировалось. Если я правильно помню (могу и соврать), по gc-логам время было в среднем в районе 50мкс.

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

I>>·>Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать? По-моему, результат отлично доказывающий мою позицию.
I>>С дотнетом проблема не в производительности, а в том, что это закрытая технология и до недавних пор Windows-only.
·>А с недавних пор — непонятно зачем это нужно. И предсказываю, что в обозначенных в сабже временных рамках вряд ли что-то значительно поменяется. Ибо "быстрее на 10% в наших тестах" не является киллер-фичей, и вряд ли кто потащит .net в другие ниши, ради лишь "шоб былО".

Потащат потому, что есть конторы на .Net стеке почти целиком. И новые конторы так же будут выбрать не только джаву.

I>>Собственно, если надо выжать максимум производительности, то здесь .Net уделает джаву, как тузик грелку.
·>Ага, а если учесть это "The Java based FIX engine closely matched the native C++ code", то следует, что .net уделает native как тузик грелку. Хотел бы я на это посмотреть...

См выше. Для тебя еще раз "закрытая технология и до недавних пор Windows-only"

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

Существует, не волнуйся. Для тебя еще раз "закрытая технология и до недавних пор Windows-only"

I>>Это облегает майнтенанс и снижает целую кучу рисков.
I>>Собственно, Микрософт работает над этой проблемой, но мягко говоря, запоздало — это надо было лет 10 назад сделать.
·>Так поезд уже ушел. Майкрософту надо работать над киллер-фичей. Просто обещания уделывать java как тузик-грелку — киллер-фичей не являются.

Они и работают над этим, не волнуйся.

I>>Разница между нейтивом и менеджед кодом, фактически, в эффективности использования кеша процессора, ядер и планирования IO. И если менеджед хорошо справляется с IO и потоками, то с кешем всё очень плохо — менеджед, любой, независимо от природы, перепахивает в основном память.
·>Неправда. Конечно, из-за строгости стандартов сделать код на Яве, который будет пахать одинаково эффективно на всех возможных имплементациях JVM на всех платформах от чайников до супер-компьютеров, но запилить под конкретное окружение на конкретном железе можно. Собственно та же ситуация, что и с нейтивом.

И при этом на нейтиве все равно можно в раза два быстрее сделать.

I>>Для того, что бы лучше использовать кеш, нужна та самая локальность — стек, регистры, value type и тд. В дотнете кучка костылей в наличии. В джаве — практически ничего.
·>Немного есть. И этого, как показал опыт, хватает.

Хватает для чего ? Для throughput ? Сильно вряд ли. Для LL — если закрыть глаза на другие технологии.

I>> Более того, благодаря type erasure джавовские контейнеры мягко говоря не блещут производительностью в менеджед мире. Там где в дотнете будет одна страница памяти благодаря генерикам, в джаве будет граф рандомно разбросаный по памяти.
·>type erasure тут не причём. Причём тут только отличие primitive types vs objects. Но есть библиотеки эффективной реализации коллекций для примитивных типов.
·>А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.

А ты хорошо понимаешь, какой код генерит С++ компилер ?

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

EP>>>Уверен ты и сам всё это понимаешь — тогда к чему эти сказки про регистры и ассемблер?
EP>·>Это ты у меня спрашиваешь? Здесь я с тобой согласен.
EP>·>Тут просто меня убеждают, что без регистров java быстро работать не может, а в шарпе обещают какие-то хаки, чтобы регистрами управлять. Ха. Три раза.
EP>Речь о том что локальность (в частности C#-ский struct) позволяет более эффективно использовать железо — кэш, регистры и т.п. А не о том что нужно вручную колупаться в регистрах чтобы получить локальность.
В принципе new MyClass[100_000] вполне локален. Может быть немного неэффективен, но не настолько страшно, как малюют.
На крайний случай всегда есть new byte[1_000_000] — но таких мест где это реально требуется — очень мало.
java быстро работать может — факт, пусть код выглядит похуже, это не show stopper.

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

I>>Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.

IID>Какая прелесть! А всего пару лет назад мне тут с пеной у рта доказывали, что .Net медленее С++ максимум в 2-3 раза... Выходит, core в 3-4 раза быстрее плюсов

Имеется ввиду вещи навроде asp.net и тд. Чистый ванильный код почти так же и работает, как и раньше.

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

V>·>Кстати, я почитал твои ссылки с графиками. Не понял что именно ты хотел доказать. Это что-ли?
V>·>The Java based FIX engine closely matched the native C++ code
V>·>Вполне ожидаемый результат.
V>Сам движок был написан как порт сишной реализации, поэтому по поведению она близка нашей нейтивной.
Ну и? Удивляешься тому, что код можно писать по разному — быстрый и не очень?

V>Про близкие результаты там ни слова, это ты сам себя уже уговариваешь. ))
Не понял, как "ни слова"? Это же copy-paste цитата. Может у тебя монитор заляпан и ты не увидел это предложение в документе, на который ты сослался? В том же месте, кстати заляпан, где ты не смог увидеть import java.util.concurrent в тесте на который ты сослался.

V>·>Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать?
V>Т.е. на джаве асилили, а на дотнете, на котором в два раза проще и в два раза меньше кода требуется — нет.
V>Оригинально.
Да, оригинально. Но факт остаётся фактом.

V>Похоже, ты решил, таки, не сдерживать себя?
Я лишь привожу факт.

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

I>Они и работают над этим, не волнуйся.
Хз, поживём увидим. MS много над чем работал... Всего доброго им, и хорошего настроения.

I>·>Неправда. Конечно, из-за строгости стандартов сделать код на Яве, который будет пахать одинаково эффективно на всех возможных имплементациях JVM на всех платформах от чайников до супер-компьютеров, но запилить под конкретное окружение на конкретном железе можно. Собственно та же ситуация, что и с нейтивом.
I>И при этом на нейтиве все равно можно в раза два быстрее сделать.
Как выяснилось, что можно и не сделать. Собственно опять, причём тут нейтив. В сабже его нет.

I>·>Немного есть. И этого, как показал опыт, хватает.
I>Хватает для чего ? Для throughput ? Сильно вряд ли.
Для throughput обычно кластеризуют, там вот да, c# может конкурировать Яве. Хотя тоже не особо. Вон SO обсуждали — из Шарпа там только сами странички, а остальное это либо нативные технологии типа mssql, веб-, проки-серверов, либо ВНЕЗАПНО java Elasticsearch.

I>Для LL — если закрыть глаза на другие технологии.
На текущий момент — одна технология, нейтив, у которого свои минусы.
И что-то сомневаюсь, что .net сможет догнать в рамках, обозначенных в сабже.

I>·>type erasure тут не причём. Причём тут только отличие primitive types vs objects. Но есть библиотеки эффективной реализации коллекций для примитивных типов.
I>·>А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.
I>А ты хорошо понимаешь, какой код генерит С++ компилер ?
Он чем-то принципиально отличается от C2 compiler?

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

EP>>Речь о том что локальность (в частности C#-ский struct) позволяет более эффективно использовать железо — кэш, регистры и т.п. А не о том что нужно вручную колупаться в регистрах чтобы получить локальность.
·>В принципе new MyClass[100_000] вполне локален. Может быть немного неэффективен, но не настолько страшно, как малюют.

MyClass может содержать внутри ссылки на другие объекты, те в свою очередь ещё на другие, а сам массив может быть многократно перемешан/отсортирован — привет проседания на один-несколько порядков. Не говоря уже о дополнительной работе для GC.

·>На крайний случай всегда есть new byte[1_000_000] — но таких мест где это реально требуется — очень мало.
·>java быстро работать может — факт, пусть код выглядит похуже, это не show stopper.

"Похуже" — это такой аутотренинг с самоуспокоением? Там от языка-то практически ничего не остаётся — классы нельзя, GC нельзя, композицию нельзя и т.п.

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