Вопрос, скорее, не холиварный, а исследовательский.
Известно, что из топ 1 миллиона сайтов
около 35 процентов занимает php
около 16 процентов — .net
около 4 процентов — J2EE

Если рассмотреть топ 10к сайтов, то доля PHP уменьшается до 17%, доля .net увеличивается до 18%, доля J2EE увеличивается до 8%.

Технологии java & c# схожи, и для крупных проектов с участием большого количества программистов подходят больше, чем php.

Но вот интересно, никто не пытался сделать сайт с одинаковым функционалом на java и на c#.
И сравнить их производительность на приблизительно одной нагрузке и затраты на разработку приблизительно одинаково оплачиваемыми программистами.
Так сказать, провести A,B анализ....

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

T>Вопрос, скорее, не холиварный, а исследовательский.

T>Но вот интересно, никто не пытался сделать сайт с одинаковым функционалом на java и на c#.
T>И сравнить их производительность на приблизительно одной нагрузке и затраты на разработку приблизительно одинаково оплачиваемыми программистами.
T>Так сказать, провести A,B анализ....

Скорее, холиварный. Прежде всего из-за выбранной метрики — производительности. Производительность сайтов прежде всего зависит от производительности СУБД и адекватности работы с ней, что к языку разработки привязано слабо.

В разрезе минимизации стоимости разработки, разумеется, надо выбирать PHP. Кластер машин фронтенда с СУБД на хорошем железе покажет очень хорошее быстродействие.

Почему тогда все сайты не написаны на PHP? Потому, что поддержка и развитие продукта обходятся значительно дороже разработки. Современное железо хоть и дешево, но тоже не бесплатно, а для с# нужно учитывать еще и стоимость лицензий.

На практике вопрос выбора между с# и java не стоит, т.к. в рамках одной компании для серверных приложений используется или первое, или второе. Очень уж разные технические стеки.

T> В разрезе минимизации стоимости разработки, разумеется, надо выбирать PHP.

Почему не JavaScript ?

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

scf>Скорее, холиварный. Прежде всего из-за выбранной метрики — производительности. Производительность сайтов прежде всего зависит от производительности СУБД и адекватности работы с ней, что к языку разработки привязано слабо.

СУБД, железо — в обоих экспериментах одинаково. Для джавы есть выбор операционки: win or unix.

scf> для с# нужно учитывать еще и стоимость лицензий.
для java тоже. Но в моем вопросе стоимость лицензий рассматривать не нужно.

scf>На практике вопрос выбора между с# и java не стоит, т.к. в рамках одной компании для серверных приложений используется или первое, или второе. Очень уж разные технические стеки.
Стоит, конкретно у нас. Есть бюджет на новый продукт. Два центра компетенций конкурируют за право взять его на себя.

Собственно, вопрос пока открыт.

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

T>СУБД, железо — в обоих экспериментах одинаково. Для джавы есть выбор операционки: win or unix.

Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.

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

T>Известно, что из топ 1 миллиона сайтов
T>около 35 процентов занимает php
T>около 16 процентов — .net
T>около 4 процентов — J2EE

А откуда эта статистика? Было бы интересно посмотреть в деталях.

T>и затраты на разработку приблизительно одинаково оплачиваемыми программистами.

Оценок, сколь-нибудь претендующих на объективность я не видел. По моим субъективным наблюдениям — разработка на C# идет несколько быстрее. За счет удобств синтаксиса. В рантайме — C# должен немного выигрывать за счет использования value types (struct, generics с примитивными типами), но на практике народ не так активно использует struct, как я ожидал. В Java поддержка value types скоро* должна появиться, так что здесь они сравняются.

(*скоро — понятие относительное. ждут уже много лет, но вроде пошли первые неофициальные билды с value types, так что есть надежда, что через несколько месяцев оно таки там появится)

T>Но вот интересно, никто не пытался сделать сайт с одинаковым функционалом на java и на c#.
T>И сравнить их производительность на приблизительно одной нагрузке и затраты на разработку приблизительно одинаково оплачиваемыми программистами.
T>Так сказать, провести A,B анализ....

странно, что никто ссылку не кинул пока
вот тесты
тебе они не помогут — java и c# условно считают одинаково быстрыми и выбирают исходя из стоимости/скорости разработки

Здравствуйте, koenig, Вы писали:
K>тебе они не помогут — java и c# условно считают одинаково быстрыми и выбирают исходя из стоимости/скорости разработки

Интересно, но ты прав — не помогут.

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

T>Вопрос, скорее, не холиварный, а исследовательский.
T>Известно, что из топ 1 миллиона сайтов
T>около 35 процентов занимает php
T>около 16 процентов — .net
T>около 4 процентов — J2EE

А остальные 45%? Где брали статистику?

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

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

scf>>Скорее, холиварный. Прежде всего из-за выбранной метрики — производительности. Производительность сайтов прежде всего зависит от производительности СУБД и адекватности работы с ней, что к языку разработки привязано слабо.

T>СУБД, железо — в обоих экспериментах одинаково. Для джавы есть выбор операционки: win or unix.
Для дотнета — тоже.

scf>> для с# нужно учитывать еще и стоимость лицензий.
T>для java тоже. Но в моем вопросе стоимость лицензий рассматривать не нужно.

scf>>На практике вопрос выбора между с# и java не стоит, т.к. в рамках одной компании для серверных приложений используется или первое, или второе. Очень уж разные технические стеки.
T>Собственно, вопрос пока открыт.
Теоретически, дотнет можно сделать быстрее. По крайней мере, на мелких реквестах.
Потому что в нём есть не только ValueType, но и недавние оптимизации для, например, парсинга HTTP хидеров без копирования. В предыдущих версиях дотнета и, насколько я знаю, в Яве, парсинг заголовков означал массовые копирования подстрок и динамическое выделение памяти, которое создаёт нагрузку на GC даже в том случае, если хэндлер просто пишет в выходной поток "HelloWorld" и закрывается.
Понятно, что на фоне "сбегать в СУБД" такие мелочи незаметны; но оптимизация веб-приложения — это в первую очередь умение быстро отдавать 200 Ok на идемпотентный PUT или 304 на conditional get. Если у вас всё хорошо, то 90% ответов — это как раз 304. И как раз такие пути исполнения можно разогнать в разы при помощи zero-copy и прочих stackalloc. Получив, в теории, до двукратного ускорения.

На практике, пока что мы имеем всё это счастье в продакшн-качестве всего лишь с марта месяца, поэтому прикладного кода, который мог бы воспользоваться преимуществами C#7.3 и .Net Core 2.1, пока что в природе не существует.

Ну, и по-хорошему стоило бы спросить экспертов по Java — может там тоже выпилен какой-то особо ускоренный пайплайн на основе ручной работы с JNI и байтовыпиливания

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

S> Потому что в нём есть не только ValueType, но и недавние оптимизации для, например, парсинга HTTP хидеров без копирования. В предыдущих версиях дотнета и, насколько я знаю, в Яве, парсинг заголовков означал массовые копирования подстрок и динамическое выделение памяти, которое создаёт нагрузку на GC даже в том случае, если хэндлер просто пишет в выходной поток "HelloWorld" и закрывается.
Это ты наверное servlet api имеешь в виду — он вроде никогда особо и не пилился для быстродействия, а для ентерпрайза. А так туева хуча high-performance http-серваков на чистой java — spark, jetty, примочки для netty, akka, и т.п. JNI если и используется, но обычно как тонкая обёртка над специфичным сетевым API операционки.

А вообще, с т.з. производительности Java, конечно, на голову выше. Начиная с того, что тысячи человеко-лет вложенных в оптимизацию JVM, hotspot, gc. Плюс куча инструментария для профилирования и мониторинга, куча вариантов тьюнинга всего чего только можно, альтернативные реализации JVM типа Azul. Да и факт, что java работает в проде на linux обычно — плюс все возможности контроля и оптимизации производительности на уровне ОС.

А ValueType... с т.з. производительности как оказалось мало чем помогает.

Ну в общем если хочется померяться, то можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json
c# на 40-м месте, после питона?

Здравствуйте, ·, Вы писали:
·>Это ты наверное servlet api имеешь в виду — он вроде никогда особо и не пилился для быстродействия, а для ентерпрайза. А так туева хуча high-performance http-серваков на чистой java — spark, jetty, примочки для netty, akka, и т.п. JNI если и используется, но обычно как тонкая обёртка над специфичным сетевым API операционки.
Не очень понятно, как можно написать high-performance http-сервер на технологии, где банальная проверка заголовка if-modified-since означает конверсию из ASCII-7 в UCS2 и двойное копирование подстроки.
Или там вручную байты сравниваются?

>А вообще, с т.з. производительности Java, конечно, на голову выше. Начиная с того, что тысячи человеко-лет вложенных в оптимизацию JVM, hotspot, gc. Плюс куча инструментария для профилирования и мониторинга, куча вариантов тьюнинга всего чего только можно, альтернативные реализации JVM типа Azul. Да и факт, что java работает в проде на linux обычно — плюс все возможности контроля и оптимизации производительности на уровне ОС.
Дотнет как бы тоже работает на линукс.

·>А ValueType... с т.з. производительности как оказалось мало чем помогает.
Ну, так его же применять надо.

·>Ну в общем если хочется померяться, то можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json
·>c# на 40-м месте, после питона?
Ну, во-первых, там конкуренция высокая. Если мерить не в местах, а в процентах, то он медленнее лидера всего на 25%. Во-вторых, это как раз примерно то, о чём я говорил — нововведения ещё не доехали до результата.
Тот же кестрел ещё не использует ничего из новинок, ну и сериализация у нас опять-таки в UCS2, с последующей конверсией в UTF-8.

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

S>Здравствуйте, ·, Вы писали:
S>·>Это ты наверное servlet api имеешь в виду — он вроде никогда особо и не пилился для быстродействия, а для ентерпрайза. А так туева хуча high-performance http-серваков на чистой java — spark, jetty, примочки для netty, akka, и т.п. JNI если и используется, но обычно как тонкая обёртка над специфичным сетевым API операционки.
S>Не очень понятно, как можно написать high-performance http-сервер на технологии, где банальная проверка заголовка if-modified-since означает конверсию из ASCII-7 в UCS2 и двойное копирование подстроки.
S>Или там вручную байты сравниваются?
Тут ведь как... если хотим перформанс, то можно ведь наоборот — UCS2 в ASCII-7 конвертировать, притом только один раз, при старте приложения, а при обработке каждого конкретного запроса стремимся к zero-gc, zero-copy. Понятно, что таким образом универсальный всемогутер не написать, но различных средств достаточно, чтобы подпиливать под конкретные юзкейсы.

>>А вообще, с т.з. производительности Java, конечно, на голову выше. Начиная с того, что тысячи человеко-лет вложенных в оптимизацию JVM, hotspot, gc. Плюс куча инструментария для профилирования и мониторинга, куча вариантов тьюнинга всего чего только можно, альтернативные реализации JVM типа Azul. Да и факт, что java работает в проде на linux обычно — плюс все возможности контроля и оптимизации производительности на уровне ОС.
S>Дотнет как бы тоже работает на линукс.
Ага, как бы работает.

S>·>А ValueType... с т.з. производительности как оказалось мало чем помогает.
S>Ну, так его же применять надо.
Это ведь тоже не универсальный всемогутер. В java если надо, то делают структуры на массивах. Притом в зависимости от ситуации — могут быть массивы структур или структуры массивов.

S>·>Ну в общем если хочется померяться, то можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json
S>·>c# на 40-м месте, после питона?
S>Ну, во-первых, там конкуренция высокая. Если мерить не в местах, а в процентах, то он медленнее лидера всего на 25%. Во-вторых, это как раз примерно то, о чём я говорил — нововведения ещё не доехали до результата.
Ну дык... Они догоняют. Но ведь остальыне платформы тоже не стоят на месте. Их тоже постоянно пилят. Вот в скорем времени и ValueType обещают в java, правда я не очень оптимистичен, сомневаюсь что это даст какой-то существенный прирост производительности. Оно, скорее всего, может лишь пригодится для упрощения _некоторого_ кода.

S>Тот же кестрел ещё не использует ничего из новинок, ну и сериализация у нас опять-таки в UCS2, с последующей конверсией в UTF-8.
Поживём, увидим.

·>А вообще, с т.з. производительности Java, конечно, на голову выше. Начиная с того, что тысячи человеко-лет вложенных в оптимизацию JVM, hotspot, gc. Плюс куча инструментария для профилирования и мониторинга, куча вариантов тьюнинга всего чего только можно, альтернативные реализации JVM типа Azul. Да и факт, что java работает в проде на linux обычно — плюс все возможности контроля и оптимизации производительности на уровне ОС.

·>А ValueType... с т.з. производительности как оказалось мало чем помогает.

·>Ну в общем если хочется померяться, то можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json
·>c# на 40-м месте, после питона?

я правильно понимаю, что судя по этой табличке тысячи человеко-лет вложенных в оптимизацию JVM позволили java быть на статистическую погрешность быстрее php?

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

K>я правильно понимаю, что судя по этой табличке тысячи человеко-лет вложенных в оптимизацию JVM позволили java быть на статистическую погрешность быстрее php?

Нет, java быстрее PHPшной либы написанной на C. В C/C++ кстати уж точно не меньше вложено.

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

S>А остальные 45%? Где брали статистику?

Там еще у питона хороший % должен быть. Но вообще интересно, да. Вот торчит REST API, как определить на чем оно реализовано? Понятно что есть родимые пятна всякие но это все оочень не точно.

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

K>·>Ну в общем если хочется померяться, то можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=json
K>·>c# на 40-м месте, после питона?
K>я правильно понимаю, что судя по этой табличке тысячи человеко-лет вложенных в оптимизацию JVM позволили java быть на статистическую погрешность быстрее php?
Похохмить или правда интересно?
Во-первых, php написан на C++, и в том сравнении самого php кода там скорее всего нуль. Тот же парсинг http-запроса и рисование ответа явно на плюсах, в php наверное только echo 'hello'.
Во-вторых, производительность java проявляется не только в вебе, а, много где. Например, в hft. Где ни php, ни .net никогда не было. Т.е. это не то что php хорош, а то что web — такая область, что там хоть левой пяткой через плечо пиши — всё заработает.

Здравствуйте, ·, Вы писали:
S>>Или там вручную байты сравниваются?
·>Тут ведь как... если хотим перформанс, то можно ведь наоборот — UCS2 в ASCII-7 конвертировать, притом только один раз, при старте приложения, а при обработке каждого конкретного запроса стремимся к zero-gc, zero-copy. Понятно, что таким образом универсальный всемогутер не написать, но различных средств достаточно, чтобы подпиливать под конкретные юзкейсы.
Простите, я тупой, мне непонятно — как это "UCS2 в ASCII-7 конвертировать, притом только один раз". То есть мы берём и превращаем "If-Modified-Since" в byte[]?
Но тогда нам нужны алгоритмы, позволяющие выполнять сравнения byte[] массивов с фрагментами буфера. Причём zero-copy. Причём было бы ещё неплохо, чтобы сравнивалка умела не в цикле байтики крутить, а, скажем, сразу SIMD инструкциями.

То есть вся инфраструктура работы со строками выбрасывается и заменяется на инфраструктуру по работе с byte[]. При этом, например, такая банальная вещь, как Slice (или Span<byte>) у нас в некотором смысле невозможна — ведь Value типов нет, поэтому объект, состоящий из "указатель на массив + смещение фрагмента + длина фрагмента" неизбежно создаёт нагрузку на GC.
И это мы ещё не упёрлись в то, что после двоеточия в if-modified-since должна идти дата, и нам нужна инфраструктура по парсингу даты из byte[], вместо стандартной библиотеки, которая умеет парсить только строки.

Как это решили в Java? Напилили весь нижний уровень без строк?

Ну, то есть вот в дотнете пацаны поняли, что упираются не столько в отсутствие библиотек, сколько в отсутствие возможности их написать. В итоге пришлось одновременно пилить CLR (для поддержки т.н. ref structs, чтобы иметь возможность безопасно манипулировать ссылками, не создающими GC Root), и джит — чтобы, к примеру, проверки выхода за диапазон устранялись не только для int[], но и для созданного на его основе Span<int>.

S>>·>А ValueType... с т.з. производительности как оказалось мало чем помогает.
S>>Ну, так его же применять надо.
·>Это ведь тоже не универсальный всемогутер. В java если надо, то делают структуры на массивах. Притом в зависимости от ситуации — могут быть массивы структур или структуры массивов.

S>>·>Ну в общем если хочется померяться, то можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r16&amp;hw=ph&amp;test=json
S>>·>c# на 40-м месте, после питона?
S>>Ну, во-первых, там конкуренция высокая. Если мерить не в местах, а в процентах, то он медленнее лидера всего на 25%. Во-вторых, это как раз примерно то, о чём я говорил — нововведения ещё не доехали до результата.
·>Ну дык... Они догоняют. Но ведь остальыне платформы тоже не стоят на месте. Их тоже постоянно пилят. Вот в скорем времени и ValueType обещают в java, правда я не очень оптимистичен, сомневаюсь что это даст какой-то существенный прирост производительности. Оно, скорее всего, может лишь пригодится для упрощения _некоторого_ кода.

Это ж два угла зрения. Оно может и ускорить простой код и упростить быстрый Ну, то есть опять — в дотнете есть хорошая интеграция с unmanaged, а также могучий unsafe. Даже не выходя из C#, при помощи unsafe можно наворотить ада — лишь бы джит выдержал. Я вообще подозреваю, что там можно и джит обойти — к примеру, самостоятельно сгенерить целевой код, и принудительно вызвать его через какой-нибудь мегахак.
То есть для хардкора все эти нововведения — всего лишь способ легализовать то, что раньше было помечено "стоп! дальше — драконы!".
А в java как? Там же нет никакого ансейфа?

S>>Тот же кестрел ещё не использует ничего из новинок, ну и сериализация у нас опять-таки в UCS2, с последующей конверсией в UTF-8.
·>Поживём, увидим.
Отож. В интересное время живём

Здравствуйте, GarryIV, Вы писали:
GIV>Там еще у питона хороший % должен быть. Но вообще интересно, да. Вот торчит REST API, как определить на чем оно реализовано? Понятно что есть родимые пятна всякие но это все оочень не точно.
Хидеры респонсов много чего рассказывают.

·>Похохмить или правда интересно?

ни то, ни то
думаю, что картинка нерелевантна дискуссии
на релевантной php бы не было на этой позиции


p.s.
на втором месте там раст
пошел смотреть, как оно выглядит

#[allow(bad_style)]
какая милота

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

S>·>Тут ведь как... если хотим перформанс, то можно ведь наоборот — UCS2 в ASCII-7 конвертировать, притом только один раз, при старте приложения, а при обработке каждого конкретного запроса стремимся к zero-gc, zero-copy. Понятно, что таким образом универсальный всемогутер не написать, но различных средств достаточно, чтобы подпиливать под конкретные юзкейсы.
S>Простите, я тупой, мне непонятно — как это "UCS2 в ASCII-7 конвертировать, притом только один раз". То есть мы берём и превращаем "If-Modified-Since" в byte[]?
Ага, в момент запуска-конфигурирования сервака.

S>Но тогда нам нужны алгоритмы, позволяющие выполнять сравнения byte[] массивов с фрагментами буфера. Причём zero-copy.
java.nio.ByteBuffer#compareTo или аналоги из соответствующих библиотек.

S>Причём было бы ещё неплохо, чтобы сравнивалка умела не в цикле байтики крутить, а, скажем, сразу SIMD инструкциями.
Ну это задача разработчиков jvm и программистов: http://prestodb.rocks/code/simd/

S>То есть вся инфраструктура работы со строками выбрасывается и заменяется на инфраструктуру по работе с byte[].
Иногда да, в особо тяжелых случаях, веб скорее к ним не относится. Но если говорить о языке java, и платформе jvm, а не о стандартных jdk классах, которые стремятся быть универсальными всемогутерами, а потому не во всех сценариях оптимальны.

S>При этом, например, такая банальная вещь, как Slice (или Span<byte>) у нас в некотором смысле невозможна — ведь Value типов нет, поэтому объект, состоящий из "указатель на массив + смещение фрагмента + длина фрагмента" неизбежно создаёт нагрузку на GC.
Да стандартно, что-то типа:

ByteSlice getSomething(ByteSlice result)
{
  result.setData(this.internalBuffer, this.somethingOffset, this.somethingLen);
  return result;
}

Но это, понятное дело, хардкорный перформанс, для веба такое обычно перебор.
Плюс ещё java умеет escape analysis и объекты могут переноситься на стек или вообще быть eliminated а такого уже и хватает для многих случаев, в т.ч. и для веба.

S>И это мы ещё не упёрлись в то, что после двоеточия в if-modified-since должна идти дата, и нам нужна инфраструктура по парсингу даты из byte[], вместо стандартной библиотеки, которая умеет парсить только строки.
Нет, не только строки, например parse берёт на вход CharSequence, который может указывать напрямую в network buffer, и query, который может извлечь данные без создания новых объектов. Аналогично и formatTo умеет писать в Appendable.

S>Как это решили в Java? Напилили весь нижний уровень без строк?
Как-как... почесали бошки, да решили.

S>Ну, то есть вот в дотнете пацаны поняли, что упираются не столько в отсутствие библиотек, сколько в отсутствие возможности их написать. В итоге пришлось одновременно пилить CLR (для поддержки т.н. ref structs, чтобы иметь возможность безопасно манипулировать ссылками, не создающими GC Root), и джит — чтобы, к примеру, проверки выхода за диапазон устранялись не только для int[], но и для созданного на его основе Span<int>.
Осталось понять, что это действительно нужно и даёт какие-то преимущества в перформансе...

S>>>Ну, во-первых, там конкуренция высокая. Если мерить не в местах, а в процентах, то он медленнее лидера всего на 25%. Во-вторых, это как раз примерно то, о чём я говорил — нововведения ещё не доехали до результата.
S>·>Ну дык... Они догоняют. Но ведь остальыне платформы тоже не стоят на месте. Их тоже постоянно пилят. Вот в скорем времени и ValueType обещают в java, правда я не очень оптимистичен, сомневаюсь что это даст какой-то существенный прирост производительности. Оно, скорее всего, может лишь пригодится для упрощения _некоторого_ кода.
S>Это ж два угла зрения. Оно может и ускорить простой код и упростить быстрый Ну, то есть опять — в дотнете есть хорошая интеграция с unmanaged, а также могучий unsafe.
Фтопку unsafe — это жуткий костыль, создающий проблемы для кроссплатформенности и размаха оптимизаций jit.

S> Даже не выходя из C#, при помощи unsafe можно наворотить ада — лишь бы джит выдержал.
Насколько я понимаю, unsafe тупо ломает jit. Разве не так?

S>Я вообще подозреваю, что там можно и джит обойти — к примеру, самостоятельно сгенерить целевой код, и принудительно вызвать его через какой-нибудь мегахак.
Генерации байткода за глаза хватает почти на всё. А там где её не хватает, там уж наверное только C, asm, gpu, fpga.

S>То есть для хардкора все эти нововведения — всего лишь способ легализовать то, что раньше было помечено "стоп! дальше — драконы!".
S>А в java как? Там же нет никакого ансейфа?
к сожалению, есть sun.misc.Unsafe. Но его наконец-то решились выпилить в последних версиях jdk.

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

S>>Но тогда нам нужны алгоритмы, позволяющие выполнять сравнения byte[] массивов с фрагментами буфера. Причём zero-copy.
·>java.nio.ByteBuffer#compareTo или аналоги из соответствующих библиотек.

S>>Причём было бы ещё неплохо, чтобы сравнивалка умела не в цикле байтики крутить, а, скажем, сразу SIMD инструкциями.
·>Ну это задача разработчиков jvm и программистов: http://prestodb.rocks/code/simd/
Круто. Это будет получше System.Numerics!
S>>То есть вся инфраструктура работы со строками выбрасывается и заменяется на инфраструктуру по работе с byte[].
·>Иногда да, в особо тяжелых случаях, веб скорее к ним не относится. Но если говорить о языке java, и платформе jvm, а не о стандартных jdk классах, которые стремятся быть универсальными всемогутерами, а потому не во всех сценариях оптимальны.

S>>При этом, например, такая банальная вещь, как Slice (или Span<byte>) у нас в некотором смысле невозможна — ведь Value типов нет, поэтому объект, состоящий из "указатель на массив + смещение фрагмента + длина фрагмента" неизбежно создаёт нагрузку на GC.
·>Да стандартно, что-то типа:
·>

·>ByteSlice getSomething(ByteSlice result)
·>{
·>  result.setData(this.internalBuffer, this.somethingOffset, this.somethingLen);
·>  return result;
·>}
·>

·>Но это, понятное дело, хардкорный перформанс, для веба такое обычно перебор.
Вот если честно, то потихоньку этот подход начинает задалбывать. Я понимаю, что в реальной жизни мы часто имеем SLA на операцию в полчаса, и что бизнесу throughput милее, чем latency, но блин из-за этого мы имеем раздражающее поведение приложений. Там позади формочки стоит ферма из 200 серверов, каждый из которых в 10000 раз мощнее машинки, на которой в 1990 году пацаны рассчитывали профиль цунами по координатам вызвавшего её землетрясения.
И при этом комбобокс вываливается с ощутимой задержкой . Ну и веб сервисы тоже никто не отменял.

·>Плюс ещё java умеет escape analysis и объекты могут переноситься на стек или вообще быть eliminated а такого уже и хватает для многих случаев, в т.ч. и для веба.
S>>И это мы ещё не упёрлись в то, что после двоеточия в if-modified-since должна идти дата, и нам нужна инфраструктура по парсингу даты из byte[], вместо стандартной библиотеки, которая умеет парсить только строки.
·>Нет, не только строки, например parse берёт на вход CharSequence, который может указывать напрямую в network buffer, и query, который может извлечь данные без создания новых объектов. Аналогично и formatTo умеет писать в Appendable.
Да, вижу, домашняя работа сделана на отлично.

S>>Ну, то есть вот в дотнете пацаны поняли, что упираются не столько в отсутствие библиотек, сколько в отсутствие возможности их написать. В итоге пришлось одновременно пилить CLR (для поддержки т.н. ref structs, чтобы иметь возможность безопасно манипулировать ссылками, не создающими GC Root), и джит — чтобы, к примеру, проверки выхода за диапазон устранялись не только для int[], но и для созданного на его основе Span<int>.
·>Осталось понять, что это действительно нужно и даёт какие-то преимущества в перформансе...
Ну, это же всё не на голом месте. А в том числе и по результатам профилирования тех самых бенчмарков, на которых дотнет просасывает.

·>Фтопку unsafe — это жуткий костыль, создающий проблемы для кроссплатформенности и размаха оптимизаций jit.
Не, у unsafe особых проблем с кроссплатформой и джитом нету.

S>> Даже не выходя из C#, при помощи unsafe можно наворотить ада — лишь бы джит выдержал.
·>Насколько я понимаю, unsafe тупо ломает jit. Разве не так?
Нет конечно. Unsafe MSIL — точно такой же, что и "safe". Просто в CIL есть три вида типов: reference, value, и указатели. Вот вся работа с последними — это и есть unsafe.
При этом инструкции по работе с указателями — точно такой же абстрактный MSIL, не зависящий от платформы. И целевой код для них порождает по-прежнему тот же самый JIT. И вполне себе его оптимизирует; так что если мы пишем в C# что-то типа fixed(int* p = &myArray[0]) {s+= p[12];}, то вся арифметика с указателем сводится к одной команде косвенной загрузки.

S>>Я вообще подозреваю, что там можно и джит обойти — к примеру, самостоятельно сгенерить целевой код, и принудительно вызвать его через какой-нибудь мегахак.
·>Генерации байткода за глаза хватает почти на всё. А там где её не хватает, там уж наверное только C, asm, gpu, fpga.
Ну вот тут только C лишний. Дупа же там, где у нас какая-то штука неоптимально выполняется в плотном цикле. Если мы заменим эту неоптимальную штуку на вызов оптимальной штуки в натив, то в самом позитивном случае у нас маршалинг сожрёт на порядок больше ресурсов, чем мы сэкономим. А когда мы переносим в натив весь цикл, то теряем возможности по его оптимизации — типа constant propagation и прочих редукций.

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

·>к сожалению, есть sun.misc.Unsafe. Но его наконец-то решились выпилить в последних версиях jdk.
Надеюсь, не заменив на oracle.misc.Unsafe

Вижу, есть чему поучиться.

·>Во-первых, php написан на C++, и в том сравнении самого php кода там скорее всего нуль.
пошел, глянул. вижу вот что
это не вполне ноль
особенно учитывая рассуждения про zero-copy в этой теме

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

S>·>Но это, понятное дело, хардкорный перформанс, для веба такое обычно перебор.
S>Вот если честно, то потихоньку этот подход начинает задалбывать. Я понимаю, что в реальной жизни мы часто имеем SLA на операцию в полчаса, и что бизнесу throughput милее, чем latency, но блин из-за этого мы имеем раздражающее поведение приложений. Там позади формочки стоит ферма из 200 серверов, каждый из которых в 10000 раз мощнее машинки, на которой в 1990 году пацаны рассчитывали профиль цунами по координатам вызвавшего её землетрясения.
S>И при этом комбобокс вываливается с ощутимой задержкой . Ну и веб сервисы тоже никто не отменял.
У всех свои приоритеты. Если ты будешь комбобокс рассчитывать как цунами, то у бизнеса деньги закончатся и никому твоя профильная формочка не будет нужна.

Кстати, любопытно. Что сейчас с этими цунами происходит? За 40 лет оно уже не только профиль высчитывать должно на ардуинке, но где и когда каждая капелька упадёт и как это повлияет на рынок акций.

S>>>Ну, то есть вот в дотнете пацаны поняли, что упираются не столько в отсутствие библиотек, сколько в отсутствие возможности их написать. В итоге пришлось одновременно пилить CLR (для поддержки т.н. ref structs, чтобы иметь возможность безопасно манипулировать ссылками, не создающими GC Root), и джит — чтобы, к примеру, проверки выхода за диапазон устранялись не только для int[], но и для созданного на его основе Span<int>.
S>·>Осталось понять, что это действительно нужно и даёт какие-то преимущества в перформансе...
S>Ну, это же всё не на голом месте. А в том числе и по результатам профилирования тех самых бенчмарков, на которых дотнет просасывает.
А почему обычный inlining, escape analysis и object elimination не спасают?

S>>> Даже не выходя из C#, при помощи unsafe можно наворотить ада — лишь бы джит выдержал.
S>·>Насколько я понимаю, unsafe тупо ломает jit. Разве не так?
S>Нет конечно. Unsafe MSIL — точно такой же, что и "safe". Просто в CIL есть три вида типов: reference, value, и указатели. Вот вся работа с последними — это и есть unsafe.
S>При этом инструкции по работе с указателями — точно такой же абстрактный MSIL, не зависящий от платформы. И целевой код для них порождает по-прежнему тот же самый JIT. И вполне себе его оптимизирует; так что если мы пишем в C# что-то типа fixed(int* p = &myArray[0]) {s+= p[12];}, то вся арифметика с указателем сводится к одной команде косвенной загрузки.
А, понятно. Но, как мне кажется, это делает msil сильно разнообразнее и заковыристие чем byte code, а значит джитить его гораздо сложнее.

S>·>Генерации байткода за глаза хватает почти на всё. А там где её не хватает, там уж наверное только C, asm, gpu, fpga.
S>Ну вот тут только C лишний. Дупа же там, где у нас какая-то штука неоптимально выполняется в плотном цикле. Если мы заменим эту неоптимальную штуку на вызов оптимальной штуки в натив, то в самом позитивном случае у нас маршалинг сожрёт на порядок больше ресурсов, чем мы сэкономим. А когда мы переносим в натив весь цикл, то теряем возможности по его оптимизации — типа constant propagation и прочих редукций.
Так откуда плотные циклы в вебе? Но если ты в общем говоришь, то да — либо оптимизируем всё с редукциями под данную платформу, либо пишем универсальный код. Оптимизированный код никогда не бывает универсальным и красивым. По крайней мере, я такого не видел.

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

S>Но есть такое ощущение, что дотнетовый джит ещё и по разному оптимизирует код, загруженный из сборки, и код, порождённый динамически. Потому что у меня по бенчмаркам получилась чуть ли не двукратная разница на x64, и я пока не понимаю почему. На первый взгляд, нативный код там получается одинаковым с точностью до перестановки фрагментов (хотя я x64 ассемблер плохо читаю — мог чего-то не заметить). То ли там какой-то ещё трамплин исполняется для динамических методов, то ли всё же мелочи влияют на производительность.
Фиг знает, не очень представяю как оно там в дотнете. Может ngen какой-нибудь ещё что-то делает?

S>·>к сожалению, есть sun.misc.Unsafe. Но его наконец-то решились выпилить в последних версиях jdk.
S>Надеюсь, не заменив на oracle.misc.Unsafe
Нет, они полезное вынесли в официальный api. Но проблема-то всё равно есть — старые библиотеки, которые зависят от него просто перестанут работать, их надо будет патчить.

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

K>·>Во-первых, php написан на C++, и в том сравнении самого php кода там скорее всего нуль.
K>пошел, глянул. вижу вот что
K>это не вполне ноль
Именно, что полный ноль. Главное смотри этот кусок — две строчки собственно. Угадай на чём написан, например, json_encode или тот самый swoole http server. И сравни на чём написан тот же rapidoid.

K>особенно учитывая рассуждения про zero-copy в этой теме
Ну zero-copy это скорее не про веб, а про "быстрее". Хотя в том же rapidoid — байты/буферы повсюду.

Здравствуйте, ·, Вы писали:
·>У всех свои приоритеты. Если ты будешь комбобокс рассчитывать как цунами, то у бизнеса деньги закончатся и никому твоя профильная формочка не будет нужна.
Очень часто это не так. Под предлогом "у нас нет средств на оптимизацию" выбираются заведомо неудачные решения. Ну вот — в JDK, оказывается, парсинг даты работает с CharSequence. Что помешало Редмонду написать парсинг сразу используя IEnumerable<char>? На стоимость написания бы это не повлияло.

·>Кстати, любопытно. Что сейчас с этими цунами происходит? За 40 лет оно уже не только профиль высчитывать должно на ардуинке, но где и когда каждая капелька упадёт и как это повлияет на рынок акций.
Увы — я не в курсе.
S>>Ну, это же всё не на голом месте. А в том числе и по результатам профилирования тех самых бенчмарков, на которых дотнет просасывает.
·>А почему обычный inlining, escape analysis и object elimination не спасают?
Увы, не в курсе. Было принято вот такое архитектурное решение

·>А, понятно. Но, как мне кажется, это делает msil сильно разнообразнее и заковыристие чем byte code, а значит джитить его гораздо сложнее.
Да нет, там основная развесистость — за счёт shortcut-инструкций. Это вот тоже — идиотизм на марше: банальная zip-компрессия байт-кода даёт больше экономии, чем возможность записать команду "загрузить аргумент номер 2 в стек" одним байтом вместо пяти.

S>>Ну вот тут только C лишний. Дупа же там, где у нас какая-то штука неоптимально выполняется в плотном цикле. Если мы заменим эту неоптимальную штуку на вызов оптимальной штуки в натив, то в самом позитивном случае у нас маршалинг сожрёт на порядок больше ресурсов, чем мы сэкономим. А когда мы переносим в натив весь цикл, то теряем возможности по его оптимизации — типа constant propagation и прочих редукций.
·>Так откуда плотные циклы в вебе? Но если ты в общем говоришь, то да — либо оптимизируем всё с редукциями под данную платформу, либо пишем универсальный код. Оптимизированный код никогда не бывает универсальным и красивым. По крайней мере, я такого не видел.
Ну, весь веб — это парсинг и склейка строк. Как раз управляемые среды с их сверхпоздним связыванием и JIT способны превращать красивый универсальный код в оптимизированный.
Если в Java можно поправить .md файлы и улучшить джит для конкретной архитектуры, то в .Net JIT — это чёрный ящик, и если где-то он не справляется, хочется добиться эффекта вручную.

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

·>Фиг знает, не очень представяю как оно там в дотнете. Может ngen какой-нибудь ещё что-то делает?
Его я пока не пробовал, но чудес не ожидаю. Как правило, если какую-то оптимизацию можно сделать, то её делают сразу в джите.

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

S>·>У всех свои приоритеты. Если ты будешь комбобокс рассчитывать как цунами, то у бизнеса деньги закончатся и никому твоя профильная формочка не будет нужна.
S>Очень часто это не так. Под предлогом "у нас нет средств на оптимизацию" выбираются заведомо неудачные решения.
Есть ещё поговорка про преждевременную оптимизацию...

S>Ну вот — в JDK, оказывается, парсинг даты работает с CharSequence. Что помешало Редмонду написать парсинг сразу используя IEnumerable<char>? На стоимость написания бы это не повлияло.
Это не тот случай, ведь .net тупо содран с jdk (ключевое слово тут "тупо" ), а это конкретное место с java.text.DateFormat, там тоже String. java.time это относительно новый api и .net опять в догоняющих.

S>·>А, понятно. Но, как мне кажется, это делает msil сильно разнообразнее и заковыристие чем byte code, а значит джитить его гораздо сложнее.
S>Да нет, там основная развесистость — за счёт shortcut-инструкций. Это вот тоже — идиотизм на марше: банальная zip-компрессия байт-кода даёт больше экономии, чем возможность записать команду "загрузить аргумент номер 2 в стек" одним байтом вместо пяти.
Да это вряд ли что-то усложняет. Тем более это тоже содрано с jvm Там тоже есть инструкции типа "положить число 4 на стек".

S>·>Так откуда плотные циклы в вебе? Но если ты в общем говоришь, то да — либо оптимизируем всё с редукциями под данную платформу, либо пишем универсальный код. Оптимизированный код никогда не бывает универсальным и красивым. По крайней мере, я такого не видел.
S>Ну, весь веб — это парсинг и склейка строк. Как раз управляемые среды с их сверхпоздним связыванием и JIT способны превращать красивый универсальный код в оптимизированный.
S>Если в Java можно поправить .md файлы и улучшить джит для конкретной архитектуры, то в .Net JIT — это чёрный ящик, и если где-то он не справляется, хочется добиться эффекта вручную.
Да строки это не плотные циклы, а так, линейный перебор кучки байтиков, с таким даже php справляется. Плотные циклы это, скорее всего, про видеокодеки, архиваторы и прочие числодробилки.

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

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

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

S>>·>У всех свои приоритеты. Если ты будешь комбобокс рассчитывать как цунами, то у бизнеса деньги закончатся и никому твоя профильная формочка не будет нужна.
S>>Очень часто это не так. Под предлогом "у нас нет средств на оптимизацию" выбираются заведомо неудачные решения.
·>Есть ещё поговорка про преждевременную оптимизацию...

S>>Ну вот — в JDK, оказывается, парсинг даты работает с CharSequence. Что помешало Редмонду написать парсинг сразу используя IEnumerable<char>? На стоимость написания бы это не повлияло.
·>Это не тот случай, ведь .net тупо содран с jdk (ключевое слово тут "тупо" ), а это конкретное место с java.text.DateFormat, там тоже String. java.time это относительно новый api и .net опять в догоняющих.

S>>·>А, понятно. Но, как мне кажется, это делает msil сильно разнообразнее и заковыристие чем byte code, а значит джитить его гораздо сложнее.
S>>Да нет, там основная развесистость — за счёт shortcut-инструкций. Это вот тоже — идиотизм на марше: банальная zip-компрессия байт-кода даёт больше экономии, чем возможность записать команду "загрузить аргумент номер 2 в стек" одним байтом вместо пяти.
·>Да это вряд ли что-то усложняет. Тем более это тоже содрано с jvm Там тоже есть инструкции типа "положить число 4 на стек".

S>>·>Так откуда плотные циклы в вебе? Но если ты в общем говоришь, то да — либо оптимизируем всё с редукциями под данную платформу, либо пишем универсальный код. Оптимизированный код никогда не бывает универсальным и красивым. По крайней мере, я такого не видел.
S>>Ну, весь веб — это парсинг и склейка строк. Как раз управляемые среды с их сверхпоздним связыванием и JIT способны превращать красивый универсальный код в оптимизированный.
S>>Если в Java можно поправить .md файлы и улучшить джит для конкретной архитектуры, то в .Net JIT — это чёрный ящик, и если где-то он не справляется, хочется добиться эффекта вручную.
·>Да строки это не плотные циклы, а так, линейный перебор кучки байтиков, с таким даже php справляется. Плотные циклы это, скорее всего, про видеокодеки, архиваторы и прочие числодробилки.
Ну, так-то да. И тем не менее, мы видим, насколько хреново работает дотнет в банальной, казалось бы, задаче — выплюнуть JSON для примитивного значения. всё-таки 25% проигрыша лидерам — we could do better.

S>>·>Ну вот... делегаты ещё. А в байткоде ничего такого нет, поэтому там всё инлайнится и девиртуализируется, вне зависимости от.
S>>На самом деле делегаты — ничуть не хуже любого другого косвенного вызова. Просто было принято архитектурное решение, и всё — спекулятивной оптимизацией дотнет не занимается, увы.
·>А какие вообще оптимизации .net jit умеет?
https://github.com/dotnet/coreclr/blob/master/Documentation/botr/ryujit-overview.md
Из недавнего — https://blogs.msdn.microsoft.com/dotnet/2017/10/16/ryujit-just-in-time-compiler-optimization-enhancements/

Вообще, десятилетия назад в Редмонде по какой-то причине решили, что хотспоттинг — не нужен. То ли патенты там, то ли инженерные соображения — хз.
Типа, "если потребуется, то мы лучше запилим PGO". То есть нет ни инструментирования кода, ни повторных оптимизаций. Джит обрабатывает каждый кусок байт-кода не более одного раза.
Поэтому принимать решения типа "а давайте попробуем предположить, что CharSequence здесь — как правило, String", ему страшно — можно же ошибиться, исправить ошибку шанса не будет.
Да и оснований для такого предположения нет — всё, что он видит, это тупо байткод. А любой делегат — это гаратированная косвенность: там есть невиртуальный метод Invoke(), который бежит по списку из (Target,Method), и делает вызов неизвестно чего неизвестно на чём. Глядя в байткод, мы даже предположить не можем, что там окажется внутри. Вот джит и делает всё по честному — вызов так вызов. Заодно и соответствие типа Target сигнатуре Method проверяется всякий раз.

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

S>>>Ну, весь веб — это парсинг и склейка строк. Как раз управляемые среды с их сверхпоздним связыванием и JIT способны превращать красивый универсальный код в оптимизированный.
S>>>Если в Java можно поправить .md файлы и улучшить джит для конкретной архитектуры, то в .Net JIT — это чёрный ящик, и если где-то он не справляется, хочется добиться эффекта вручную.
S>·>Да строки это не плотные циклы, а так, линейный перебор кучки байтиков, с таким даже php справляется. Плотные циклы это, скорее всего, про видеокодеки, архиваторы и прочие числодробилки.
S>Ну, так-то да. И тем не менее, мы видим, насколько хреново работает дотнет в банальной, казалось бы, задаче — выплюнуть JSON для примитивного значения. всё-таки 25% проигрыша лидерам — we could do better.
Да как обычно. Продукты ms никогда не отличались умом и сообразительностью, его сила в маркетинге. "У нас есть блекджек и value types! Value types ведь значит что типа быстро!" Но вот _реально_ о производительности не подумали.

S>>>·>Ну вот... делегаты ещё. А в байткоде ничего такого нет, поэтому там всё инлайнится и девиртуализируется, вне зависимости от.
S>>>На самом деле делегаты — ничуть не хуже любого другого косвенного вызова. Просто было принято архитектурное решение, и всё — спекулятивной оптимизацией дотнет не занимается, увы.
S>·>А какие вообще оптимизации .net jit умеет?
S>https://github.com/dotnet/coreclr/blob/master/Documentation/botr/ryujit-overview.md
S>Из недавнего — https://blogs.msdn.microsoft.com/dotnet/2017/10/16/ryujit-just-in-time-compiler-optimization-enhancements/
"made the JIT recognize the Item property getters of Span" — это тупейший идиотизм. Вместо универсальных оптимизаций всего кода, чтобы в т.ч. быстро заработал и Span, они вставляют костыли в predefined-типы. Т.е. если я по каким-то своим причинам захочу запилить что-то очень похожее на Span, то оно не будет оптимизироваться.
Често говоря, я вообще не понимаю смысла такого jit. Если он пилится только для определённых типов, то почему бы их просто не реализовывать интринзиками компилятора или тупо вставкой нативных имплементаций методов данного типа?

S>Вообще, десятилетия назад в Редмонде по какой-то причине решили, что хотспоттинг — не нужен. То ли патенты там, то ли инженерные соображения — хз.
S>Типа, "если потребуется, то мы лучше запилим PGO". То есть нет ни инструментирования кода, ни повторных оптимизаций. Джит обрабатывает каждый кусок байт-кода не более одного раза.
Ну как бы путь выбран неверный, потому и результат такой.

S>Поэтому принимать решения типа "а давайте попробуем предположить, что CharSequence здесь — как правило, String", ему страшно — можно же ошибиться, исправить ошибку шанса не будет.
Uncommon trap же — один conditional jump, который очень дружественен к branch prediction.

S>Да и оснований для такого предположения нет — всё, что он видит, это тупо байткод. А любой делегат — это гаратированная косвенность: там есть невиртуальный метод Invoke(), который бежит по списку из (Target,Method), и делает вызов неизвестно чего неизвестно на чём. Глядя в байткод, мы даже предположить не можем, что там окажется внутри. Вот джит и делает всё по честному — вызов так вызов. Заодно и соответствие типа Target сигнатуре Method проверяется всякий раз.
Не понял причём тут байткод. Hotspot же тоже только байткод видит и оптимизирует.

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

S>>Ну, так-то да. И тем не менее, мы видим, насколько хреново работает дотнет в банальной, казалось бы, задаче — выплюнуть JSON для примитивного значения. всё-таки 25% проигрыша лидерам — we could do better.
·>Да как обычно. Продукты ms никогда не отличались умом и сообразительностью, его сила в маркетинге. "У нас есть блекджек и value types! Value types ведь значит что типа быстро!" Но вот _реально_ о производительности не подумали.
Ну, маркетинг у них как раз ниже плинтуса.

S>>Из недавнего — https://blogs.msdn.microsoft.com/dotnet/2017/10/16/ryujit-just-in-time-compiler-optimization-enhancements/
·>"made the JIT recognize the Item property getters of Span" — это тупейший идиотизм. Вместо универсальных оптимизаций всего кода, чтобы в т.ч. быстро заработал и Span, они вставляют костыли в predefined-типы. Т.е. если я по каким-то своим причинам захочу запилить что-то очень похожее на Span, то оно не будет оптимизироваться.
Отож.
·>Често говоря, я вообще не понимаю смысла такого jit. Если он пилится только для определённых типов, то почему бы их просто не реализовывать интринзиками компилятора или тупо вставкой нативных имплементаций методов данного типа?
Ну, часть так и сделана. Например, весь System.Numerics — это хак, с predefined types, отображаемыми на интринсики.

S>>Поэтому принимать решения типа "а давайте попробуем предположить, что CharSequence здесь — как правило, String", ему страшно — можно же ошибиться, исправить ошибку шанса не будет.
·>Uncommon trap же — один conditional jump, который очень дружественен к branch prediction.
Он имеет смысл только тогда, когда мы как правило угадываем. Если же у нас исполнение чаще бегает по ветке "ок, давайте сделаем косвенный вызов", то результат получается хуже, чем просто косвенный вызов. Ещё и размер метода увеличивается, уменьшая, в свою очередь, его шансы на встроенность.

S>>Да и оснований для такого предположения нет — всё, что он видит, это тупо байткод. А любой делегат — это гаратированная косвенность: там есть невиртуальный метод Invoke(), который бежит по списку из (Target,Method), и делает вызов неизвестно чего неизвестно на чём. Глядя в байткод, мы даже предположить не можем, что там окажется внутри. Вот джит и делает всё по честному — вызов так вызов. Заодно и соответствие типа Target сигнатуре Method проверяется всякий раз.
·>Не понял причём тут байткод. Hotspot же тоже только байткод видит и оптимизирует.
Нет. Хотспот видит частоты определённых стеков. Это профайлер, встроенный в JVM. Именно из его результатов джит вообще получает информацию о том, какие реально указатели могут оказаться в месте косвенного вызова. И насколько часто они встречаются относительно друг друга — и принять решение, какие из них инлайнить. А потом ещё и передумать — если статистика изменится, и частой станет другая ветка кода.
В дотнете вместо этого мы имеем PGO — см. https://msdn.microsoft.com/en-us/magazine/mt683795.aspx
Там упоминается dynamic MPGO, который по описанию аналогичен джавовскому хотспоту, но я про него знаю чуть меньше, чем ничего.
Судя по комментам в https://github.com/dotnet/coreclr/issues/4331, автор просто соврал.
Его статья вышла в марте 2016, а в июле 2017 Andy Ayers пишет:

Making MPGO-style feedback data available when jitting is certainly an option (currently we can only read this data back when prejitting). There are various limits to what can be instrumented, so not all methods can be handled this way, there are other limitations we need to look at (for instance, no feedback data is available for inlinees), the instrumentation and training runs needed to create the MPGO data are a barrier to for many users, and the MPGO data may or may not match up with what we'd have when bootstrapping off the first tier, but the idea certainly has merit.

То есть через год хотспоттинг всё ещё в неопределённом будущем.

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

S>·>Да как обычно. Продукты ms никогда не отличались умом и сообразительностью, его сила в маркетинге. "У нас есть блекджек и value types! Value types ведь значит что типа быстро!" Но вот _реально_ о производительности не подумали.
S>Ну, маркетинг у них как раз ниже плинтуса.
Без этого .net вообще бы не взлетел.

S>Ну, часть так и сделана. Например, весь System.Numerics — это хак, с predefined types, отображаемыми на интринсики.
Мде.

S>>>Поэтому принимать решения типа "а давайте попробуем предположить, что CharSequence здесь — как правило, String", ему страшно — можно же ошибиться, исправить ошибку шанса не будет.
S>·>Uncommon trap же — один conditional jump, который очень дружественен к branch prediction.
S>Он имеет смысл только тогда, когда мы как правило угадываем. Если же у нас исполнение чаще бегает по ветке "ок, давайте сделаем косвенный вызов", то результат получается хуже, чем просто косвенный вызов. Ещё и размер метода увеличивается, уменьшая, в свою очередь, его шансы на встроенность.
А на чём он основывает предположения, если нет профайлера?

S>>>Да и оснований для такого предположения нет — всё, что он видит, это тупо байткод. А любой делегат — это гаратированная косвенность: там есть невиртуальный метод Invoke(), который бежит по списку из (Target,Method), и делает вызов неизвестно чего неизвестно на чём. Глядя в байткод, мы даже предположить не можем, что там окажется внутри. Вот джит и делает всё по честному — вызов так вызов. Заодно и соответствие типа Target сигнатуре Method проверяется всякий раз.
S>·>Не понял причём тут байткод. Hotspot же тоже только байткод видит и оптимизирует.
S>Нет. Хотспот видит частоты определённых стеков. Это профайлер, встроенный в JVM. Именно из его результатов джит вообще получает информацию о том, какие реально указатели могут оказаться в месте косвенного вызова. И насколько часто они встречаются относительно друг друга — и принять решение, какие из них инлайнить. А потом ещё и передумать — если статистика изменится, и частой станет другая ветка кода.
Ну да. А почему нет профайлера в .net?

S>В дотнете вместо этого мы имеем PGO — см. https://msdn.microsoft.com/en-us/magazine/mt683795.aspx
Ну pgo в яве тоже есть — Excelsior и Zing ReadyNow. Правда оно реально нужно только в особо тяжелых случаях.
Кстати, Java AOT (jaotc) как-то совершенно незамеченно зарелизился уж год назад в Java 9.

S>То есть через год хотспоттинг всё ещё в неопределённом будущем.
Мде.

Здравствуйте, ·, Вы писали:
·>Без этого .net вообще бы не взлетел.
Нупрям. Я в другой раз расскажу своё мнение. Вкратце: маркетинг у дотнета как раз никакой.

S>>Ну, часть так и сделана. Например, весь System.Numerics — это хак, с predefined types, отображаемыми на интринсики.
·>Мде.
·>А на чём он основывает предположения, если нет профайлера?
А он их не делает. Я же говорю — встраиваются только невиртуальные вызовы
S>>·>Не понял причём тут байткод. Hotspot же тоже только байткод видит и оптимизирует.
S>>Нет. Хотспот видит частоты определённых стеков. Это профайлер, встроенный в JVM. Именно из его результатов джит вообще получает информацию о том, какие реально указатели могут оказаться в месте косвенного вызова. И насколько часто они встречаются относительно друг друга — и принять решение, какие из них инлайнить. А потом ещё и передумать — если статистика изменится, и частой станет другая ветка кода.
·>Ну да. А почему нет профайлера в .net?
"Было принято такое архитектурное решение". Я, к сожалению, свечку не держал.

·>Ну pgo в яве тоже есть — Excelsior и Zing ReadyNow. Правда оно реально нужно только в особо тяжелых случаях.
·>Кстати, Java AOT (jaotc) как-то совершенно незамеченно зарелизился уж год назад в Java 9.
Ну, а в дотнете AOT был с самого начала — если мы про ngen.

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

S>Хидеры респонсов много чего рассказывают.

Это если нет reverse proxy. А оно в современных облачных сервисах есть примерно всегда, ибо LB.

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

T>Но вот интересно, никто не пытался сделать сайт с одинаковым функционалом на java и на c#.

Пытались. https://www.microsoft.com/en-us/download/details.aspx?id=16693
Джавовские варианты для разных фреймворков и аппсерверов найдешь сам.

T>И сравнить их производительность на приблизительно одной нагрузке и затраты на разработку приблизительно одинаково оплачиваемыми программистами.
T>Так сказать, провести A,B анализ....

Не получится. Потому что разработать сайт одинакового функционала на одинаковую загрузку дальше набившего оскомину ToDo-списка не получится: слишком дорогое удовольствие. Синтетические бенчмарки идут лесом все.

В итоге все решает time-to-market и возможность взлетать вместе с ростом проекта (если он есть). Вон, Инстаграмм до сих пор, вроде, на Django крутится, и ничо.

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

GIV>Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.

Дотнет давно доступен под *nix

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

S>На практике, пока что мы имеем всё это счастье в продакшн-качестве всего лишь с марта месяца, поэтому прикладного кода, который мог бы воспользоваться преимуществами C#7.3 и .Net Core 2.1, пока что в природе не существует.

А прикладному оно зачем? Kestrel же вполне умеет.

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

S>Тот же кестрел ещё не использует ничего из новинок

Использует. Просто в тестах наверняка старая версия.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А прикладному оно зачем? Kestrel же вполне умеет.
Это хорошо. Но бенчмарки на кестреле по-преждему сливают — надо полагать, Json сериализатор тормозит.

Здравствуйте, Ночной Смотрящий, Вы писали:

GIV>>Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.

НС>Дотнет давно доступен под *nix

Там про джаву было, мастер цитирования. Тем не менее дотнет на линуксе тоже не нужен, хотя бесспорно есть, да.

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

GIV>>>Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.
НС>>Дотнет давно доступен под *nix
GIV>Там про джаву было, мастер цитирования.

Т.е. это джава винду требует?

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

НС>>А прикладному оно зачем? Kestrel же вполне умеет.
S>Это хорошо. Но бенчмарки на кестреле по-преждему сливают — надо полагать, Json сериализатор тормозит.

Возможно. Но непонятно какая версия кестрела там. Да и сериализатор там не от МС, а нуллсофтовский.

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

Tiered Compilation
В .NET Core 2.2 Preview 2 is tiered comilation включен по умолчанию

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

S>Если у вас всё хорошо, то 90% ответов — это как раз 304.

Это или для статических/файловых данных, которые обслуживает нейтивный HTTP-сервак еще до того, как будет вызван дотнетный плагин-хендлер, или всё-равно придётся сначала залезть в базу, например, чтобы убедиться, что сообщение в форуме не было изменено.

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

S>А в java как? Там же нет никакого ансейфа?

Там много JNI.
Вот один из лидеров по тому рейтингу:
https://github.com/wizzardo/epoll/blob/master/src/main/c/com/wizzardo/epoll/EpollCore.c

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

S>·>Фиг знает, не очень представяю как оно там в дотнете. Может ngen какой-нибудь ещё что-то делает?
S>Его я пока не пробовал, но чудес не ожидаю. Как правило, если какую-то оптимизацию можно сделать, то её делают сразу в джите.

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

Просто речь о разных культурах.
В дотнете берут технологии "изкаробки", потому что считается, что и так быстродействие приемлимое.
Это так и есть.
Джавовское "изкаробки" в том рейтинге будет ближе к хвосту, ес-но.

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

Как раз тоже этим занят в последние месяцы на .Net Core, результаты вполне.
Но так-то да, коллекции, парсинг сетевого потока, оперирование "отрезками" байт в памяти — всё это ручками и в полный рост, плюс последние фреймворковые Span<>, Sequence<>, Memory<> и т.д. неплохо помогают. И всё это без всяких использований массивов байт для "умозрительной" разметки памяти на джавовский манер (это вообще какая-то жесть) — в дотнете то же самое можно делать на вэлью-типах и в unsafe с вполне человеческой типизацией.

Здравствуйте, vdimas, Вы писали:
V>Это или для статических/файловых данных, которые обслуживает нейтивный HTTP-сервак еще до того, как будет вызван дотнетный плагин-хендлер, или всё-равно придётся сначала залезть в базу, например, чтобы убедиться, что сообщение в форуме не было изменено.
Не обязательно. Никто не мешает нам иметь кэш в памяти, который держит недавние запросы.

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

S>Ну, так-то да. И тем не менее, мы видим, насколько хреново работает дотнет в банальной, казалось бы, задаче — выплюнуть JSON для примитивного значения. всё-таки 25% проигрыша лидерам — we could do better.

Ну так можно портировать джавовский код на дотнет и обогнать.
Вопрос — а нужно ли?
Если уже "изкаробки" идёт вплотную к "миллиону ручных приседаний", это показатель, однако.

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

S>Никто не мешает нам иметь кэш в памяти, который держит недавние запросы.

В случае масштабирования врать не будет? ))

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

V>В случае масштабирования врать не будет? ))
Смотря как сделать
На самом деле основная экономия будет, по идее, как раз на всяких парсерах. Для форматтеров надо бы посмотреть точный профайл, что куда девается. Есть подозрение, что там тоже дофига всего теряется на преобразования UCS2->UTF8 и копирования строк.

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

S>>А в java как? Там же нет никакого ансейфа?
V>Там много JNI.
V>Вот один из лидеров по тому рейтингу:
V>https://github.com/wizzardo/epoll/blob/master/src/main/c/com/wizzardo/epoll/EpollCore.c
"Много" это ты громко заявил. Всего строк ~700, по сравнению с остальным кодом на java — копейки. И имя файла как бы намекает, что это тонкая обёртка над системным вызовом epoll, честно говоря, не понял зачем, начиная с java7 оно вроде уже встроено, афаир. Например, у лидера rapidoid и того нет, чистая java.

А если посмотреть на тот же kestrel, то там unsafe и native везде пестрит, по поводу и без повода.

V>Ну так можно портировать джавовский код на дотнет и обогнать.
Код бессмысленно портировать. Надо jit портировать... и в лучшем случае догнать. Ибо обгонять не на чем.

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

V>Джавовское "изкаробки" в том рейтинге будет ближе к хвосту, ес-но.
К хвосту, это где? Если чё, изрядно архаичный, тупой, жирный, overengineered стандартный Servlet API на 23 месте, а вылизанный kestrel — на 40 месте.

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

V>>Джавовское "изкаробки" в том рейтинге будет ближе к хвосту, ес-но.
·>К хвосту, это где? Если чё, изрядно архаичный, тупой, жирный, overengineered стандартный Servlet API на 23 месте, а вылизанный kestrel — на 40 месте.

Это всё прилагательные из разряда оценочных суждений.
Тем более, что Сервлет АПИ в прошлом году был зарелизен почти с 0-ля.

В общем, для объективности сравнивать надо идентичный код, а по ссылке сравнивается разный.

Помнится, ты так и не смог в прошлые разы привести джавовский код, который при портировании на дотнет стал бы медленнее.
И сейчас не сможешь, ес-но.

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

·>К хвосту, это где? Если чё, изрядно архаичный, тупой, жирный, overengineered стандартный Servlet API на 23 месте, а вылизанный kestrel — на 40 месте.

Так, посмотрел внимательней, Servlet API крутится поверх Resin-сервера.
Самых свежих сырцов Резина по-быстрому не нашёл, но в тех, что нашел, опять никакого чуда не произошло:
https://github.com/mdaniel/svn-caucho-com-resin/tree/master/modules/c/src
JNI в полный рост.
"Вылизанный kestrel" — полностью managed.

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

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

V>>>Джавовское "изкаробки" в том рейтинге будет ближе к хвосту, ес-но.
V>·>К хвосту, это где? Если чё, изрядно архаичный, тупой, жирный, overengineered стандартный Servlet API на 23 месте, а вылизанный kestrel — на 40 месте.
Блин, ошибся. Сервлеты там 9 месте...

V>Это всё прилагательные из разряда оценочных суждений.
Ну правда же — туда сюда столько всего приходится конвертить и копировать — и собственно всё только ради универсальности, чтобы можно было запускать в разных контейнерах.

V>Тем более, что Сервлет АПИ в прошлом году был зарелизен почти с 0-ля.
В каком месте с нуля?! И что конкретно там касается перформанса?

V>В общем, для объективности сравнивать надо идентичный код, а по ссылке сравнивается разный.
Ну продемонстрируй идентичный код коду лидера.

V>Помнится, ты так и не смог в прошлые разы привести джавовский код, который при портировании на дотнет стал бы медленнее.
А я пытался или хотя бы обещал?

V>И сейчас не сможешь, ес-но.
Почему это меня должно беспокоить?

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

GIV>Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.

Так делают только очень неумные системные дизайнеры. Ну или просто профнепригодные
У нас например 90% всей инфраструктуры поддержки производства на винсерверах, а в цехах почти 100% процесса производства управляется под разными версиями винды.

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

V>·>К хвосту, это где? Если чё, изрядно архаичный, тупой, жирный, overengineered стандартный Servlet API на 23 месте, а вылизанный kestrel — на 40 месте.
V>Так, посмотрел внимательней, Servlet API крутится поверх Resin-сервера.
V>Самых свежих сырцов Резина по-быстрому не нашёл, но в тех, что нашел, опять никакого чуда не произошло:
V>https://github.com/mdaniel/svn-caucho-com-resin/tree/master/modules/c/src
V>JNI в полный рост.
А ты посмотри повнимательней — коннекторы к frontend серверам — apache, isapi, обёртка вокруг win32 sendfile и подобное. Вряд ли что-то из этого используется в бенчмарке.

V>"Вылизанный kestrel" — полностью managed.
libuv. А тут вообще смешно... число в строчку безопасно сконвертировать не могут...

V>В общем, в угол, на гречку, тщательно думать над своим поведением.
Да ладно... не переживай ты так, зачем такое самоистязание?

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

V>>https://github.com/wizzardo/epoll/blob/master/src/main/c/com/wizzardo/epoll/EpollCore.c
·>"Много" это ты громко заявил. Всего строк ~700, по сравнению с остальным кодом на java — копейки.

А по сравнению с остальным кодом, который влияет на бенчмарк?

·>А если посмотреть на тот же kestrel, то там unsafe и native везде пестрит, по поводу и без повода.

А что с unsafe то не так? То что его на джаве нет?

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

S>>Никто не мешает нам иметь кэш в памяти, который держит недавние запросы.
V>В случае масштабирования врать не будет? ))

Для такого придуманы всякие редисы.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>>https://github.com/wizzardo/epoll/blob/master/src/main/c/com/wizzardo/epoll/EpollCore.c
НС>·>"Много" это ты громко заявил. Всего строк ~700, по сравнению с остальным кодом на java — копейки.
НС>А по сравнению с остальным кодом, который влияет на бенчмарк?
Тоже копейки. В любом случае, у лидера, rapidoid, нативного кода нет. Это просто vdimas, как обычно, подбирает удобные факты.

НС>·>А если посмотреть на тот же kestrel, то там unsafe и native везде пестрит, по поводу и без повода.
НС>А что с unsafe то не так? То что его на джаве нет?
Using unsafe code introduces security and stability risks.

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

НС>>А что с unsafe то не так? То что его на джаве нет?
·>Using unsafe code introduces security and stability risks.

Ну это уж как использовать.

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

V>>JNI в полный рост.
·>А ты посмотри повнимательней — коннекторы к frontend серверам — apache, isapi, обёртка вокруг win32 sendfile и подобное. Вряд ли что-то из этого используется в бенчмарке.

Сам посмотри повнимательней:
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/common/stream.c
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/resin_os/jni_os.c
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/resin_os/jni_socket.c
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/resin_os/std.c

— вообще весь IO нейтивный;
— управление буферами памяти нейтивное;
— даже нейтивное управление процессами/демонами и общение с ними.


V>>"Вылизанный kestrel" — полностью managed.
·>libuv.

И ты достоверно знаешь, что используется это:
https://github.com/aspnet/KestrelHttpServer/blob/master/src/Kestrel.Transport.Libuv/Internal/LibuvConnection.cs
а не это:
https://github.com/aspnet/KestrelHttpServer/blob/master/src/Kestrel.Transport.Sockets/Internal/SocketConnection.cs
?

·>тут вообще смешно... число в строчку безопасно сконвертировать не могут...

По ссылкам для Резина такого навалом.

С другой стороны, возможно некий рудимент, бо сегодня можно и без указателей:

    struct Chars13
    {
        public fixed char Data[13];
    }

Пояснять надо?
Как тебе такое?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>А что с unsafe то не так? То что его на джаве нет?
НС>·>Using unsafe code introduces security and stability risks.
НС>Ну это уж как использовать.
Ну а накой тогда вообще заморачиваться с этим всем managed?

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>>Никто не мешает нам иметь кэш в памяти, который держит недавние запросы.
V>>В случае масштабирования врать не будет? ))
НС>Для такого придуманы всякие редисы.

Или можно простой нейтивный HTTP-прокси на входе поставить.

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

Здесь нужно смотреть и на перспективы. Сейчас развивается .Net Core а вместе с ним много внимание уделяется и скорости.
В том числе и .Net Native который применяется в UWP и ilcpp https://blogs.unity3d.com/ru/2015/05/06/an-introduction-to-ilcpp-internals/
http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT/

https://github.com/dotnet/corert

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

НС>>Ну это уж как использовать.
·>Ну а накой тогда вообще заморачиваться с этим всем managed?

unsafe обычно в коде очень не много. Прям как те 700 строк JNI. Только, в отличие от JNI, оно остается по прежнему типизированным, кроссплатформенным, и не требует танцев с бубном.

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

V>Или можно простой нейтивный HTTP-прокси на входе поставить.

Можно. Такое, правда, сейчас сильно непопулярно.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну это уж как использовать.
НС>·>Ну а накой тогда вообще заморачиваться с этим всем managed?
НС>unsafe обычно в коде очень не много. Прям как те 700 строк JNI. Только, в отличие от JNI, оно остается по прежнему типизированным, кроссплатформенным, и не требует танцев с бубном.
Unsafe бы не помог. Тот упомянутый JNI как раз обёртка над платформоспецифичным API epoll, который в jre появился не сразу, в современных имплементациях сетевых приложений и тут JNI уже не нужен.

Ещё насколько я знаю, в java серверах используется нативный SSL/TLS (в бенчмарке вроде оно не участвует). А у .net managed версия есть?

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

.NET Core we have changed the default transport in Kestrel from libuv to sockets

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

GIV>>Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.

K>Так делают только очень неумные системные дизайнеры. Ну или просто профнепригодные
Угу, а потом пляшут с бубном когда надо в кубернейтис все это запихать.

K>У нас например 90% всей инфраструктуры поддержки производства на винсерверах, а в цехах почти 100% процесса производства управляется под разными версиями винды.
У вас вроде не джава или я ошибаюсь? И расскажи чем обусловлен выбор ОС в вашем случае.

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

·> А у .net managed версия есть?

С рождения.

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

V>.NET Core we have changed the default transport in Kestrel from libuv to sockets

Вот как раз благодаря тем самым Span<T> сотоварищи.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·> А у .net managed версия есть?
НС>С рождения.
Эээ... Хкм.

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

НС>>·> А у .net managed версия есть?
НС>>С рождения.
·>Эээ... Хкм.

И? То что есть обертка для нативных реализаций не означает отсутствия managed.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>·> А у .net managed версия есть?
НС>>>С рождения.
НС>·>Эээ... Хкм.
НС>И? То что есть обертка для нативных реализаций не означает отсутствия managed.
Да я не это имел в виду. То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.

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

·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.

Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.
НС>Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.
Я не знаю что там используется. Нагуглил в моно это, в коре это. А ты почему решил что managed имплементация используется? Может, наверное, и используется как fallback если нативное не смогло завестись на некой платформе. И работает пусть тормозно, но работает.

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

НС>>·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.
НС>>Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.
·>Я не знаю что там используется.

Кто бы сомневался.

·> А ты почему решил что managed имплементация используется?

Потому что netstandard подразумевает работу под разными платформами.

·> Может, наверное, и используется как fallback если нативное не смогло завестись на некой платформе. И работает пусть тормозно, но работает.

Что еще нафантазируешь? Вот исходники, можешь посмотреть как оно на самом деле.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.
НС>>>Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.
НС>·>Я не знаю что там используется.
НС>Кто бы сомневался.
А почему я должен знать? Ты говорить стесняешься, а то что я нахожу — сомнений не оставляет.

НС>·> А ты почему решил что managed имплементация используется?
НС>Потому что netstandard подразумевает работу под разными платформами.
И что? jdk тоже подразумевает работу под разными платформами. Это не значит, что там всё манагед.

НС>·> Может, наверное, и используется как fallback если нативное не смогло завестись на некой платформе. И работает пусть тормозно, но работает.
НС>Что еще нафантазируешь? Вот исходники, можешь посмотреть как оно на самом деле.
Так я смотрел и увидел CurlHandler. Да и файлы с суффиксами Windows, Unix, OSX. А ты что там видишь?