Здравствуйте, ·, Вы писали:
V>>А у меня есть весьма активно наполняемая система баг-трекинга конторы с кучей программеров. Там за несколько лет ни одной ошибки выхода за границы массива, зато куча типичных логических ошибок. И на динамическом коде их намного больше, ес-но. ·>И с памятью никаких проблем не было? Утечек не было?
Утечки вообще не в кассу, так как возможны и в управляемых языках
Здравствуйте, Evgeny.Panasyuk, Вы писали:
N>>И, чем дальше отличается задача от мейнстрима вбивания инструкций в конвейеры процессора — тем менее важна вылизанность нативности. На партиционировании в quicksort слишком много сравнений, чтобы нативность что-то дала. EP>Даст не нативность, а меньшее количество индерекций в сортируемых массивах, инлайнинг компараторов и итераторов.
Про компараторы — почти согласен — по крайней мере если C++ std::sort, а не, например, C qsort (говорю это потому, что некоторые товарищи тут доказывали, что C++ тоже не годится). "Почти" — потому что любой современный явовский JIT сейчас умеет инлайнить небольшие блоки кода, и компаратор тут тоже может попасть в работу.
Для Java тут может потребоваться финт, обратный type erasure, но если мы говорим, как раньше в треде, про сортировку int[], то там и компаратор тривиальный, и доступ.
Индирекции же никуда не денутся, если не начинать менять по-умному структуры данных. Оптимизаторы C/C++ на это не способны, кроме банальных случаев типа "complex разместим в двух FP регистрах".
N>>А дальше уже начинает играть роль алгоритмическая оптимизация — например, EP>Старые песни о главном — "ничего что всё тормозит, зато на алгоритмах вас заборем"
Я ни слова про "ничего, что всё тормозит" не говорил, обсуждай это с кем-нибудь другим.
N>>в Java quicksort partitioning это dual-pivot, EP>Это который Arrays.sort(int[])? Конечно сортировать прибитые гвоздями int'ы за average O(N * log(N)) — это повод для алгоритмической гордости, прям забороли-перебороли
По-моему, он там везде, а не только на intʼах.
N>>а в GCC STL — introsort с выбором по тупой медиане и неуправляемой левосторонней рекурсией, соответственно, свалиться в плохой случай ей в разы легче.
EP>Худший случай у introsort это O(N*log(N))
С постоянным коэффициентом в 3 раза больше нормального quicksort.
EP>А у Arrays.sort на Java какая-то расплывчатая формулировка EP>
EP>This algorithm offers O(n log(n)) performance on many data sets
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>Это враньё. Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код. N>>"Это враньё" ((c) Ikemefula). Перепахиванию RAM пофиг нативность кода, до тех пор, пока интерпретатор хоть как-то разумен — даже самый тупой JIT тут даёт достаточный результат.
EP>Ему ой как не пофиг на лишние косвенности и скачки по памяти, которыми пестрит весь управляемый код.
Неуправляемый тоже. Это проблема структур данных, а не необходимости явного delete.
EP> Собственно поэтому и извращаются на байт-буферах чтобы эти самые косвенности пересилить
Да. Или на структурах, в дотнете. И будут точно так же на структурах в Java 9.
И точно так же на структурах в C/C++, сюрприз
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ты с каким конкретно тезисом в моей фразе не согласен? С тем что оно недавно появилось? Или с тем, что это обрезок от полноценного .net'a? Поясни, а то из твоего потока ссылкок и т.п. совершенно не понятна твоя мысль. S>> Откуда ты взял про нестабильный? Во вторых я тебе дал ссылку, где в скором времени он уже не будет обрезком и сейчас достаточно, для того, что бы писать кроссплатформенные приложения. В отличие не от обрезка, который прибит к Windows. Он то как раз и неполноценный.
_>Что значит не будет обрезком? На Линухе заработает WPF? В какой из тех ссылок про это сказано?
Уже работает. Ты хоть ссылки читаешь? 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/
Смотри avalonia
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>>> То что в яблоках используется только натив. ·>Хорошая гипотеза, но требует доказательств.
S>>·>В общем случае — не значит. JIT может иногда давать лучший код, т.к. ему доступно реальная информация времени исполнения. AOT — этого может и не знать. Скажем, типичный пример — virtual call elimination — если используется единственная имплементация виртуальной функции во время работы приложения, то JIT может выкинуть косвенный вызов. AOT — такой информацией просто не обладает. S>> Угу на мобильных то устройствах? Там большинство до сих пор сидит на Java 6. ·>Да этому уж много лет, думаю с java 5 или как раз с 6. ·>Но даже если и так, интересно, что быстрее появится на мобильниках — java 8 или .net native?
Это касается Java/ На IPhone и WinMo .net native есть. S>> А вот что касается инлайнинга и прочих оптимизаций то тут никакой оптимизатор лучше не сделает. ·>inline тоже делается. Притом после virtual call elimination. Круто ведь — возможность инлайна виртуальных функций! ·>https://blog.jooq.org/2016/07/19/the-java-jit-compiler-is-darn-good-in-optimization/
То есть это для мобильников? И это касается только итераторов. Это и в .Net есть
Интерес представляет инлайнинг компараторов и прочих делегатоа прежде всего в дженериках.
На подобии roslyn-linq-rewrite
S>>>>>> На самом деле смысл в .Net Native не только в скорости и меньше расхода батареи, S>>>>·>У тебя есть сравнение? Или опять голословные утверждения? S>>>> Ну быстрее загружается, быстрее работает. Есть цифры на сайте MS. S>>·>Покажи. S>> https://msdn.microsoft.com/ru-ru/library/dn643729(v=vs.110).aspx S>>https://social.msdn.microsoft.com/Forums/en-US/f650e4d4-578f-4ef9-84d1-0d3eac9147c9/uwp-net-native-vs-net-jit-benchmark?forum=wpdevelop S>> По сборке мусора здесь S>>https://msdn.microsoft.com/pl-pl/windows/uwp/debug-test-perf/improve-garbage-collection-performance ·>А, фу-ты. Я думал быстрее, чем java. А так это просто значит, что обычный fw медленно работает, native fw — нормально, наконец-то.
То есть ты сравнивал мобильниках на java 5 и 6 с .Net Native?
S>>>>·>ART (Android Runtime) уже давно занимается компиляцией java в натив, install time — под конкретный девайс. S>>>> Спасибо. Интересно. Но там вроде компиляция на самом девайсе, в отличеие от MicroSoft S>>·>При желании компиляцию можно и до закачки делать — но непонятно зачем, тебе придётся компилировать под все возможные платформы, а их чуть больше чем дофига и постоянно клепают новые. S>> Так компилируется на стороне магазина. С мобильного указываются параметры и под него уже компилится или бертся из уже скомпиленных. Количество марок аппаратов ограничено. ·>Можно и так, запускай ART-конверсию на серваке... Но непонятно что это даёт, кроме как лишнюю нагрузку на сервера магазина. ·>И представь себе — выходит очередная версия компилятора с новыми фичами оптимизации и весь мир ломится на несчастные сервера магазина для обновления _всех_ приложений под _все_ платформы.
Угу. Весь мир Андроида сидит на java 5 или как раз с 6. S>>>> Нужна. Здесь на форуме много копий по этому поводу сломано. S>>·>Обсускаторы для java тоже есть. S>> Есть но машинный код лучше. ·>И компилятор тоже есть, для особо страждущих. https://www.excelsiorjet.com/
Еще раз смотрим версию, и вспоминаем на чем народ на Андроид до сих пор сидит
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, netch80, Вы писали:
I>>>>Это враньё. Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код. N>>>"Это враньё" ((c) Ikemefula). Перепахиванию RAM пофиг нативность кода, до тех пор, пока интерпретатор хоть как-то разумен — даже самый тупой JIT тут даёт достаточный результат. EP>>Ему ой как не пофиг на лишние косвенности и скачки по памяти, которыми пестрит весь управляемый код. N>Неуправляемый тоже. Это проблема структур данных,
Конечно, проблема в том что например в Java нет структур, а в C# их можно далеко не везде использовать — отсюда и получаются эти индерекции, которые проблема структур данных.
N>а не необходимости явного delete.
delete вообще не понятно при чём
EP>> Собственно поэтому и извращаются на байт-буферах чтобы эти самые косвенности пересилить N>Да. Или на структурах, в дотнете. И будут точно так же на структурах в Java 9.
О, в Java наконец появятся структуры?
N>И точно так же на структурах в C/C++, сюрприз
На C++ структуры это никакое не извращение, а вполне обычной код. Нарезание же байт-буферов вручную — вот это извращение
Здравствуйте, netch80, Вы писали:
EP>>Даст не нативность, а меньшее количество индерекций в сортируемых массивах, инлайнинг компараторов и итераторов. N>Про компараторы — почти согласен — по крайней мере если C++ std::sort, а не, например, C qsort (говорю это потому, что некоторые товарищи тут доказывали, что C++ тоже не годится).
qsort как раз каноничный пример почему C++ лучше для производительности чем C.
N>Для Java тут может потребоваться финт, обратный type erasure, но если мы говорим, как раньше в треде, про сортировку int[], то там и компаратор тривиальный, и доступ.
Не, тут я про общий случай. Если на Java взять сортировку прибитую к int[], да ещё и без компаратора — то там никаких косвеностей нет, и действительно будет быстро.
N>Индирекции же никуда не денутся, если не начинать менять по-умному структуры данных. Оптимизаторы C/C++ на это не способны, кроме банальных случаев типа "complex разместим в двух FP регистрах".
Тут заслуга не только оптимизаторов, но и языка. Да и не в FP регистрах суть.
На C++ vector<complex<float>> будет в памяти одним сплошным куском, by design.
На Java же будет массив указателей на объекты, N индерекций и аллокаций. Либо будет ручное error-prone нарезание float[] на комплексные числа. Собственно здесь уже было
сравнение именно на тему complex — на Java как раз вылез баг в самом причинном месте — на ручном нарезании И кстати требуемый код на Java (с перетасовкой) так никто и не показал
, и даже без неё уже было 3.5x проседание
N>>>в Java quicksort partitioning это dual-pivot, EP>>Это который Arrays.sort(int[])? Конечно сортировать прибитые гвоздями int'ы за average O(N * log(N)) — это повод для алгоритмической гордости, прям забороли-перебороли N>По-моему, он там везде, а не только на intʼах.
Так там же конкретные методы зачем-то. Да и для всех тех примитивных типов есть O(N) сортировки, тем более там компаратор не используется
N>>>а в GCC STL — introsort с выбором по тупой медиане и неуправляемой левосторонней рекурсией, соответственно, свалиться в плохой случай ей в разы легче. EP>>Худший случай у introsort это O(N*log(N)) N>С постоянным коэффициентом в 3 раза больше нормального quicksort.
Что?
EP>>А у Arrays.sort на Java какая-то расплывчатая формулировка EP>>
EP>>This algorithm offers O(n log(n)) performance on many data sets
EP>>Подозреваю что в худшем случае квадратичная N>Скорее всего, просто доку не обновили.
Тогда что имелось в виду вот здесь:
N>соответственно, свалиться в плохой случай ей в разы легче.
Когда с одной стороны worst-case O(N*log(N)), а с другой O(N*N)?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Даст не нативность, а меньшее количество индерекций в сортируемых массивах, инлайнинг компараторов и итераторов. N>>Про компараторы — почти согласен — по крайней мере если C++ std::sort, а не, например, C qsort (говорю это потому, что некоторые товарищи тут доказывали, что C++ тоже не годится). EP>qsort как раз каноничный пример почему C++ лучше для производительности чем C.
Это ты не мне, это тем коллегам говори.
N>>Для Java тут может потребоваться финт, обратный type erasure, но если мы говорим, как раньше в треде, про сортировку int[], то там и компаратор тривиальный, и доступ. EP>Не, тут я про общий случай. Если на Java взять сортировку прибитую к int[], да ещё и без компаратора — то там никаких косвеностей нет, и действительно будет быстро.
А не в общем случае надо смотреть, что JIT умеет, а не что кажется до его включения.
N>>Индирекции же никуда не денутся, если не начинать менять по-умному структуры данных. Оптимизаторы C/C++ на это не способны, кроме банальных случаев типа "complex разместим в двух FP регистрах". EP>Тут заслуга не только оптимизаторов, но и языка. Да и не в FP регистрах суть. EP>На C++ vector<complex<float>> будет в памяти одним сплошным куском, by design. EP>На Java же будет массив указателей на объекты, N индерекций и аллокаций. Либо будет ручное error-prone нарезание float[] на комплексные числа. Собственно здесь уже было
сравнение именно на тему complex — на Java как раз вылез баг в самом причинном месте — на ручном нарезании И кстати требуемый код на Java (с перетасовкой) так никто и не показал
Ну я в этих спецолимпиадах участвовать не хочу. А аналоги таких действий мы успешно реализуем. Да, громоздко. Но работает.
N>>По-моему, он там везде, а не только на intʼах. EP>Так там же конкретные методы зачем-то. Да и для всех тех примитивных типов есть O(N) сортировки, тем более там компаратор не используется
Если ты O(N) для int зовёшь всякие поразрядные (radix) и распределяющие, то это обманка. Именно за счёт проходов по количеству бит в представлении они и оказываются всё равно O(N log N), только логарифм стыдливо заметён под ковёр. Ну а на практике они невыгодны за счёт того, что не учитывают реальные ситуации типа "все числа менее 1000".
N>>>>а в GCC STL — introsort с выбором по тупой медиане и неуправляемой левосторонней рекурсией, соответственно, свалиться в плохой случай ей в разы легче. EP>>>Худший случай у introsort это O(N*log(N)) N>>С постоянным коэффициентом в 3 раза больше нормального quicksort. EP>Что?
Постоянный коэффициент у heapsort (которая в introsort как fallback) где-то в 3 раза выше quicksort. В лучшем частном случае оптимизируют до 1.5-2.
EP>Тогда что имелось в виду вот здесь: EP>
N>>соответственно, свалиться в плохой случай ей в разы легче.
EP>Когда с одной стороны worst-case O(N*log(N)), а с другой O(N*N)?
Плохой случай для introsort это когда она исчерпала бюджет рекурсии и переключается на heapsort. Я именно его имел в виду. А с тем, что данный sort рекурсию ведёт только налево — попасть в него ну очень легко.
Известный плохой случай для quicksort без intro — сейчас обходится сразу несколькими методами, банальными и не очень — начиная со случайного выбора разделяющего элемента (теоретически некошерно, практически же работает в 100% случаев), и вплоть до жёсткой (увеличение затрат в 1.5-2 раза), но железобетонно работающей медианы медиан. Можно делать и комбинированно — случайным до исчерпания бюджета, медиана медиан — после.
Здравствуйте, netch80, Вы писали:
N>Ну, против этого есть и здравый смысл, и защита. В гугловском магазине и, думаю, не только в нём, есть вариант "анонсировать обновление только K процентов пользователей", с дискретом для K типа 10, а, может, и меньше. А по жалобам, если что — откатить срочно назад.
Понятно, что это можно размазать по времени. Но это не изменяет само число.
Так у нас есть D версий девайсов, A версий аппликух, K версий компиляторов.
В случае запуска компилятора на девайсе: D + A + K бинариков.
Значит на серверах надо собрать и распространить D * A * K бинариков.
комбинаторный взрыв, однако... а выгода совсем не очевидна.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>·>inline тоже делается. Притом после virtual call elimination. Круто ведь — возможность инлайна виртуальных функций! S>·>https://blog.jooq.org/2016/07/19/the-java-jit-compiler-is-darn-good-in-optimization/ S> То есть это для мобильников? И это касается только итераторов. Это и в .Net есть S> Интерес представляет инлайнинг компараторов и прочих делегатоа прежде всего в дженериках. S>На подобии roslyn-linq-rewrite
На уровне байткода никаких дженериков и делегатов нет, JIT-у пофиг что инлайнить. Компаратор такой же класс, имплементирующий интерфейс, как и всё остальное.
S>>>·>Покажи. S>>> https://msdn.microsoft.com/ru-ru/library/dn643729(v=vs.110).aspx S>>>https://social.msdn.microsoft.com/Forums/en-US/f650e4d4-578f-4ef9-84d1-0d3eac9147c9/uwp-net-native-vs-net-jit-benchmark?forum=wpdevelop S>>> По сборке мусора здесь S>>>https://msdn.microsoft.com/pl-pl/windows/uwp/debug-test-perf/improve-garbage-collection-performance S>·>А, фу-ты. Я думал быстрее, чем java. А так это просто значит, что обычный fw медленно работает, native fw — нормально, наконец-то. S> То есть ты сравнивал мобильниках на java 5 и 6 с .Net Native?
Нет, не сравнивал. Я вообще с мобильниками дела не имею. Но я бы удивился, если бы джава отстала по перформансу.
S>>> Так компилируется на стороне магазина. С мобильного указываются параметры и под него уже компилится или бертся из уже скомпиленных. Количество марок аппаратов ограничено. S>·>Можно и так, запускай ART-конверсию на серваке... Но непонятно что это даёт, кроме как лишнюю нагрузку на сервера магазина. S>·>И представь себе — выходит очередная версия компилятора с новыми фичами оптимизации и весь мир ломится на несчастные сервера магазина для обновления _всех_ приложений под _все_ платформы. S> Угу. Весь мир Андроида сидит на java 5 или как раз с 6.
Какая разница кто на чём сидит? Комбинации, однако: dotnet vs java 2016-2020.
S>>>>> Нужна. Здесь на форуме много копий по этому поводу сломано. S>>>·>Обсускаторы для java тоже есть. S>>> Есть но машинный код лучше. S>·>И компилятор тоже есть, для особо страждущих. https://www.excelsiorjet.com/ S> Еще раз смотрим версию, и вспоминаем на чем народ на Андроид до сих пор сидит https://www.excelsior-usa.com/jetdladdon.php?jetversion=700
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>inline тоже делается. Притом после virtual call elimination. Круто ведь — возможность инлайна виртуальных функций! S>>·>https://blog.jooq.org/2016/07/19/the-java-jit-compiler-is-darn-good-in-optimization/ S>> То есть это для мобильников? И это касается только итераторов. Это и в .Net есть S>> Интерес представляет инлайнинг компараторов и прочих делегатоа прежде всего в дженериках. S>>На подобии roslyn-linq-rewrite ·>На уровне байткода никаких дженериков и делегатов нет, JIT-у пофиг что инлайнить. Компаратор такой же класс, имплементирующий интерфейс, как и всё остальное.
В том чиле и метод. Это касается прежде всего int, byte, Int64 где вызов метода 1+1, значительно дольше самого сложения, сравнения
S>>>>·>Покажи. S>>>> https://msdn.microsoft.com/ru-ru/library/dn643729(v=vs.110).aspx S>>>>https://social.msdn.microsoft.com/Forums/en-US/f650e4d4-578f-4ef9-84d1-0d3eac9147c9/uwp-net-native-vs-net-jit-benchmark?forum=wpdevelop S>>>> По сборке мусора здесь S>>>>https://msdn.microsoft.com/pl-pl/windows/uwp/debug-test-perf/improve-garbage-collection-performance S>>·>А, фу-ты. Я думал быстрее, чем java. А так это просто значит, что обычный fw медленно работает, native fw — нормально, наконец-то. S>> То есть ты сравнивал мобильниках на java 5 и 6 с .Net Native? ·>Нет, не сравнивал. Я вообще с мобильниками дела не имею. Но я бы удивился, если бы джава отстала по перформансу.
Для мобильных платформ там совсем другие VM.
S>>>> Так компилируется на стороне магазина. С мобильного указываются параметры и под него уже компилится или бертся из уже скомпиленных. Количество марок аппаратов ограничено. S>>·>Можно и так, запускай ART-конверсию на серваке... Но непонятно что это даёт, кроме как лишнюю нагрузку на сервера магазина. S>>·>И представь себе — выходит очередная версия компилятора с новыми фичами оптимизации и весь мир ломится на несчастные сервера магазина для обновления _всех_ приложений под _все_ платформы. S>> Угу. Весь мир Андроида сидит на java 5 или как раз с 6. ·>Какая разница кто на чём сидит? Комбинации, однако: dotnet vs java 2016-2020.
То есть VM для вех версий одна? Да и андроидов разных полно. S>>>>>> Нужна. Здесь на форуме много копий по этому поводу сломано. S>>>>·>Обсускаторы для java тоже есть. S>>>> Есть но машинный код лучше. S>>·>И компилятор тоже есть, для особо страждущих. https://www.excelsiorjet.com/ S>> Еще раз смотрим версию, и вспоминаем на чем народ на Андроид до сих пор сидит ·>https://www.excelsior-usa.com/jetdladdon.php?jetversion=700
А где Андроид? Мы то говорим про мобильные платформы. .Net Native выгоден прежде всего для мобильных устройств.
Опять же для .Net Native не нужна установка .Net Core или CLR
Я так понимаю, что это аналог NGEN https://msdn.microsoft.com/ru-ru/library/dn807190(v=vs.110).aspx
NET Native и NGEN
Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
• Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
• NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
• Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, netch80, Вы писали:
N>Ты судишь по отчётам о супероптимизациях каких-нибудь memcpy за счёт фишек конкретного набора инструкций? N>Если так, то у JIT как раз больше шансов сделать тут оптимизацию под конкретный случай — это раз. И, чем дальше отличается задача от мейнстрима вбивания инструкций в конвейеры процессора — тем менее важна вылизанность нативности. На партиционировании в quicksort слишком много сравнений, чтобы нативность что-то дала.
Твои рассуждения конечно верны, но в глубокой теории, а на практике всё наоборот. Если рассуждать абстрактно, то подобные платформы (работающие под управлением ВМ, типа jvm, clr, многие скриптовые языки) могут обходить по быстродействию любые нативные языки, потому что имеют возможность применить все их статические оптимизации и потом ещё добавить к ним кучу своих рантаймовых. Именно так обычно и рассуждают пропагандисты данных технологий. Однако нас, практиков, интересуют не их влажные фантазии о счастливом будущем, а текущая суровая реальность. Так вот в данный момент на практике все компиляторы подобных платформ не обеспечивают даже половины мощнейших статических оптимизации (работающих по дефолту скажем во всех основных компиляторах C++) и добавляют при этом всего одну-две слабенькие рантайм оптимизации. В итоге на практике Java/C# (про скриптовые и не говорим) отстаёт от аналогичного C++ кода в разы.
Да, и это всё было исключительно об оптимизации, без учёта особенностей устройства языков (если начать учитывать лишнюю косвенность в подобных языках, работу сборщика мусора и т.п., то всё становится ещё намного печальнее). Т.е. отставание по быстродействию от нативного наблюдается даже на обычном линейном коде (без всяких там структур, выделений памяти и т.п.).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Ему ой как не пофиг на лишние косвенности и скачки по памяти, которыми пестрит весь управляемый код. N>>Неуправляемый тоже. Это проблема структур данных, EP>Конечно, проблема в том что например в Java нет структур, а в C# их можно далеко не везде использовать — отсюда и получаются эти индерекции, которые проблема структур данных.
Надо смотреть конкретный пример, общие высказывания я бы поостерёгся давать. А то внезапно у тебя не получится сделать std::vector<MyType> и придётся лепить std::vectior<some_smart_pointer<MyType>> и прочее. Т.е. нужно именно начинать от конкретных структур и смотерть что можно сделать.
EP>>> Собственно поэтому и извращаются на байт-буферах чтобы эти самые косвенности пересилить N>>Да. Или на структурах, в дотнете. И будут точно так же на структурах в Java 9. EP>О, в Java наконец появятся структуры?
О java 9 он вроде поторопился, фичефриз уже прошел, релизят через пол года (но пробовать можно уже сейчас), но есть планы в 10ке https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language) через года полтора-два.
В общем .net должен бежать ещё быстрее, чтоб окончательно не отстать по своим фичам.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
I>>Сам подумай — почему HPC, HFT, высоконагруженые приложения пишут на джаве, пейтоне. По уму, если выбирают перформанс, то надо писать исключительно на С++. Опаньки ! I>>Теперь понятно, что если производительность отстаёт не на порядки, то это _дешевле_ пофиксить железом иногда даже виртуальным. Собтсвенно выбор в пользу джавы именно так и делается, а то бы весь софт писали бы на С++.
_>Так в этих твоих примерах совсем другой расклад.
Примеры не мои, а твои. И выбор в пользу открытых технологий и кроссплатформенной VM.
_>В их офисном конечно не надо. Мы же не про клиринговые центры и т.п. процессинг говорим, а про "энтерпрайзные формочки". Кстати, а вот про ПО в клиринговых центрах тоже было бы интересно разузнать (скажем у Visa или MasterCard), на чём оно написано — там то как раз производительность вполне актуальна.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
V>>>А у меня есть весьма активно наполняемая система баг-трекинга конторы с кучей программеров. Там за несколько лет ни одной ошибки выхода за границы массива, зато куча типичных логических ошибок. И на динамическом коде их намного больше, ес-но. EP>·>И с памятью никаких проблем не было? Утечек не было? EP>Утечки вообще не в кассу, так как возможны и в управляемых языках
Тут надо отличать. Логические утечки: утечки ресурсов (незакрытые файлы, невозвращённые коннекты в пул, етс), утечки данных (вечнорастущий контейнер или забитый диск) возможны вообще в любом ЯП. А я имею в виду утечки памяти на уровне самого ЯП.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Честно говоря, это до тех пор, пока не надо работать с методом, который хочет именно std::string. А таких полно. Сделать абстрактный интерфейс (в смысле Java) readonly строки с фиксированным набором методов и требовать в таких методах реализацию такого интерфейса — не додумались, или не успели, неважно, но цена конверсии из своей строки в стандартную может быть слишком высокой.
Здравствуйте, netch80, Вы писали:
N>И точно так же на структурах в C/C++, сюрприз
В C++ же нет разницы между структурами и классами. Т.е. ты можешь ввести многоуровневую иерархию агрегации, причём каждый её элемент может быть членом сложной иерархии наследования и всё это вместе внесёт ровно нулевую косвенность (ну если использовать для агрегации контейнеры, то будет +1 уровень косвенности, но это всё равно даже близко не сравнимо с теми ужасами, что происходят в Java/C# в аналогичных случаях).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Сортировка это перепахивание RAM, то есть, именно то, ради чего стоит использовать нативный код. У тебя даже тупой проход по массиву интов на сишном коде даст вопиющую разницу.
EP>Нет, не даст — на уровне массива интов отличия как раз непринципиальные.
Вообще то разница уже видна
I>>Чем сложнее алгоритм, тем больше будет эта разница.
EP>А здесь верно.
I>>Хочешь перформанс — есть только Си и тот без плюсов.
EP>Нет, наоборот.
Если наоборот, то надо учесть, что современный ++ осваивают единицы, остальные только думают что освоили или просто не заморачиваются на этом.
По ссылке вижу упоминание новой GUI библиотеки (avalonia, сейчас в состояние альфа релиза) для .net, в этот раз кроссплатформенной. Само по себе это конечно же позитивное явление (будет, когда выйдет из состояния альфы), только причём тут WPF? )
Здравствуйте, Serginio1, Вы писали:
S>·>На уровне байткода никаких дженериков и делегатов нет, JIT-у пофиг что инлайнить. Компаратор такой же класс, имплементирующий интерфейс, как и всё остальное. S> В том чиле и метод. Это касается прежде всего int, byte, Int64 где вызов метода 1+1, значительно дольше самого сложения, сравнения
Что "метод"? Имплементировать интерфейс — значит написать имплементацию метода(ов) этого интерфейса. После девиртуализации вызова Comparator.compare станет доступным тело метода для инлайнинга.
S>>> То есть ты сравнивал мобильниках на java 5 и 6 с .Net Native? S>·>Нет, не сравнивал. Я вообще с мобильниками дела не имею. Но я бы удивился, если бы джава отстала по перформансу. S> Для мобильных платформ там совсем другие VM.
И что? Они медленнее .net что-ли?
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 запускать для генерации бинарика.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
