Сообщение Re[10]: 2D-Linq и оптимизация цифровых фильтров - 4 от 05.08.2020 11:01
Изменено 05.08.2020 11:15 Mystic Artifact
Re[10]: 2D-Linq и оптимизация цифровых фильтров - 4
Здравствуйте, Sinclair, Вы писали:
MA>>Просто обращу внимание, что там же так же есть ссылка на [Proposal][Crossgen] Relax throughput impacting JIT parameters for crossgen в котором есть ссылка на ченджсет с конфигурированием этого лимита. Я постараюсь не забыть и смогу попробовать повторить тест с увеличенным лимитом. Хоть будет видно, насколько это сильно поменяет ситуацию.
S>Попробуй новую версию — я сократил количество временных переменных путём переиспользования.
Попробовал. 20 локалов вместо 600 это безусловно прогресс.
Тесты:
В принципе результаты полностью повторяют предыдущие...
Поковыряв JIT, я обнаружил, что число локальный переменных для GetDetect:Transform, нужно фактически вдвое больше чем тот, что был указан в IL... Их число происходит из количества стэковых операций, и не уверен что связано с локалами, так что лимит который будет работать это... скорее 1200. С лимитом в 2048 вместо 48Kb кода, получается 38Kb, а так же требуется практически в два раза меньше места на стэке. Время исполнения безусловно улучшается тоже, но ни о каких 30%-40% речи там нет. Таким образом что первая, что вторая версия обламывается с сообщением "Stopped promoting struct fields, due to too many locals.", и только JIT с умеличенным лимитом не обламывается. Но даже если он не обламывается — судя по всему это тот случай где ты много не теряешь (там остается именно каких-то 4 структуры, 1x ValueTuple`2 и 3x Vector32`1). Хрен его знает. Безусловно, более качественная компиляция помогает. Но размер кода с оптимизированными locals так же уменьшается до 43Кб, что как бы всё равно лучше.
В общем как-то много мороки, а профита не виднос с ковыряниями вокруг JIT. Надоел он что-то. Там выхлоп его данных в 100Мб на этот метод. Не хочу больше читать. Ничего не понятно всё равно.
Вот альтернативный замер для подумать:
MA>>Просто обращу внимание, что там же так же есть ссылка на [Proposal][Crossgen] Relax throughput impacting JIT parameters for crossgen в котором есть ссылка на ченджсет с конфигурированием этого лимита. Я постараюсь не забыть и смогу попробовать повторить тест с увеличенным лимитом. Хоть будет видно, насколько это сильно поменяет ситуацию.
S>Попробуй новую версию — я сократил количество временных переменных путём переиспользования.
Попробовал. 20 локалов вместо 600 это безусловно прогресс.
Тесты:
Pooling of CSE vars
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |-----------:|--------:|--------:|------:|
| SafeSauvola | 5 | p00743.bmp | 1,285.3 ms | 8.81 ms | 8.24 ms | 1.80 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 714.5 ms | 4.02 ms | 3.76 ms | 1.00 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,153.9 ms | 7.31 ms | 6.48 ms | 1.62 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,281.3 ms | 5.12 ms | 4.53 ms | 1.79 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 687.0 ms | 5.03 ms | 4.71 ms | 0.96 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 815.4 ms | 5.02 ms | 4.70 ms | 1.14 |
BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.388 (2004/?/20H1)
Intel Core i7-4770 CPU 3.40GHz (Haswell), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=5.0.100-preview.6.20318.15
[Host] : .NET Core 3.1.6 (CoreCLR 4.700.20.26901, CoreFX 4.700.20.31603), X64 RyuJIT
DefaultJob : .NET Core 3.1.6 (CoreCLR 4.700.20.26901, CoreFX 4.700.20.31603), X64 RyuJIT
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |-----------:|--------:|--------:|------:|
| SafeSauvola | 5 | p00743.bmp | 1,280.9 ms | 8.19 ms | 7.66 ms | 1.79 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 714.7 ms | 4.36 ms | 4.08 ms | 1.00 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,153.1 ms | 5.11 ms | 4.78 ms | 1.61 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,277.9 ms | 6.96 ms | 6.51 ms | 1.79 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 693.5 ms | 5.69 ms | 5.04 ms | 0.97 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 815.9 ms | 4.73 ms | 4.43 ms | 1.14 |В принципе результаты полностью повторяют предыдущие...
Поковыряв JIT, я обнаружил, что число локальный переменных для GetDetect:Transform, нужно фактически вдвое больше чем тот, что был указан в IL... Их число происходит из количества стэковых операций, и не уверен что связано с локалами, так что лимит который будет работать это... скорее 1200. С лимитом в 2048 вместо 48Kb кода, получается 38Kb, а так же требуется практически в два раза меньше места на стэке. Время исполнения безусловно улучшается тоже, но ни о каких 30%-40% речи там нет. Таким образом что первая, что вторая версия обламывается с сообщением "Stopped promoting struct fields, due to too many locals.", и только JIT с умеличенным лимитом не обламывается. Но даже если он не обламывается — судя по всему это тот случай где ты много не теряешь (там остается именно каких-то 4 структуры, 1x ValueTuple`2 и 3x Vector32`1). Хрен его знает. Безусловно, более качественная компиляция помогает. Но размер кода с оптимизированными locals так же уменьшается до 43Кб, что как бы всё равно лучше.
lclMAX_TRACKED = 512
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |---------:|--------:|--------:|------:|
| UnsafeSauvolaScalar | 5 | p00743.bmp | 671.6 ms | 4.69 ms | 4.38 ms | 1.00 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 638.0 ms | 7.64 ms | 7.15 ms | 0.95 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 773.9 ms | 4.66 ms | 4.36 ms | 1.15 |
lclMAX_TRACKED = 2048
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |---------:|--------:|--------:|------:|
| UnsafeSauvolaScalar | 5 | p00743.bmp | 673.9 ms | 5.37 ms | 4.76 ms | 1.00 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 610.2 ms | 0.77 ms | 0.72 ms | 0.91 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 732.3 ms | 4.65 ms | 4.35 ms | 1.09 |В общем как-то много мороки, а профита не виднос с ковыряниями вокруг JIT. Надоел он что-то. Там выхлоп его данных в 100Мб на этот метод. Не хочу больше читать. Ничего не понятно всё равно.
Вот альтернативный замер для подумать:
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio | RatioSD | BranchInstructions/Op | BranchMispredictions/Op |
|------------------------ |------ |----------- |-----------:|---------:|---------:|------:|--------:|----------------------:|------------------------:|
| SafeSauvola | 5 | p00743.bmp | 1,256.5 ms | 5.32 ms | 4.44 ms | 1.82 | 0.01 | 783,368,081 | 3,552,007 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 689.6 ms | 3.19 ms | 2.98 ms | 1.00 | 0.00 | 314,035,883 | 970,411 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,276.0 ms | 6.58 ms | 6.15 ms | 1.85 | 0.01 | 533,759,280 | 5,058,339 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,267.0 ms | 6.60 ms | 5.51 ms | 1.84 | 0.01 | 400,418,238 | 5,938,255 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 677.1 ms | 5.66 ms | 5.30 ms | 0.98 | 0.01 | 214,382,434 | 801,792 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 815.8 ms | 16.20 ms | 15.91 ms | 1.18 | 0.02 | 97,124,131 | 1,867,112 |Re[10]: 2D-Linq и оптимизация цифровых фильтров - 4
Здравствуйте, Sinclair, Вы писали:
MA>>Просто обращу внимание, что там же так же есть ссылка на [Proposal][Crossgen] Relax throughput impacting JIT parameters for crossgen в котором есть ссылка на ченджсет с конфигурированием этого лимита. Я постараюсь не забыть и смогу попробовать повторить тест с увеличенным лимитом. Хоть будет видно, насколько это сильно поменяет ситуацию.
S>Попробуй новую версию — я сократил количество временных переменных путём переиспользования.
Попробовал. 20 локалов вместо 600 это безусловно прогресс.
Тесты:
В принципе результаты полностью повторяют предыдущие...
Поковыряв JIT, я обнаружил, что число локальный переменных для GetDetect:Transform, нужно фактически вдвое больше чем тот, что был указан в IL... Их число происходит из количества стэковых операций, и не уверен что связано с локалами, так что лимит который будет работать это... скорее 1200. С лимитом в 2048 вместо 48Kb кода, получается 38Kb, а так же требуется практически в два раза меньше места на стэке. Время исполнения безусловно улучшается тоже, но ни о каких 30%-40% речи там нет. Таким образом что первая, что вторая версия обламывается с сообщением "Stopped promoting struct fields, due to too many locals.", и только JIT с умеличенным лимитом не обламывается. Но даже если он не обламывается — судя по всему это тот случай где ты много не теряешь (там остается именно каких-то 4 структуры, 1x ValueTuple`2 и 3x Vector32`1). Хрен его знает. Безусловно, более качественная компиляция помогает. Но размер кода с оптимизированными locals так же уменьшается до 43Кб, что как бы всё равно лучше.
В общем как-то много мороки, а профита не виднос с ковыряниями вокруг JIT. Надоел он что-то. Там выхлоп его данных в 100Мб на этот метод. Не хочу больше читать. Ничего не понятно всё равно.
Вот альтернативный замер для подумать:
MA>>Просто обращу внимание, что там же так же есть ссылка на [Proposal][Crossgen] Relax throughput impacting JIT parameters for crossgen в котором есть ссылка на ченджсет с конфигурированием этого лимита. Я постараюсь не забыть и смогу попробовать повторить тест с увеличенным лимитом. Хоть будет видно, насколько это сильно поменяет ситуацию.
S>Попробуй новую версию — я сократил количество временных переменных путём переиспользования.
Попробовал. 20 локалов вместо 600 это безусловно прогресс.
Тесты:
Pooling of CSE vars
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |-----------:|--------:|--------:|------:|
| SafeSauvola | 5 | p00743.bmp | 1,285.3 ms | 8.81 ms | 8.24 ms | 1.80 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 714.5 ms | 4.02 ms | 3.76 ms | 1.00 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,153.9 ms | 7.31 ms | 6.48 ms | 1.62 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,281.3 ms | 5.12 ms | 4.53 ms | 1.79 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 687.0 ms | 5.03 ms | 4.71 ms | 0.96 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 815.4 ms | 5.02 ms | 4.70 ms | 1.14 |
BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.388 (2004/?/20H1)
Intel Core i7-4770 CPU 3.40GHz (Haswell), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=5.0.100-preview.6.20318.15
[Host] : .NET Core 3.1.6 (CoreCLR 4.700.20.26901, CoreFX 4.700.20.31603), X64 RyuJIT
DefaultJob : .NET Core 3.1.6 (CoreCLR 4.700.20.26901, CoreFX 4.700.20.31603), X64 RyuJIT
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |-----------:|--------:|--------:|------:|
| SafeSauvola | 5 | p00743.bmp | 1,280.9 ms | 8.19 ms | 7.66 ms | 1.79 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 714.7 ms | 4.36 ms | 4.08 ms | 1.00 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,153.1 ms | 5.11 ms | 4.78 ms | 1.61 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,277.9 ms | 6.96 ms | 6.51 ms | 1.79 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 693.5 ms | 5.69 ms | 5.04 ms | 0.97 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 815.9 ms | 4.73 ms | 4.43 ms | 1.14 |В принципе результаты полностью повторяют предыдущие...
Поковыряв JIT, я обнаружил, что число локальный переменных для GetDetect:Transform, нужно фактически вдвое больше чем тот, что был указан в IL... Их число происходит из количества стэковых операций, и не уверен что связано с локалами, так что лимит который будет работать это... скорее 1200. С лимитом в 2048 вместо 48Kb кода, получается 38Kb, а так же требуется практически в два раза меньше места на стэке. Время исполнения безусловно улучшается тоже, но ни о каких 30%-40% речи там нет. Таким образом что первая, что вторая версия обламывается с сообщением "Stopped promoting struct fields, due to too many locals.", и только JIT с умеличенным лимитом не обламывается. Но даже если он не обламывается — судя по всему это тот случай где ты много не теряешь (там остается именно каких-то 4 структуры, 1x ValueTuple`2 и 3x Vector32`1). Хрен его знает. Безусловно, более качественная компиляция помогает. Но размер кода с оптимизированными locals так же уменьшается до 43Кб, что как бы всё равно лучше.
lclMAX_TRACKED = 512
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |---------:|--------:|--------:|------:|
| UnsafeSauvolaScalar | 5 | p00743.bmp | 671.6 ms | 4.69 ms | 4.38 ms | 1.00 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 638.0 ms | 7.64 ms | 7.15 ms | 0.95 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 773.9 ms | 4.66 ms | 4.36 ms | 1.15 |
lclMAX_TRACKED = 2048
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio |
|------------------------ |------ |----------- |---------:|--------:|--------:|------:|
| UnsafeSauvolaScalar | 5 | p00743.bmp | 673.9 ms | 5.37 ms | 4.76 ms | 1.00 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 610.2 ms | 0.77 ms | 0.72 ms | 0.91 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 732.3 ms | 4.65 ms | 4.35 ms | 1.09 |В общем как-то много мороки, а профита не виднос с ковыряниями вокруг JIT. Надоел он что-то. Там выхлоп его данных в 100Мб на этот метод. Не хочу больше читать. Ничего не понятно всё равно.
Вот альтернативный замер для подумать:
Run 1:
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio | RatioSD | BranchInstructions/Op | BranchMispredictions/Op |
|------------------------ |------ |----------- |-----------:|---------:|---------:|------:|--------:|----------------------:|------------------------:|
| SafeSauvola | 5 | p00743.bmp | 1,256.5 ms | 5.32 ms | 4.44 ms | 1.82 | 0.01 | 783,368,081 | 3,552,007 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 689.6 ms | 3.19 ms | 2.98 ms | 1.00 | 0.00 | 314,035,883 | 970,411 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,276.0 ms | 6.58 ms | 6.15 ms | 1.85 | 0.01 | 533,759,280 | 5,058,339 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,267.0 ms | 6.60 ms | 5.51 ms | 1.84 | 0.01 | 400,418,238 | 5,938,255 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 677.1 ms | 5.66 ms | 5.30 ms | 0.98 | 0.01 | 214,382,434 | 801,792 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 815.8 ms | 16.20 ms | 15.91 ms | 1.18 | 0.02 | 97,124,131 | 1,867,112 |
Run 2:
| Method | WHalf | FileName | Mean | Error | StdDev | Ratio | RatioSD | BranchInstructions/Op | BranchMispredictions/Op |
|------------------------ |------ |----------- |-----------:|---------:|---------:|------:|--------:|----------------------:|------------------------:|
| SafeSauvola | 5 | p00743.bmp | 1,256.7 ms | 2.48 ms | 2.32 ms | 1.83 | 0.01 | 803,031,495 | 3,632,242 |
| UnsafeSauvolaScalar | 5 | p00743.bmp | 685.3 ms | 3.28 ms | 3.07 ms | 1.00 | 0.00 | 305,128,752 | 916,065 |
| LinqSauvolaVector | 5 | p00743.bmp | 1,115.8 ms | 4.97 ms | 4.41 ms | 1.63 | 0.01 | 561,164,990 | 5,154,875 |
| LinqSauvolaScalar | 5 | p00743.bmp | 1,241.6 ms | 3.64 ms | 3.41 ms | 1.81 | 0.01 | 425,470,320 | 6,090,332 |
| CachedLinqSauvolaVector | 5 | p00743.bmp | 671.9 ms | 12.92 ms | 13.27 ms | 0.98 | 0.02 | 205,053,288 | 729,199 |
| CachedLinqSauvolaScalar | 5 | p00743.bmp | 785.7 ms | 3.74 ms | 3.50 ms | 1.15 | 0.00 | 99,804,388 | 1,917,611 |