Мemory mapped file — это такой персональный кусочек свопа, ос выделяет сегмент и мапит его виртуальную память на диск. Как клиент будет работать с этой памятью ос не знает и потому действует довольно консервативно. Скорость чтения из него ограничена физическими возможностями диска.
В этом смысле клиенту выгоднее самому распоряжаться файловым хранилищем т.к. он то знает какая у него политика чтения/записи, где надо кэш побольше, а что сразу сбрасывать можно. Т.е. клиент потенциально организует файловое хранилище более эффективно, чем ОС.
В вашем случае клиент не распоряжается политикой распределения виртуального адресного пространства, а система распоряжается, но понятия не имеет как было бы оптимальнее с точки зрения клиента.
Можно подумать лишь о том, как более эффективно использовать дисковый кэш при чтении из свопа.
Ну… упомянутые вами специальные методики тоже должен кто-то составлять.
Глаз ловит закономерности, которые и описать то трудно.
И да, быть любознательным это не так уж и плохо, даже если и антинаучно.
Если я правильно понял, имеются ввиду затраты на переключение потоков.
Вытеснение потока очень дорогая операция уже хотя бы потому,
что скорее всего произойдет полное вытеснение его данных из кэша.
Данные высокоприоритетных потоков можно было бы не вытеснять,
но увы, кэширование ведется в физических адресах.
С другой стороны, если переключение происходит 1000 раз в секунду на ядро при
частоте в 1Ггц, несколько тысяч потерянных тактов составят всего-лишь несколько процентов потерянной производительности.
Этот продукт эксплуатирует другую идею — раз стековый процессор такой простой, давайте наделаем их целую кучу на одном кристалле и посмотрим что из этого получится.
А еще раньше были транспьютеры.
А еще раньше машиносчетные станции :)
На мой взгляд это продукт.с очень узкой экологической нишей.
Всё что касается памяти ограничено в размерах.
В данной статье скорее делалось сравнение — вот есть 100млн мелких файлов, что нам может предложить штатная
файловая система и можно ли сделать это быстрее.
Ключевая мысль — пользовательская структура файловой системы это часть данных а не часть архитектуры файловой системы.
Дерево — отличный объект, с которым умеют работать в базах данных.
Так давайте смотреть на файловую систему как на единое дерево где путь к файлу — ключ, а содержимое файла — значение в едином дереве.
Ну… я бы не назвал это моим подходом, но да, желание протащить параллелизм от компилятора в АЛУ давно уже витает в воздухе.
Стек мне всё же представляется менее вымученным способом.
Здравствуйте!
С Мультиклетом дотошно не разбирался, первое впечатление… неоднозначное.
Общий коммутатор мне не нравится, как эффективно всё это компилировать не очень понятно.
Но может это просто первое впечатление.
Видимо, мне следовало более внятно написать о цели статьи,
а именно (уже писал выше), ответить на вопрос можно ли на суперскалярном ядре написать такой код для простого суммирования массива, что при любом (масштабируемом) числе независимых функциональных устройств они будут использованы по максимуму.
А я хочу синергии и пытаюсь оптимизировать сразу пару компилятор/архитектура.
И в этой мутной водичке стараюсь сохранить (условную) простоту и того и другого.
Про любую архитектуру я тоже не говорил :)
А так да.
Но в данной статье рассматривается лишь вопрос об устранении зависимостей при суммировании.
Зависимость в данных такая штука, что если она есть, её не объедешь ни на одной архитектуре.
А за счет алгебраических преобразований кое что сделать можно.
Да, я знаю, современные компиляторы умеют пользоваться алгебраическими преобразованиями.
Но в рамках целевой архитектуры.
А хочется универсальности.
SIMD не предлагать :)
Я нигде не говорил об универсальности,
локальная задача, локальное решение.
С одной стороны. А с другой — весьма распространенный вид зависимостей по данным.
Сумма да произведение — вот и вся арифметика :)
«Единственный способ в современном мире» избавиться от парадигм — не использовать парадигмы :)
Вот конкретно описанный метод вычисления суммы пирамидкой даёт такую формальную возможность.
Моя вина — не донес основную мысль
Эта статья не о том, как улучшить кодогенерацию под конкретный процессор еще на 1%.
А скорее интерес пощупать возможную синергию между (абстрактными) компилятором и процессором.
Вот спарк — замечательны процессор, у него масштабируемое к-во регистров, в определенных (и нетривиальных) случаях код может обходиться без обращения к памяти. Но довеском идет и ряд проблем.
В epic в добавок еще пытаются масштабировать функциональные устройства. Результат тоже пока не очень.
Регистровая архитектура — замечательная концепция, позволяющая компилятору быстро выдавать почти идеальный код.
Суперскалярный процессор — отличная идея, увы, производительность упирается во внутреннюю сложность.
Технологические возможности производителей процессоров выше способности их (возможности) переварить, что странно.
Возможности компиляторов упираются в особенности архитектур и их сложность тоже начинает расти непропорционально полезному результату.
Я утрирую, конечно, и тем не менее.
Вот у меня есть мысль и я её думаю :)
Мысль о том, как подать суперскалярному ядру уже частично размеченный зависимостями код.
Так что я пишу потихоньку простой компилятор, виртуальную машину к нему.
А данная статья побочный эффект, что-ли. Еще раз извиняюсь, что не выделил основной вопрос.
Он в том, можно ли на суперскалярном ядре написать такой код для простого суммирования массива, что
при любом (масштабируемом) числе независимых функциональных устройств они будут использованы по максимуму.
Проблема, как она мне видится, не в том, что компилятор не умеет выдавать оптимальный код.
В конкретном описанном случае переплюнуть векторное суммирование принципиально невозможно.
А теперь представим, что программа скомпилирована под avx2, а исполняться будет на avx512 или avx1024.
Изначально вопрос был: а можно ли, скомпилировать один раз, а потом использовать на более новых процессорах максимально эффективно.
Похоже, что можно, пусть практическая ценность вот прямо сейчас минимальна, но важна ведь идея.
В этом смысле клиенту выгоднее самому распоряжаться файловым хранилищем т.к. он то знает какая у него политика чтения/записи, где надо кэш побольше, а что сразу сбрасывать можно. Т.е. клиент потенциально организует файловое хранилище более эффективно, чем ОС.
В вашем случае клиент не распоряжается политикой распределения виртуального адресного пространства, а система распоряжается, но понятия не имеет как было бы оптимальнее с точки зрения клиента.
Можно подумать лишь о том, как более эффективно использовать дисковый кэш при чтении из свопа.
Глаз ловит закономерности, которые и описать то трудно.
И да, быть любознательным это не так уж и плохо, даже если и антинаучно.
Вытеснение потока очень дорогая операция уже хотя бы потому,
что скорее всего произойдет полное вытеснение его данных из кэша.
Данные высокоприоритетных потоков можно было бы не вытеснять,
но увы, кэширование ведется в физических адресах.
С другой стороны, если переключение происходит 1000 раз в секунду на ядро при
частоте в 1Ггц, несколько тысяч потерянных тактов составят всего-лишь несколько процентов потерянной производительности.
А еще раньше были транспьютеры.
А еще раньше машиносчетные станции :)
На мой взгляд это продукт.с очень узкой экологической нишей.
В данной статье скорее делалось сравнение — вот есть 100млн мелких файлов, что нам может предложить штатная
файловая система и можно ли сделать это быстрее.
Ключевая мысль — пользовательская структура файловой системы это часть данных а не часть архитектуры файловой системы.
Дерево — отличный объект, с которым умеют работать в базах данных.
Так давайте смотреть на файловую систему как на единое дерево где путь к файлу — ключ, а содержимое файла — значение в едином дереве.
Стек мне всё же представляется менее вымученным способом.
С Мультиклетом дотошно не разбирался, первое впечатление… неоднозначное.
Общий коммутатор мне не нравится, как эффективно всё это компилировать не очень понятно.
Но может это просто первое впечатление.
а именно (уже писал выше), ответить на вопрос можно ли на суперскалярном ядре написать такой код для простого суммирования массива, что при любом (масштабируемом) числе независимых функциональных устройств они будут использованы по максимуму.
И в этой мутной водичке стараюсь сохранить (условную) простоту и того и другого.
А так да.
Но в данной статье рассматривается лишь вопрос об устранении зависимостей при суммировании.
Зависимость в данных такая штука, что если она есть, её не объедешь ни на одной архитектуре.
А за счет алгебраических преобразований кое что сделать можно.
Да, я знаю, современные компиляторы умеют пользоваться алгебраическими преобразованиями.
Но в рамках целевой архитектуры.
А хочется универсальности.
SIMD не предлагать :)
локальная задача, локальное решение.
С одной стороны. А с другой — весьма распространенный вид зависимостей по данным.
Сумма да произведение — вот и вся арифметика :)
Вот конкретно описанный метод вычисления суммы пирамидкой даёт такую формальную возможность.
Вопрос не в этом. Подробнее написал выше.
Эта статья не о том, как улучшить кодогенерацию под конкретный процессор еще на 1%.
А скорее интерес пощупать возможную синергию между (абстрактными) компилятором и процессором.
Вот спарк — замечательны процессор, у него масштабируемое к-во регистров, в определенных (и нетривиальных) случаях код может обходиться без обращения к памяти. Но довеском идет и ряд проблем.
В epic в добавок еще пытаются масштабировать функциональные устройства. Результат тоже пока не очень.
Регистровая архитектура — замечательная концепция, позволяющая компилятору быстро выдавать почти идеальный код.
Суперскалярный процессор — отличная идея, увы, производительность упирается во внутреннюю сложность.
Технологические возможности производителей процессоров выше способности их (возможности) переварить, что странно.
Возможности компиляторов упираются в особенности архитектур и их сложность тоже начинает расти непропорционально полезному результату.
Я утрирую, конечно, и тем не менее.
Вот у меня есть мысль и я её думаю :)
Мысль о том, как подать суперскалярному ядру уже частично размеченный зависимостями код.
Так что я пишу потихоньку простой компилятор, виртуальную машину к нему.
А данная статья побочный эффект, что-ли. Еще раз извиняюсь, что не выделил основной вопрос.
Он в том, можно ли на суперскалярном ядре написать такой код для простого суммирования массива, что
при любом (масштабируемом) числе независимых функциональных устройств они будут использованы по максимуму.
А как же ANSI — совместимость?
В конкретном описанном случае переплюнуть векторное суммирование принципиально невозможно.
А теперь представим, что программа скомпилирована под avx2, а исполняться будет на avx512 или avx1024.
Изначально вопрос был: а можно ли, скомпилировать один раз, а потом использовать на более новых процессорах максимально эффективно.
Похоже, что можно, пусть практическая ценность вот прямо сейчас минимальна, но важна ведь идея.