Вы правы, SIMD-оптимизации не были учтены, и это сильно портит сравнение. Однако Span<T>.Fill() я бы, все же, сравнил с memcpy. Хотелось посмотреть на то, как оптимизируются банальные вещи, без специфического тюнинга кода под задачу.
В замерах выделение памяти не участвует, gc на время выполнения не повлияет, так как он соберет большой объект только при выделении памяти, когда память выделенная для кучи закончится. Соберет он его вместе с поколением 2. Именно для того, чтобы сборка мусора не произошла в неудобный момент, выделений памяти вынесено за пределы измеряемого блока кода. Пробовал с ручной сборкой LOH, результаты не отличались. Оставил так для простоты кода.
Вы правы, SIMD-оптимизации не были учтены, и это сильно портит сравнение. Однако Span<T>.Fill() я бы, все же, сравнил с memcpy. Хотелось посмотреть на то, как оптимизируются банальные вещи, без специфического тюнинга кода под задачу.
Справедливости ради, компилятор указан в начале статьи
Вроде бы, нет тут SIMD
Код асемблера:
Благодарю за комментарий. Ваш код проверил, цифры те же +- что и у обычного массива. Обязательно разберусь, можно ли с помощью SIMD ускориться.
Речь идет о C, а не о C++. Проверьте вышеприведенный код с этим языком
В другом потоке, например
В замерах выделение памяти не участвует, gc на время выполнения не повлияет, так как он соберет большой объект только при выделении памяти, когда память выделенная для кучи закончится. Соберет он его вместе с поколением 2. Именно для того, чтобы сборка мусора не произошла в неудобный момент, выделений памяти вынесено за пределы измеряемого блока кода. Пробовал с ручной сборкой LOH, результаты не отличались. Оставил так для простоты кода.