.NET Core 3.0 will expose SIMD instructions as API’s that are available to managed code directly, making it unnecessary to use native code to access them.
Re: .NET Core 3.0 will expose SIMD instructions as API’s
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, vorona, Вы писали:
V>>[q].NET Core 3.0 will expose SIMD instructions
K>Опомнились Если вирт.машину проектировать грамотно, эти инструкции должны были генерироваться ещё в .NET 1.0;
Проблема не в Il коде, а в Jit ере. В .Net Native они могут сколько угодно тратить время на компиляцию в нативный код,
а вот Jit идет по пути наименьшего сопротивления, то есть тратит по минимуму времени. Вот RyuJit они и оптимизируют
и солнце б утром не вставало, когда бы не было меня
Re: .NET Core 3.0 will expose SIMD instructions as API’s
.NET Core 3.0 will expose SIMD instructions as API’s that are available to managed code directly, making it unnecessary to use native code to access them.
V>
Новость супер. Нужно будет планировать переход на него. Где-то через год после выхода. Так как со старта, я думаю, багов будет не меряно.
Здравствуйте, Serginio1, Вы писали:
K>>Опомнились Если вирт.машину проектировать грамотно, эти инструкции должны были генерироваться ещё в .NET 1.0;
S>а вот Jit идет по пути наименьшего сопротивления, то есть тратит по минимуму времени
Внимание, правильный вопрос: А ЧТО МЕШАЕТ взять и один раз сделать "медленно и хорошо"?! Жаба была на рынке уже тысчу лет, проблемы "тормозов" знали все. Более того — сама же M$ кэширует исполнимые модули! Ну так вместо своей бестолковой MSI системы (которая тратит кучу времени на перетасовывание файлов) они бы лучше воткнули компилер! Ты запускаешь сетап, а пока он распаковывает файлы, параллельный процесс их канпеляет в хорошие, оптимизированные модули. В результате имеем те же MSIL->EXE, но куда более оптимальные — неужели надо быть семи пядей во лбу для этого?!
Re[4]: .NET Core 3.0 will expose SIMD instructions as API’s
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
K>>>Опомнились Если вирт.машину проектировать грамотно, эти инструкции должны были генерироваться ещё в .NET 1.0;
S>>а вот Jit идет по пути наименьшего сопротивления, то есть тратит по минимуму времени
K>Внимание, правильный вопрос: А ЧТО МЕШАЕТ взять и один раз сделать "медленно и хорошо"?! Жаба была на рынке уже тысчу лет, проблемы "тормозов" знали все. Более того — сама же M$ кэширует исполнимые модули! Ну так вместо своей бестолковой MSI системы (которая тратит кучу времени на перетасовывание файлов) они бы лучше воткнули компилер! Ты запускаешь сетап, а пока он распаковывает файлы, параллельный процесс их канпеляет в хорошие, оптимизированные модули. В результате имеем те же MSIL->EXE, но куда более оптимальные — неужели надо быть семи пядей во лбу для этого?!
Здравствуйте, _NN_, Вы писали:
_NN>То бишь NGen которым и пользуются в установщике ?
Ну если SIMD ввели только сейчас, то НЕТ. NGen слишком убогий, чтобы выдавать идеальный код. Но идея правильная — можно и при инсталляции, можно перед первым запуском — Я ГОТОВ подождать 10 минут, пока вся программа не превратится в "идеальный экзешник" Со всеми кодами, которые присутствуют на моём CPU.
Re[6]: .NET Core 3.0 will expose SIMD instructions as API’s
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, _NN_, Вы писали:
_NN>>То бишь NGen которым и пользуются в установщике ?
K>Ну если SIMD ввели только сейчас, то НЕТ. NGen слишком убогий, чтобы выдавать идеальный код. Но идея правильная — можно и при инсталляции, можно перед первым запуском — Я ГОТОВ подождать 10 минут, пока вся программа не превратится в "идеальный экзешник" Со всеми кодами, которые присутствуют на моём CPU.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
K>>>Опомнились Если вирт.машину проектировать грамотно, эти инструкции должны были генерироваться ещё в .NET 1.0;
S>>а вот Jit идет по пути наименьшего сопротивления, то есть тратит по минимуму времени
K>Внимание, правильный вопрос: А ЧТО МЕШАЕТ взять и один раз сделать "медленно и хорошо"?! Жаба была на рынке уже тысчу лет, проблемы "тормозов" знали все. Более того — сама же M$ кэширует исполнимые модули! Ну так вместо своей бестолковой MSI системы (которая тратит кучу времени на перетасовывание файлов) они бы лучше воткнули компилер! Ты запускаешь сетап, а пока он распаковывает файлы, параллельный процесс их канпеляет в хорошие, оптимизированные модули. В результате имеем те же MSIL->EXE, но куда более оптимальные — неужели надо быть семи пядей во лбу для этого?!
Суть, то в том, что многое сделано на отображении, а значит нужна динамическая компиляция.
Для всего другого есть .Net Native. Видно они на него и сделали ставку. Ну и на ryujit
и солнце б утром не вставало, когда бы не было меня
Re: .NET Core 3.0 will expose SIMD instructions as API’s
.NET Core 3.0 will expose SIMD instructions as API’s that are available to managed code directly, making it unnecessary to use native code to access them.
V>
К слову, часть SIMD уже вполне юзабельна "здесь и сейчас" в .NET Core 2.0+ в System.Numerics.Vectors
Re[3]: .NET Core 3.0 will expose SIMD instructions as API’s
Здравствуйте, Serginio1, Вы писали:
S>а вот Jit идет по пути наименьшего сопротивления, то есть тратит по минимуму времени. Вот RyuJit они и оптимизируют
Уже нет. В Core 3 будет что то вроде джавовского hotspot
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Жаба была на рынке уже тысчу лет, проблемы "тормозов" знали все. Более того — сама же M$ кэширует исполнимые модули! Ну так вместо своей бестолковой MSI системы (которая тратит кучу времени на перетасовывание файлов) они бы лучше воткнули компилер! Ты запускаешь сетап, а пока он распаковывает файлы, параллельный процесс их канпеляет в хорошие, оптимизированные модули. В результате имеем те же MSIL->EXE, но куда более оптимальные — неужели надо быть семи пядей во лбу для этого?! 
