хотел бы задать вопрос экзистенциальный
сам я джава / С++ (но С++ это скорее только про boost) гай.
вы сказали — "если надо получить стабильное решение задачи и быстро то современный шарп имеет сотню очков форы". в чем это проявляется?
jvm явный признанный лидер по scalability / perf. и новые языки вроде kotlin позволяют ускорить разработку. в чем смысл си щарпа в таком случае?
Здравствуйте, a_g_99, Вы писали:
__>вы сказали — "если надо получить стабильное решение задачи и быстро то современный шарп имеет сотню очков форы". в чем это проявляется? __>jvm явный признанный лидер по scalability / perf. и новые языки вроде kotlin позволяют ускорить разработку. в чем смысл си щарпа в таком случае?
Котлин более маргинальный, чем Ява. На скале пишут PHD, которых ещё надо найти. На clojure пишут марсиане. На обычную Яву вы найдёте опытных жителей Бангалора.
Остаётся только C#, если конечно не рассматривать всякие там питоны, а их лучше не рассматривать.
Здравствуйте, Слава, Вы писали:
С>Котлин более маргинальный, чем Ява. На скале пишут PHD, которых ещё надо найти. На clojure пишут марсиане. На обычную Яву вы найдёте опытных жителей Бангалора.
На C# в Бангалоре сейчас готовят на порядок больше.
С>Остаётся только C#, если конечно не рассматривать всякие там питоны, а их лучше не рассматривать.
Кроме питона идёт новая волна с полдесятка интересных языков.
Здравствуйте, a_g_99, Вы писали:
__>hi_octane
__>хотел бы задать вопрос экзистенциальный __>сам я джава / С++ (но С++ это скорее только про boost) гай.
__>jvm явный признанный лидер по scalability / perf. и новые языки вроде kotlin позволяют ускорить разработку. в чем смысл си щарпа в таком случае?
1.
А сколько латенси у await в джаве на старом ксеоне 2 Ггц? В .NET — одна микросекунда вот в таком коде:
var y = await Task.Run(() => 42);
В джаве хоть есть такой синтакс в 2020м году?
2.
А JIT в джаве умеет SSE/AVX на ксеонах и NEON на армах? .NET Core 3.1 LTS умеет на ксеонах, а .NET Core 5.0 preview умеет и NEON на армах.
ускорение там в 3+ раза примерно. Причем .NET коре можно юзать и Explicit SIMD инструкции и встроенные древние функции тоже их умеет. Плюс есть Vector<T> который тоже умеет причем не нужно самому ничего выдумывать.
Здравствуйте, VladCore, Вы писали:
VC>В джаве хоть есть такой синтакс в 2020м году?
в котлине есть корутины если вы про них. при этом тк котлин на jvm он в полной мере поддерживает hotspot оптимизации
VC>2. VC>А JIT в джаве умеет SSE/AVX на ксеонах и NEON на армах? .NET Core 3.1 LTS умеет на ксеонах, а .NET Core 5.0 preview умеет и NEON на армах.
конечно умеет. jvm поддерживает AVX в полной мере. вы угораете надо мной что ли ?
Здравствуйте, VladCore, Вы писали:
VC>2. VC>А JIT в джаве умеет SSE/AVX на ксеонах и NEON на армах? .NET Core 3.1 LTS умеет на ксеонах, а .NET Core 5.0 preview умеет и NEON на армах.
Улыбнуло. Эту фишку от C# рекламировали с самой первой версии, типа оно будет само оптимизироваться при запуске на целевой платформе под эту самую платформу. Неужели только-только появилось? Тогда это провал.
__>jvm явный признанный лидер по scalability / perf.
Я бы тут разделил jvm и scalability / perf. Многие проекты написанные на java очень аккуратно и hardware-friendly долгое время являлись эталоном того как относительно кросс-платформенный и высокоуровневый код, может при этом показывать высокую производительность. Были версии jvm "заточенные" под определённые сценарии, которые позволяли выжать ещё больше. Но этот высокопроизводительный код не является "красивым" или написанным "с использованием всех фишек языка". Чаще всего это c-like код, с минимумом выделений памяти, пулами для часто используемых типов объектов, и т.п. Да такое работает быстро, но никакого отношения к jvm не имеет. Так аккуратно можно писать практически на любом языке. Но это нифига не "скоренько накидать, лишь бы работало".
Также врождённые проблемы jvm (отсутствие value-типов, "неправильные" generic'и) — становятся кандалами, замедляющими развитие и возможности оптимизации скомпилированного кода. Их пытаются решить тем же project Valhalla, но до самого решения ещё далеко, до его mass adoption ещё дольше, обновления существующих библиотек которые могут получить выигрыш в performance придётся ждать наверное до 2030-го.
Современный высокопроизводительный код тоже делится на пару составляющих — возможность писать числодробильный код, и возможность писать эффективный многопоточный код.
В .NET сама парадигма async/await и стандарт использования Task<T> появились очень давно. Соответственно вся экосистема, все открытые или внутренние проекты используют одно и то-же tasks api. И как раз оно каждый релиз вылизывается всё больше и больше. Тоже есть какие-то родовые проблемы, которые, видимо, останутся навсегда. Но бьющих именно по производительности относительно мало закопайте делегаты!.
К примеру ни kotlin ни java вообще насколько я понимаю, не позволяют писать, alloc-free асинхронный код на future/task. В современном .NET это ещё с приседаниями, но уже можно делать. Более того, можно написать библиотеку которая будет отдавать клиенту alloc-free tasks, и при этом клиент сможет её использовать вообще не заметив отличий от обычной.
Для числодробильного кода в C# тоже очень много всего добавили. Но если это расписывать, получится уже не пост на форуме, а какая-то статья.
__>и новые языки вроде kotlin позволяют ускорить разработку. в чем смысл си щарпа в таком случае?
Небольшой знаток kotlin, но когда смотрел его последний раз — например вменяемого linq там не было. Функции map, filter, и т.п. я вменяемым linq не считаю. Т.е. по сравнению с java kotlin явно ускоряет разработку, а сравнивая с C# — большой вопрос. Многие вещи которые в C# можно закрыв глаза на оптимизацию сделать "лишь бы работало", тоже отсутствуют, например dynamic (для jvm).
Также по отзывам тех с кем работал (сам на kotlin не пишу, опять же) у kotlin есть свои корутины (и они вроде даже быстрее встроенных в JVM). Но при этом возникают сложности когда нужная библиотека для jvm вроде бы есть, но написана давно и на java. Соответственно использует устаревшие подходы к многопоточности, встроенный или даже самописные аналоги Future (для той самой performance), и т.п. В общем использовать можно, но уже не так удобно.
В scala сахара позволяющего писать продуктивный код больше, но из-за особенностей самой scala код написанный со всеми плюшками — после компиляции очень часто безумно неоптимален и создаёт огромный memory traffic на временных объектах. То есть high perf код без оглядки на "во что оно там развернётся-то?" не напишешь.
__>вы сказали — "если надо получить стабильное решение задачи и быстро то современный шарп имеет сотню очков форы". в чем это проявляется?
Долгое время программируя на C#, как и на других языках, был некий tradeoff. Что-то типа "тут используем весь доступный синтаксический сахар, пусть тормозит, но что-то зарелизим уже завтра" vs "тут надо заморочиться, вспомнить кучу глав из Writing High Perf .NET Code, и потом профайлером".
Последние годы команда .NET Core старательно подкручивает и оптимизирует даже между major релизами, так что на оптимизации можно забить всё чаще, и всё чаще встречаются случаи когда старые паттерны оптимизации больше не дают эффекта.
Собственно в той же теме
я писал, что один из проектов мы начинали по сути как PoC. Изначально идея была разбить на части которые можно будет потом независимо дооптимизировать к релизу. Первую редакцию написать самым скоростным и простым образом. Получить некий эталон, на котором гонять юнит и интеграционные тесты. А потом доводить до ума компоненты по одному. И времени было заложено соответственно. Но случилось так что этот самый концепт-код выдал нужные скорость и стабильность сразу. Учитывая объёмы траффика которые через него проходят каждую секунду, и то как это было написано, такого тупо не должно было быть.
Одновременно с этим в C# постоянно добавляют ништяки для микро-оптимизаций. Т.е. если понадобится ускорить раза в 2 — то вполне есть понимание что делать. И это всё ещё будет читабельный и типизированный C#.
Здравствуйте, a_g_99, Вы писали:
VC>>В джаве хоть есть такой синтакс в 2020м году? __>в котлине есть корутины если вы про них. при этом тк котлин на jvm он в полной мере поддерживает hotspot оптимизации
VC>>2. VC>>А JIT в джаве умеет SSE/AVX на ксеонах и NEON на армах? .NET Core 3.1 LTS умеет на ксеонах, а .NET Core 5.0 preview умеет и NEON на армах. __>конечно умеет. jvm поддерживает AVX в полной мере. вы угораете надо мной что ли ?
повторюсь про performance
А сколько латенси у await в джаве на старом ксеоне 2 Ггц? В .NET — одна микросекунда вот в таком коде:
var y = await Task.Run(() => 42);
p.s. я кажется понял почему ты не понимаеш вопрос. java похоже не умеет вычислять типы. тогда тот же сымый код без type infrerrence выглядит так:
Здравствуйте, VladCore, Вы писали:
VC>повторюсь про performance
VC>А сколько латенси у await в джаве на старом ксеоне 2 Ггц? В .NET — одна микросекунда вот в таком коде: VC>var y = await Task.Run(() => 42);
А зачем это вообще мерять?
Ну да, явовский компилятор не умеет резать функции на куски по границе await (точнее, он вообще await не знает). Но кто ставит такие короткие задачи в асинхронное выполнение и зачем?
Здравствуйте, netch80, Вы писали:
VC>>повторюсь про performance
VC>>А сколько латенси у await в джаве на старом ксеоне 2 Ггц? В .NET — одна микросекунда вот в таком коде: VC>>var y = await Task.Run(() => 42);
N>А зачем это вообще мерять? N>Ну да, явовский компилятор не умеет резать функции на куски по границе await (точнее, он вообще await не знает). Но кто ставит такие короткие задачи в асинхронное выполнение и зачем?
Здравствуйте, VladCore, Вы писали:
N>>А зачем это вообще мерять? N>>Ну да, явовский компилятор не умеет резать функции на куски по границе await (точнее, он вообще await не знает). Но кто ставит такие короткие задачи в асинхронное выполнение и зачем?
VC> не вижу смайликов
Здравствуйте, hi_octane, Вы писали:
_>Современный высокопроизводительный код тоже делится на пару составляющих — возможность писать числодробильный код, и возможность писать эффективный многопоточный код.
Можно пару нововведений и оптимизации для числодробилок? Речь о языке(сахаре) или о CLR?
Здравствуйте, hi_octane, Вы писали:
_>Более того, можно написать библиотеку которая будет отдавать клиенту alloc-free tasks, и при этом клиент сможет её использовать вообще не заметив отличий от обычной.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, hi_octane, Вы писали:
_>>Современный высокопроизводительный код тоже делится на пару составляющих — возможность писать числодробильный код, и возможность писать эффективный многопоточный код.
S>Можно пару нововведений и оптимизации для числодробилок? Речь о языке(сахаре) или о CLR?
F>Имеется в виду ValueTask?
Скорее связка IValueTaskSource + ValueTask. Ну и вроде для облегчения этой задачи был добавлен ManualResetValueTaskSourceCore но ещё не смотрел как у него с аллокациями
Здравствуйте, a_g_99, Вы писали:
VC>>А JIT в джаве умеет SSE/AVX на ксеонах и NEON на армах? .NET Core 3.1 LTS умеет на ксеонах, а .NET Core 5.0 preview умеет и NEON на армах. __>конечно умеет. jvm поддерживает AVX в полной мере.
JVM то умеет, вопрос в том можешь ли ты написать свой код на java с использованием AVX.
не вижу смайликов — так что читай: https://en.wikipedia.org/wiki/Latency_(engineering)#Computer_hardware_and_operating_system_latency
