Julia: Рассмотрите возможность добавления `VecTuple {N, T}` для хранения N `VecElements {T}` s

Созданный на 14 мар. 2017 · 3Комментарии · Источник: JuliaLang/julia

Мне известно о существовании SIMD.jl. Однако я считаю, что генерация основного кода векторов SIMD должна поддерживаться более простым способом в самой базе Julia и скрывать некоторые детали в кортеже-оболочке, а не просто по базовому типу.

Таким образом, я предлагаю определить некий тип VecTuple{N,T} который по сути был бы эквивалентен текущему NTuple{N, VecElement{T}} . Разница будет в том, что свойства VecElement codegen будут применяться неявно, если это необходимо, но привязаны к кортежу, а не к элементу. Таким образом, доступ к отдельным элементам кортежа не требует дополнительного преобразования T <-> VecElement{T} . В настоящее время для доступа к одному элементу NTuple{N, VecElement{T}} требуется x[i].value вместо простого x[i] .

Кроме того, к специализированному кортежу будут привязаны требования к общему размеру и выравниванию типа или к тому, какие фундаментальные типы (с размером от 8 до 64) вообще разрешены. См. Также №20961.

Я не предлагаю добавлять все возможные операции с векторами SIMD в базу Юлии. Их определенно слишком много (подумайте о перетасовке, транспонировании или инвертировании). Пока все это можно оставить специализированным пакетам, просто изменив способ связывания самого фундаментального свойства кодогенерации LLVM с кортежем.

( VecTuple конечно, просто заполнитель для любого удобного имени по этому вопросу.)

simd speculative types and dispatch

Источник

m-j-w

Самый полезный комментарий

Одна из идей того, как действовать дальше, - это создать новый пакет, который описывает, что, по вашему мнению, должно входить в базу. Назовите это, например, SIMDBase . Затем мы можем перенаправить SIMD на этот пакет, что, если ваше предположение верно, упростит SIMD . Как только люди согласятся с функциональностью, предоставляемой SIMDBase , его можно будет перенести в Base.

Например, я был бы не против, если бы некоторые из низкоуровневых искажений вызова LLVM могли обрабатываться где-то еще.

eschnett 14 мар. 2017

👍2

Все 3 Комментарий

Напоминаем, что у нас нет VecTuple, поскольку Tuple не определен как тип абстрактного вектора, поэтому говорить о векторизованном кортеже - это частичное столкновение терминов.