RC

[thedeemon]

В интернетах обсуждают очередное сравнение скорости работы разных языков, на этот раз на примере user mode сетевых драйверов. С непреодолим как скорость света. Раст отстает, то ли из-за bounds checks, то ли из-за другого кодогенератора (LLVM vs. GCC). Неожиданно хорошо выступил C#, там есть value типы и слайсы/спаны, можно снизить нагрузку на GC до нуля практически, есть unsafe блоки и указатели. Близко к нему Go. Java отстала. Окамл получился быстрее Хаскеля. Но самый позорный результат из компилируемых языков - у Swift'a. И ведь не первый раз я вижу, что он так тормозит. Комментарии из их статьи:

Swift increments a reference counter for each object passed into a function and decreases it when leaving the function. This is done for every single packet as they are wrapped in Swift-native wrappers for bounds checks. There is no good way to disable this behavior for the wrapper objects while maintaining an idiomatic API for applications using the driver. A total of 76% of the CPU time is spent incrementing and decrementing reference counters. This is the only language runtime evaluated here that incurs a large cost even for objects that are never free’d.

Вот вам и "RC быстрее GC".

Занятное про Хаскель:
Compiler (GHC 8.4.3) optimizations seem to do more harm than good in this workload. Increasing the optimization level in the default GHC backend from O1 to O2 reduces throughput by 11%. The data in the graph is based on the LLVM backend which is 3.5% faster than the default backend at O1. Enabling the threaded runtime in GHC decreases performance by 8% and causes the driver to lose packets even at loads below 1 Mpps due to regular GC pauses of several milliseconds.

Comments

[juan_gandhi]

Забавные наблюдения.

Тут, конечно, сравнивается, пожалуй, не скорость языков, а скорость относительно небольшого хорошо вылизанного кода на разных языках.

Но интересно все равно.

[perdakot]

Вот вам и "RC быстрее GC".
Swift increments a reference counter for each object passed into a function and decreases it when leaving the function.

А ГЦ же даже больше должен делать, создать ссылку, зарегистрировать ее везде и обратно.

[chaource]

As far as I understand, GC does not necessarily work like that. Some GC implementations walk the heap and find pointers that are unused.

[perdakot]

А корни берутся из стэк фреймов, где ссылки хранятся в виде указателей и ГЦ знает куда смотреть? Как тогда куча уплотняется (указатели правятся прямо в стэке)?

[thedeemon]

При вызове функции указатель просто кладется на стек, как в Си, специально регистрировать его и обратно не надо, это бы все такие языки затормозило на порядки. Внутри ф-ии обычно бывают специальные места, где instruction pointer может находиться, когда случается GC. Т.е. или сама ф-я вызывает аллокацию, а та вызывает сборку, либо если сборку инициировал другой поток, этот поток не останавливается внезапно, а лишь в подходящем месте. Для всех таких подходящих мест компилятор заранее статически генерит карту стека - где на нем лежат указатели в этот момет. Ее сборщик использует при анализе стека.

Бывают и более простые подходы. Например, в D сборщик просто весь стек сканирует, и все, что похоже на указатель по значению (делится на величину слова [upd: не обязательно], "указывает" на нужный диапазон адресов), считает потенциальным указателем.

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

[chaource]

GC is a well developed field with 500-page books full of GC algorithms. I wouldn't know what made Ocaml faster than GHC, for example.

I read somewhere that Standard ML has an experimental compiler called "MLTon" that eliminates all garbage collection by whole-program optimization. Not sure if this is really possible in all cases.

[perdakot]

eliminates all garbage collection by whole-program

Rust этим занимается с лайфтаймами, поэтому двухсвязный список в нем нетривиален.

[thedeemon]

Rust слишком много на программиста перекладывает. В ML Kit пытались сделать автоматический вывод "регионов", чтобы не надо было вручную как в Расте о временах жизни заботиться, и все структуры данных было бы делать не сложнее, чем в обычном ML. Но, увы, так ничего хорошего и не вышло, все равно GC нужен.

[thedeemon]

"MLton does not use region-based memory management; it uses traditional GarbageCollection. We have considered integrating regions with MLton, but in our opinion it is far from clear that regions would provide MLton with improved performance, while they would certainly add a lot of complexity to the compiler and complicate reasoning about and achieving SpaceSafety."
http://www.mlton.org/Regions

Там были исследования по region inference, но по сути провалились.

[sassa_nf]

Generated code has safe points where all pointers are in known places in memory, not in registers. Yes, the pointers are modified in place.

There are methods that allow to do less of this, trapping mutators by marking relocated regions as read only or missing.

[vit_r]

Проблема с высоконагруженными приложениями в том, что нужна компиляция без side-effects. То есть, можно бросить на отладку лишние силы, добрав пять процентов, и сама постановка вопросов не имеет смысла.

В задаче же с большими объектами и графическим интерфейсом важно время реакции. И тут, подозреваю, скорости будут другие.

Интересно, кстати, было бы посмотреть на С++.

[thedeemon]

Тут можно открыть список CVE и видеть, как на отладку все бросают силы и бросают, все бросают и бросают, но все равно дыра за дырой открывается, и в большинстве случаев - некорректная работа с памятью. Не получается у человечества безопасный код на Си писать, десятилетиями пытались.

Но если скорость - самое важное, а на остальное наплевать, тогда да, С is king.

И да, С++ там напрасно нет.

[vit_r]

Не получается у человечества безопасный код на Си писать, десятилетиями пытались.

Человеки разные бывают. Всё-таки от организации производства очень многое зависит.

[sassa_nf]

Java is full of JNI. That's expensive, and is a nonsensical way of implementing it. When we worked on ixgbe, we implemented a NativeByteBuffer, then all accesses are normal Java, only allocation and some forms of polling required JNI.

Our RT was 100 usecs.