Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>И точно так же на структурах в C/C++, сюрприз
_>В C++ же нет разницы между структурами и классами. Т.е. ты можешь ввести многоуровневую иерархию агрегации, причём каждый её элемент может быть членом сложной иерархии наследования и всё это вместе внесёт ровно нулевую косвенность (ну если использовать для агрегации контейнеры, то будет +1 уровень косвенности, но это всё равно даже близко не сравнимо с теми ужасами, что происходят в Java/C# в аналогичных случаях).
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Ikemefula, Вы писали:
I>>Этого мало. В джаве эти фокусы сделаны по причине кроссплатформенности в ущерб производительности. В дотнете прямо противоположное решние. Собственно если ты запилишь простейший цикл на массиве, нативный код уже даст выигрыш. Чем сложнее логика — тем больше будет отрыв нативного решения.
N>Ты судишь по отчётам о супероптимизациях каких-нибудь memcpy за счёт фишек конкретного набора инструкций?
Я говорю о другом — менеджед это сначала в 100-1000 замедление, а потом частичная компенсация за счет джыта.
N>А дальше уже начинает играть роль алгоритмическая оптимизация — например, в Java quicksort partitioning это dual-pivot, а в GCC STL — introsort с выбором по тупой медиане и неуправляемой левосторонней рекурсией, соответственно, свалиться в плохой случай ей в разы легче.
И где я пишу, что надо брать исключительно алгоритм цельно тянутый из STL ?
I>>Выиграть у нейтива можно только за счет смены самого алгоритма, заточить скажем версию под джыт, гц и тд, N>Dual pivot не имеет никакой связи с JIT или GC
Dual pivot реализуем на С++ или нет ?
I>> если нет проблем с локальностью. И то, на плюсах всего лишь увеличится сложность решения. Принципиально же любой менеджед супер-пупер алгоритм можно ускорить за счет нейтива.
N>И опять ты игнорируеш важность оптимизации в рантайме.
см выше, про компенсацию. Обработка видео, надеюсь, уже целиком перешла на джаву ? Нет ? А как же оптимизации в рантайме ?
Здравствуйте, netch80, Вы писали:
I>>Это враньё. Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код.
N>"Это враньё" ((c) Ikemefula). Перепахиванию RAM пофиг нативность кода, до тех пор, пока интерпретатор хоть как-то разумен — даже самый тупой JIT тут даёт достаточный результат.
Разумности интерпретатора мешает время на принятие решений. В компайлтайм компилер может хоть час думать. У джыта этого фокуса нет.
I>> У тебя даже тупой проход по массиву интов на сишном коде даст вопиющую разницу. N>Не даст.
А даёт.
I>>Если речь про перформанс, то он обязан быть самым лучшим, а не просто внятным. У джавы перформанс никогда не был на первом месте. У ней на первом месте кроссплатформенность, менеджед со своими плюшками. Все что угодно, но не перформанс. I>>Хочешь перформанс — есть только Си и тот без плюсов.
N>С чего это без плюсов?
А их никто толком и не знает, кроме нескольких реликтов из 90х
Здравствуйте, alex_public, Вы писали:
_>Твои рассуждения конечно верны, но в глубокой теории, а на практике всё наоборот. Если рассуждать абстрактно, то подобные платформы (работающие под управлением ВМ, типа jvm, clr, многие скриптовые языки) могут обходить по быстродействию любые нативные языки, потому что имеют возможность применить все их статические оптимизации и потом ещё добавить к ним кучу своих рантаймовых. Именно так обычно и рассуждают пропагандисты данных технологий. Однако нас, практиков, интересуют не их влажные фантазии о счастливом будущем, а текущая суровая реальность. Так вот в данный момент на практике все компиляторы подобных платформ не обеспечивают даже половины мощнейших статических оптимизации (работающих по дефолту скажем во всех основных компиляторах C++) и добавляют при этом всего одну-две слабенькие рантайм оптимизации. В итоге на практике Java/C# (про скриптовые и не говорим) отстаёт от аналогичного C++ кода в разы. https://benchmarksgame.alioth.debian.org/u64q/java.html
В "разы", конечно, не стоит так уверенно заявлять. Тут в среднем отставание раза в 1.5-2. Притом, как я вижу, java код там написан вообще без каких-либо забот о перформансе и это простой main(), без всякого прогрева (т.е. шанса выполнить все оптимизации до начала замеров).
Если же потратить немного усилий для оптимизации, то разницу можно свести к десятку процентов, а то и уровнять, вплоть до точности измерений.
Единственное что в managed языках плохо, что количество потребляемой памяти будет всегда больше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
N>>>Ему не нравится, что сравнивают реализации с нативным кодом против чисто VMовских. I>>А по моему он не понимает аргумент про закрытые и открытые технологии.
N>А что тут закрытого-то? Любимый vdimas’ом C++/CLI?
Вообще всё. Как результат — зависимость от одного единственного вендора.
I>>Еще раз — дотнет до недавних пор был прибит гвоздями к винде. N>Чиво? Mono, Unity3D — уже много лет как. Да, это малая часть, но как раз соответственно обсуждаемому тут основному движку.
Так вот откуда у vdimas jpeg пополам с ордерами — люди пилят LL трединг на Unit3D !
I>> Следовательно, без винды ты никак его использовать не можешь. Следовательно, в HFT будут видны проблемы не только дотнета, но и винды.
N>Если бы дотнет был так выгоднее для HFT сам по себе — было бы полно реализаций на Mono вместо Java. Mono никогда не имел необходимости затачиваться под винду и ограничиваться виндой (хотя идиотизм, зашитый в стандарты, подбил и его).
Моно всерьез никто не воспринимает. Это набор проблем.
N>Java тоже не имеет HFT основной тематикой.
У меня только за углом три конторы которые исключительно этим и занимаются Не владею статистикой, но почти все джависты работают во всяких финансовых, биржевых проектах. Как то так.
Здравствуйте, netch80, Вы писали:
N>>>Про не прибегая к offheap это подтасовка. Я как раз говорил, что offheap — один из методов решения. I>>Я тебя попросил показать _другой_ способ для этой же задачи. Например — твой прогрев.
N>Вообще-то и он реально работает — после того, как прогрев сделан, и принудительный GC выполнен, отсутствие последующих аллокаций приводит к тому, что GC не запускается в течение всего времени работы биржи. Самое сложное было таки устранить все аллокации даже не выходящие за пределы 0-го поколения — вот тут пришлось доработать offheap’ом.
То есть, в качестве способа отличного от offheap ты привел пример offheap Попробуй все таки без offheap работать с миллиардом объектов. Хочешь — прогревай, хочешь, не прогревай.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Что значит не будет обрезком? На Линухе заработает WPF? В какой из тех ссылок про это сказано? S>> Уже работает. Ты хоть ссылки читаешь? S>>https://blogs.msdn.microsoft.com/dotnet/2016/09/14/the-week-in-net-net-core-1-0-1-on-net-with-peachpie-avalonia-folk-tale/ S>> Смотри avalonia
_>По ссылке вижу упоминание новой GUI библиотеки (avalonia, сейчас в состояние альфа релиза) для .net, в этот раз кроссплатформенной. Само по себе это конечно же позитивное явление (будет, когда выйдет из состояния альфы), только причём тут WPF? )
А WPF прибит гвоздями к Windows
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, netch80, Вы писали:
I>>Ты сам спросил а я тебе рассказал про string и array. В дотнете полно таких оптимизаций и это одна из проблем. Оптимизации вполне обоснованы — сишный компилер при ряде условий может выдать и на порядок лучший результат, нежели самый лучший менеджед код.
N>Именно что "при ряде условий". Проблемка в том, что эти условия обычно не воспроизводятся в реальности. N>А вот JIT бьёт именно на то, что оказывается важнее всего в реале, например: N>1. Устранение всех лишних проверок. Не просто написать код, чтобы процессор по умолчанию какой-то переход считал unlikely, такое и в C делается влёт (особенно с хелперами типа __builtin_expect), а вообще устранить развилку. N>У Куксенко был показательный пример: в коде надо проверять if (x != null), и до прогрева null ни разу не встретился — JIT делает использование x безусловным, а на не случившийся до того вариант null — проверка заложена в хэндлере SIGSEGV. N>В C++ это нереализуемо — какая-то проверка стоит на десятом уровне косвенности в шаблонах N>2. Развиртуализация. У некоторого интерфейса встречаются всего 2-3 класса реализации, причём один чаще всего — в JIT версии вызова виртуального метода делается проверка базового класса (причём удешевлённая) и вызов по уже известному адресу. N>3. Оптимальность не под средний по больнице процессор на момент выхода программы, а под конкретный. И не надо говорить, что JIT не успеет такое — см. хотя бы генератор LLVM из IR, он вполне быстрый, а эти методы в отрасли известны задолго до LLVM.
И когда уже Джава вытеснит плюсы из обработки видео, звука, изображений ?
Здравствуйте, Ikemefula, Вы писали:
_>>В их офисном конечно не надо. Мы же не про клиринговые центры и т.п. процессинг говорим, а про "энтерпрайзные формочки". Кстати, а вот про ПО в клиринговых центрах тоже было бы интересно разузнать (скажем у Visa или MasterCard), на чём оно написано — там то как раз производительность вполне актуальна. I>Я говорю про процессинг.
Процессинг — в смысле платежи по карте?
В Visa — на Java всё, конечно. И даже — ужас — spring и hibernate (хотя для 2011 года — ожидаемо, новее данных не нашел).
В MasterCard подробностей не нашел, но судя по позиции тоже Java.
А что ещё могло быть? С++ или, упаси господи, dotnet?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>На уровне байткода никаких дженериков и делегатов нет, JIT-у пофиг что инлайнить. Компаратор такой же класс, имплементирующий интерфейс, как и всё остальное. S>> В том чиле и метод. Это касается прежде всего int, byte, Int64 где вызов метода 1+1, значительно дольше самого сложения, сравнения ·>Что "метод"? Имплементировать интерфейс — значит написать имплементацию метода(ов) этого интерфейса. После девиртуализации вызова Comparator.compare станет доступным тело метода для инлайнинга.
Вот кстати для примера посмотри на stackalloc для классов и какое оно дает ускорение. http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/
S>>>> То есть ты сравнивал мобильниках на java 5 и 6 с .Net Native? S>>·>Нет, не сравнивал. Я вообще с мобильниками дела не имею. Но я бы удивился, если бы джава отстала по перформансу. S>> Для мобильных платформ там совсем другие VM. ·>И что? Они медленнее .net что-ли?
Не знаю. Я лишь, говорю о том, что .Net Native может использовать более продвинутую компиляцию в машинный код
и не зависит от установленного .Net Core S>>>> Угу. Весь мир Андроида сидит на java 5 или как раз с 6. S>>·>Какая разница кто на чём сидит? Комбинации, однако: dotnet vs java 2016-2020. S>> То есть VM для вех версий одна? Да и андроидов разных полно. ·>Что? Почему? Ты о чём?
Я про мобильные устройства говорю, а ты мне ссылки для декстопа. S>>>>·>И компилятор тоже есть, для особо страждущих. https://www.excelsiorjet.com/ S>>>> Еще раз смотрим версию, и вспоминаем на чем народ на Андроид до сих пор сидит S>>·>https://www.excelsior-usa.com/jetdladdon.php?jetversion=700 S>> А где Андроид? Мы то говорим про мобильные платформы. .Net Native выгоден прежде всего для мобильных устройств. ·>Так для андроида ART есть, я же говорил уже, можно тупо локально dex2oat запускать для генерации бинарика.
Еще раз это аналог .NGEN. Он мало, что дает. И оптимизации для андроид версии там скорее всего нет, ибо батарея будет садиться быстро.
Как .NET Native влияет на вашу работу и на ваше приложение?
Результаты вашей работы скорее всего будут варьироваться, но в большинстве случаев ваше приложение будет запускаться и выполняться быстрее, а также использовать меньше системных ресурсов. Вы можете ожидать до 60% прироста скорости первого запуска приложения и до 40% при последующих запусках («теплых» запусках). Ваши приложения будут потреблять меньше памяти после компиляции в «родной» машинный код. Все зависимости от исполняющей среды .NET удаляются, поэтому конечным пользователям никогда не придется прерывать установку вашего приложения для получения специфической версии .NET Framework, на которую оно ссылается. По сути, все зависимости от .NET упаковываются в ваше приложение, поэтому его поведение не должно меняться просто потому, что на машину устанавливается другая версия .NET Framework.
Хотя ваше приложение компилируется в неуправляемые двоичные файлы, вы все равно можете использовать преимущества .NET-языков, к которым вы привыкли (C# или Visual Basic), и превосходные инструменты, связанные с ними. Наконец, вы можете по-прежнему применять всеобъемлющую и согласованную модель программирования, доступную благодаря .NET Framework с богатыми API для прикладной логики, встроенного управления памятью и обработки исключений.
За счет .NET Native вы получаете лучшее из двух миров: управляемой разработки и C++ с его колоссальной производительностью. Неплохо, да?
Вот такие маркетинговые речи!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
_>>>В их офисном конечно не надо. Мы же не про клиринговые центры и т.п. процессинг говорим, а про "энтерпрайзные формочки". Кстати, а вот про ПО в клиринговых центрах тоже было бы интересно разузнать (скажем у Visa или MasterCard), на чём оно написано — там то как раз производительность вполне актуальна. I>>Я говорю про процессинг. ·>Процессинг — в смысле платежи по карте? ·>В Visa — на Java всё, конечно. И даже — ужас — spring и hibernate (хотя для 2011 года — ожидаемо, новее данных не нашел).
Здравствуйте, Serginio1, Вы писали:
S>>> В том чиле и метод. Это касается прежде всего int, byte, Int64 где вызов метода 1+1, значительно дольше самого сложения, сравнения S>·>Что "метод"? Имплементировать интерфейс — значит написать имплементацию метода(ов) этого интерфейса. После девиртуализации вызова Comparator.compare станет доступным тело метода для инлайнинга. S> Вот кстати для примера посмотри на stackalloc для классов и какое оно дает ускорение. S>http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/
ну опять же "ускорение по сравнению с dotnet" же. В Яве же есть escape analysis, который может разместить объект на стеке, если объект не покидает некий scope.
S>>> Для мобильных платформ там совсем другие VM. S>·>И что? Они медленнее .net что-ли? S> Не знаю. Я лишь, говорю о том, что .Net Native может использовать более продвинутую компиляцию в машинный код S>и не зависит от установленного .Net Core
Так java тоже может использовать.
S>·>Что? Почему? Ты о чём? S> Я про мобильные устройства говорю, а ты мне ссылки для декстопа.
Какие ссылки для десктопа? Я говорю, что идея компилировать в натив-бинарники для девайсов на серверах магазина — плохомасштабируемая идея. Это ещё может работать для Яблок, их всего около десятка версий, притом только две-три активные. А для андроида — упс.
S>>>·>https://www.excelsior-usa.com/jetdladdon.php?jetversion=700 S>>> А где Андроид? Мы то говорим про мобильные платформы. .Net Native выгоден прежде всего для мобильных устройств. S>·>Так для андроида ART есть, я же говорил уже, можно тупо локально dex2oat запускать для генерации бинарика. S> Еще раз это аналог .NGEN. Он мало, что дает. И оптимизации для андроид версии там скорее всего нет, ибо батарея будет садиться быстро.
.net native делается с целью убрать зависимость от fw (который изначально был непереносимым и неотъемлимым компонентом системы, засунутый по самые гланды), а производительность за счёт чего? (ну кроме как за счёт исправления косяков ngen).
Цели убрать такую зависимость в ART нет, поэтому сделали именно так.
Компиляторы java->native были, есть и будут если понадобится. Каких-то принципиальных проблем их использовать — нет.
Я, кстати, много лет назад использовал GCJ, чтобы собрать из java-кода standalone (в смысле без каких либо зависимостей) dll.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Твои рассуждения конечно верны, но в глубокой теории, а на практике всё наоборот. Если рассуждать абстрактно, то подобные платформы (работающие под управлением ВМ, типа jvm, clr, многие скриптовые языки) могут обходить по быстродействию любые нативные языки, потому что имеют возможность применить все их статические оптимизации и потом ещё добавить к ним кучу своих рантаймовых. Именно так обычно и рассуждают пропагандисты данных технологий. Однако нас, практиков, интересуют не их влажные фантазии о счастливом будущем, а текущая суровая реальность. Так вот в данный момент на практике все компиляторы подобных платформ не обеспечивают даже половины мощнейших статических оптимизации (работающих по дефолту скажем во всех основных компиляторах C++) и добавляют при этом всего одну-две слабенькие рантайм оптимизации. В итоге на практике Java/C# (про скриптовые и не говорим) отстаёт от аналогичного C++ кода в разы. ·>https://benchmarksgame.alioth.debian.org/u64q/java.html ·>В "разы", конечно, не стоит так уверенно заявлять. Тут в среднем отставание раза в 1.5-2. Притом, как я вижу, java код там написан вообще без каких-либо забот о перформансе и это простой main(), без всякого прогрева (т.е. шанса выполнить все оптимизации до начала замеров). ·>Если же потратить немного усилий для оптимизации, то разницу можно свести к десятку процентов, а то и уровнять, вплоть до точности измерений. ·>Единственное что в managed языках плохо, что количество потребляемой памяти будет всегда больше.
Говоришь максимум в 2 раза разница и потратив немного усилий её можно свести к десятку процентов? ) Ну-Ну)
можно увидеть упрощённую сводную табличку результатов. Там же есть ссылка на Java код данного теста (меньше 20 строчек) — покажешь как этот простенький примерчик довести до уровня быстродействия C++? )))
Здравствуйте, Ikemefula, Вы писали:
N>>Вообще-то и он реально работает — после того, как прогрев сделан, и принудительный GC выполнен, отсутствие последующих аллокаций приводит к тому, что GC не запускается в течение всего времени работы биржи. Самое сложное было таки устранить все аллокации даже не выходящие за пределы 0-го поколения — вот тут пришлось доработать offheap’ом.
I>То есть, в качестве способа отличного от offheap ты привел пример offheap
То есть, я не приводил и даже не собирался приводить такого способа, а все идеи, что я должен был его привести — твои фантазии и капризы. Я говорил, что это таки реально используется для фактического отключения GC без его отрезания. Ровно это и ни слова больше.
I> Попробуй все таки без offheap работать с миллиардом объектов. Хочешь — прогревай, хочешь, не прогревай.
Со стандартным GC даже пробовать не хочу. И пока не определено, какой компромисс мы ищем между постоянными и пиковыми затратами.
Здравствуйте, ·, Вы писали:
S>>>>·>https://www.excelsior-usa.com/jetdladdon.php?jetversion=700 S>>>> А где Андроид? Мы то говорим про мобильные платформы. .Net Native выгоден прежде всего для мобильных устройств. S>>·>Так для андроида ART есть, я же говорил уже, можно тупо локально dex2oat запускать для генерации бинарика. S>> Еще раз это аналог .NGEN. Он мало, что дает. И оптимизации для андроид версии там скорее всего нет, ибо батарея будет садиться быстро. ·>.net native делается с целью убрать зависимость от fw (который изначально был непереносимым и неотъемлимым компонентом системы, засунутый по самые гланды), а производительность за счёт чего? (ну кроме как за счёт исправления косяков ngen).
Ее основное отличие от текущей реализации в том, что IL2CPP компилятор преобразует сборки в исходный код C++. Затем он использует стандартный компилятор C++ для данной платформы, чтобы создать родные двоичные файлы.
Код выполняется одновременно с дополнительными службами (вроде сборщика мусора, метаданных, специфичных для платформы ресурсов), которые обеспечивает IL2CCP VM.
Преимущества IL2CPP
Давайте рассмотрим каждую из вышеупомянутых сложностей и то, как как с ней справляется IL2CPP.
Производительность
В IL2CPP мы стремимся совместить простоту использования и скорость написания кода со производительностью C++.
С ним мы можем сохранить скорость текущего процесса написания скриптов и дополнить ее моментальным повышением производительности. Мы видели 2-3-кратное увеличение скорости выполнения некоторых наших тестов со сложными скриптами. Такой прирост производительности возникает по нескольким причинам:
— Компиляторы и компоновщики C++ дают нам большое количество ранее недоступных методов оптимизации.
— Ваш код подвергается статическому анализу и на скорость и на размер
— Unity-ориентированные оптимизации среды выполнения скриптов
И хотя работа над IL2CPP еще далека от завершения, этот ранний прирост производительности однозначно указывает на большое будущее нашего проекта.
·>Цели убрать такую зависимость в ART нет, поэтому сделали именно так. ·>Компиляторы java->native были, есть и будут если понадобится. Каких-то принципиальных проблем их использовать — нет.
·>Я, кстати, много лет назад использовал GCJ, чтобы собрать из java-кода standalone (в смысле без каких либо зависимостей) dll.
Еще раз есть кроссплатформенный .Net Core, который кстати позволяет работать только с используемыми библиотеками. https://habrahabr.ru/post/311520/ и не зависить от Фреймворка. Так что твои умозаключения об зависимости от фреймвока нет.
Главное скорость, расход батареи, обфускация.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
N>>Именно что "при ряде условий". Проблемка в том, что эти условия обычно не воспроизводятся в реальности. N>>А вот JIT бьёт именно на то, что оказывается важнее всего в реале, например:
[...]
I>И когда уже Джава вытеснит плюсы из обработки видео, звука, изображений ?
Не знаю, надо на конкретные кодеки и реализации смотреть. Везде, где реализация это не C-оболочка вокруг ассемблера — шансы неплохие.
Здравствуйте, Serginio1, Вы писали:
_>>По ссылке вижу упоминание новой GUI библиотеки (avalonia, сейчас в состояние альфа релиза) для .net, в этот раз кроссплатформенной. Само по себе это конечно же позитивное явление (будет, когда выйдет из состояния альфы), только причём тут WPF? ) S> А WPF прибит гвоздями к Windows
Ну если это так (кстати не уверен, но разбираться нет никакого желания), то это соответственно означает, что все эти .net core и т.п. обречены быть обрезками. Т.к. WPF — это официально часть .net.
Здравствуйте, Ikemefula, Вы писали:
N>>>>Ему не нравится, что сравнивают реализации с нативным кодом против чисто VMовских. I>>>А по моему он не понимает аргумент про закрытые и открытые технологии. N>>А что тут закрытого-то? Любимый vdimas’ом C++/CLI? I>Вообще всё. Как результат — зависимость от одного единственного вендора.
Ну, в данном случае MS сделала (в своём понимании, конечно) всё, чтобы такой зависимости не было. Ну что понимание кривое — ну а как иначе ;(
I>>>Еще раз — дотнет до недавних пор был прибит гвоздями к винде. N>>Чиво? Mono, Unity3D — уже много лет как. Да, это малая часть, но как раз соответственно обсуждаемому тут основному движку. I>Так вот откуда у vdimas jpeg пополам с ордерами — люди пилят LL трединг на Unit3D !
Хм. Интересная гипотеза. Честно говоря, я бы даже не удивился, если оно окажется действительно так.
I>>> Следовательно, без винды ты никак его использовать не можешь. Следовательно, в HFT будут видны проблемы не только дотнета, но и винды. N>>Если бы дотнет был так выгоднее для HFT сам по себе — было бы полно реализаций на Mono вместо Java. Mono никогда не имел необходимости затачиваться под винду и ограничиваться виндой (хотя идиотизм, зашитый в стандарты, подбил и его). I>Моно всерьез никто не воспринимает. Это набор проблем.
Так что тут первично? Что он набор проблем или что его всерьёз не воспринимает? Мне кажется, что таки первое — следствие второго, а второе — совместный результат репутаций MS и Иказы плюс наличие Java без тяжёлого наследия.
N>>Java тоже не имеет HFT основной тематикой. I>У меня только за углом три конторы которые исключительно этим и занимаются Не владею статистикой, но почти все джависты работают во всяких финансовых, биржевых проектах. Как то так.
Верю. В локальный концентрат. Но у меня вокруг сейчас в этом только моя контора, но не остальные видимые джависты.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>По ссылке вижу упоминание новой GUI библиотеки (avalonia, сейчас в состояние альфа релиза) для .net, в этот раз кроссплатформенной. Само по себе это конечно же позитивное явление (будет, когда выйдет из состояния альфы), только причём тут WPF? ) S>> А WPF прибит гвоздями к Windows
_>Ну если это так (кстати не уверен, но разбираться нет никакого желания), то это соответственно означает, что все эти .net core и т.п. обречены быть обрезками. Т.к. WPF — это официально часть .net.
Это не часть, а библиотека. Вместо WPF используется XAML
см выше, про компенсацию. Обработка видео, надеюсь, уже целиком перешла на джаву ? Нет ? А как же оптимизации в рантайме ?
Не владею статистикой, но почти все джависты работают во всяких финансовых, биржевых проектах. Как то так.
