Сообщение Re[20]: C# - from indians by indians от 09.06.2015 19:57
Изменено 09.06.2015 20:05 alex_public
Здравствуйте, Sinix, Вы писали:
S>Выше по ветке уже был похожий пример
Да я вообще не пойму кто там ещё пользуется этим убожеством. И дело даже не в оптимизациях, а в стандартах. Кругом уже все на C++14 работают (полиморфные лямбды крайне удобны), а в у MS ещё даже C++11 целиком не реализован.
S>Угу, нынешний JIT на числомолотилки не заточен, это давно известно. Чисто ради интереса: какой фреймворк и x64 или x86 вариант проверялся?
Ммм, а у меня вроде как нет никакой разницы... Т.е. все изначальные тесты я делал для x64 (на всех языках), но сейчас отдельно глянул — 32-ух битный код ничего не меняет.
S>UPD Не из-за них, протупил. Для варианта с указателями на 7 сложений меньше, т.к. аналог (a[p + x]) вычисляется 1 раз. Вот этот вариант с указателями, но с доступом по индексу не отличается от safe-варианта:
Всё верно, я как раз на это и указывал здесь. Что многие алгоритмы записываются максимально эффективно только при наличие в языке арифметики указателей. Т.е. в Java вообще без шансов. В C# ещё можно вывернуться, но тут уже многие говорили, что программировать на unsafe C# смысла нет — это даже ещё более печально, чем на чистом C.
S>UPD2 Ну да, собственно этим твои варианты под шарп и c++ и отличаются
S>Как только я их привёл к одному виду на автомате — время совпало с нативным результатом без автовекторизации.
На самом деле не совпадает (разве что с результатом убогого компилятора от MS), но действительно уже близко. Могу показать свои результаты в виде единой таблички:
C++ — 1,3 с.
C++ с отключённой векторизацией — 3,5 с.
D — 4,9 с.
C# unsafe + страшный код с обращением к массиву через * — 5 с.
C# unsafe — 5,9 с.
Java — 7,3 с.
C# — 8,7 с.
Показательно значение для языка D (оригинальный компилятор, а не gdc) — там мы имеем полностью нативный код с указателями, без всяких рантайм проверок, но при этом со слабеньким оптимизатором.
Кстати, видно, что у C++ варианта есть большой простор по ручной SIMD оптимизации. Т.к. прирост в 3 раза — это явно меньше того, что можно получить на современных процессорах. Автовекторизация пока ещё отстаёт от ручной, но думаю через несколько лет это исправится. Так же как когда-то исправилось с обычной оптимизацией.
А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
S>Ручную векторизацию конечно можно попробовать сделать с RyuJIT + SIMD, но это уже за гранью добра и зла имхо. Нужна производительность — проще вытащить кусок в unmanaged-код и не страдать из-за "если добавить 7 лишних сложений, то шарп медленный".
Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях. Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))
S>Выше по ветке уже был похожий пример
Автор: PM
Дата: 05.06.15
. Компилятор c++ в vs2013 местами не блещет.Дата: 05.06.15
Да я вообще не пойму кто там ещё пользуется этим убожеством. И дело даже не в оптимизациях, а в стандартах. Кругом уже все на C++14 работают (полиморфные лямбды крайне удобны), а в у MS ещё даже C++11 целиком не реализован.
S>Угу, нынешний JIT на числомолотилки не заточен, это давно известно. Чисто ради интереса: какой фреймворк и x64 или x86 вариант проверялся?
Ммм, а у меня вроде как нет никакой разницы... Т.е. все изначальные тесты я делал для x64 (на всех языках), но сейчас отдельно глянул — 32-ух битный код ничего не меняет.
S>UPD Не из-за них, протупил. Для варианта с указателями на 7 сложений меньше, т.к. аналог (a[p + x]) вычисляется 1 раз. Вот этот вариант с указателями, но с доступом по индексу не отличается от safe-варианта:
Всё верно, я как раз на это и указывал здесь. Что многие алгоритмы записываются максимально эффективно только при наличие в языке арифметики указателей. Т.е. в Java вообще без шансов. В C# ещё можно вывернуться, но тут уже многие говорили, что программировать на unsafe C# смысла нет — это даже ещё более печально, чем на чистом C.
S>UPD2 Ну да, собственно этим твои варианты под шарп и c++ и отличаются
S>Как только я их привёл к одному виду на автомате — время совпало с нативным результатом без автовекторизации.
На самом деле не совпадает (разве что с результатом убогого компилятора от MS), но действительно уже близко. Могу показать свои результаты в виде единой таблички:
C++ — 1,3 с.
C++ с отключённой векторизацией — 3,5 с.
D — 4,9 с.
C# unsafe + страшный код с обращением к массиву через * — 5 с.
C# unsafe — 5,9 с.
Java — 7,3 с.
C# — 8,7 с.
Показательно значение для языка D (оригинальный компилятор, а не gdc) — там мы имеем полностью нативный код с указателями, без всяких рантайм проверок, но при этом со слабеньким оптимизатором.
Кстати, видно, что у C++ варианта есть большой простор по ручной SIMD оптимизации. Т.к. прирост в 3 раза — это явно меньше того, что можно получить на современных процессорах. Автовекторизация пока ещё отстаёт от ручной, но думаю через несколько лет это исправится. Так же как когда-то исправилось с обычной оптимизацией.
А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
S>Ручную векторизацию конечно можно попробовать сделать с RyuJIT + SIMD, но это уже за гранью добра и зла имхо. Нужна производительность — проще вытащить кусок в unmanaged-код и не страдать из-за "если добавить 7 лишних сложений, то шарп медленный".
Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях. Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))
Re[20]: C# - from indians by indians
Здравствуйте, Sinix, Вы писали:
S>Выше по ветке уже был похожий пример
Да я вообще не пойму кто там ещё пользуется этим убожеством. И дело даже не в оптимизациях, а в стандартах. Кругом уже все на C++14 работают (полиморфные лямбды крайне удобны), а в у MS ещё даже C++11 целиком не реализован.
S>Угу, нынешний JIT на числомолотилки не заточен, это давно известно. Чисто ради интереса: какой фреймворк и x64 или x86 вариант проверялся?
Ммм, а у меня вроде как нет никакой разницы... Т.е. все изначальные тесты я делал для x64 (на всех языках), но сейчас отдельно глянул — 32-ух битный код ничего не меняет.
S>UPD Не из-за них, протупил. Для варианта с указателями на 7 сложений меньше, т.к. аналог (a[p + x]) вычисляется 1 раз. Вот этот вариант с указателями, но с доступом по индексу не отличается от safe-варианта:
Всё верно, я как раз на это и указывал здесь. Что многие алгоритмы записываются максимально эффективно только при наличие в языке арифметики указателей. Т.е. в Java вообще без шансов. В C# ещё можно вывернуться, но тут уже многие говорили, что программировать на unsafe C# смысла нет — это даже ещё более печально, чем на чистом C.
Да, и что самое главное... В таком варианте код не только быстрее, но и удобнее. Т.е. в отличие от вариантов во многих других языках, где нам надо уродовать код для достижения производительности, здесь у нас самый красивый код является самым быстрым.
S>UPD2 Ну да, собственно этим твои варианты под шарп и c++ и отличаются
S>Как только я их привёл к одному виду на автомате — время совпало с нативным результатом без автовекторизации.
На самом деле не совпадает (разве что с результатом убогого компилятора от MS), но действительно уже близко. Могу показать свои результаты в виде единой таблички:
C++ — 1,3 с.
C++ с отключённой векторизацией — 3,5 с.
D — 4,9 с.
C# unsafe + страшный код с обращением к массиву через * — 5 с.
C# unsafe — 5,9 с.
Java — 7,3 с.
C# — 8,7 с.
Показательно значение для языка D (оригинальный компилятор, а не gdc) — там мы имеем полностью нативный код с указателями, без всяких рантайм проверок, но при этом со слабеньким оптимизатором.
Кстати, видно, что у C++ варианта есть большой простор по ручной SIMD оптимизации. Т.к. прирост в 3 раза — это явно меньше того, что можно получить на современных процессорах. Автовекторизация пока ещё отстаёт от ручной, но думаю через несколько лет это исправится. Так же как когда-то исправилось с обычной оптимизацией.
А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
S>Ручную векторизацию конечно можно попробовать сделать с RyuJIT + SIMD, но это уже за гранью добра и зла имхо. Нужна производительность — проще вытащить кусок в unmanaged-код и не страдать из-за "если добавить 7 лишних сложений, то шарп медленный".
Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях. Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))
S>Выше по ветке уже был похожий пример
Автор: PM
Дата: 05.06.15
. Компилятор c++ в vs2013 местами не блещет.Дата: 05.06.15
Да я вообще не пойму кто там ещё пользуется этим убожеством. И дело даже не в оптимизациях, а в стандартах. Кругом уже все на C++14 работают (полиморфные лямбды крайне удобны), а в у MS ещё даже C++11 целиком не реализован.
S>Угу, нынешний JIT на числомолотилки не заточен, это давно известно. Чисто ради интереса: какой фреймворк и x64 или x86 вариант проверялся?
Ммм, а у меня вроде как нет никакой разницы... Т.е. все изначальные тесты я делал для x64 (на всех языках), но сейчас отдельно глянул — 32-ух битный код ничего не меняет.
S>UPD Не из-за них, протупил. Для варианта с указателями на 7 сложений меньше, т.к. аналог (a[p + x]) вычисляется 1 раз. Вот этот вариант с указателями, но с доступом по индексу не отличается от safe-варианта:
Всё верно, я как раз на это и указывал здесь. Что многие алгоритмы записываются максимально эффективно только при наличие в языке арифметики указателей. Т.е. в Java вообще без шансов. В C# ещё можно вывернуться, но тут уже многие говорили, что программировать на unsafe C# смысла нет — это даже ещё более печально, чем на чистом C.
Да, и что самое главное... В таком варианте код не только быстрее, но и удобнее. Т.е. в отличие от вариантов во многих других языках, где нам надо уродовать код для достижения производительности, здесь у нас самый красивый код является самым быстрым.
S>UPD2 Ну да, собственно этим твои варианты под шарп и c++ и отличаются
S>Как только я их привёл к одному виду на автомате — время совпало с нативным результатом без автовекторизации.
На самом деле не совпадает (разве что с результатом убогого компилятора от MS), но действительно уже близко. Могу показать свои результаты в виде единой таблички:
C++ — 1,3 с.
C++ с отключённой векторизацией — 3,5 с.
D — 4,9 с.
C# unsafe + страшный код с обращением к массиву через * — 5 с.
C# unsafe — 5,9 с.
Java — 7,3 с.
C# — 8,7 с.
Показательно значение для языка D (оригинальный компилятор, а не gdc) — там мы имеем полностью нативный код с указателями, без всяких рантайм проверок, но при этом со слабеньким оптимизатором.
Кстати, видно, что у C++ варианта есть большой простор по ручной SIMD оптимизации. Т.к. прирост в 3 раза — это явно меньше того, что можно получить на современных процессорах. Автовекторизация пока ещё отстаёт от ручной, но думаю через несколько лет это исправится. Так же как когда-то исправилось с обычной оптимизацией.
А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
S>Ручную векторизацию конечно можно попробовать сделать с RyuJIT + SIMD, но это уже за гранью добра и зла имхо. Нужна производительность — проще вытащить кусок в unmanaged-код и не страдать из-за "если добавить 7 лишних сложений, то шарп медленный".
Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях. Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))