Камнем преткновения для фон Неймановской архитектуры является работа с массивом данных: проверка значений, суммирование, произведение элементов. Данное действие требует организации цикла от первого элемента до последнего. В любом цикле обязательно присутствуют накладные расходы: вычисление адреса следующего элемента, изменение и проверка счётчика. Кроме того, если архитектура процессора не поддерживает циклы на микропрограммном уровне, то приходится каждую команду цикла считывать из памяти или кэша, декодировать и выполнять. КПД такого процесса может быть довольно низким. Единственный плюс — это длина кода программы. Всего несколько байт для любого размера массива.
Для процессоров, работающих с векторами, накладные расходы ниже. Количество циклов уменьшается в N раз, где N — количество одновременно обрабатываемых элементов массива. Однако, проблему это не снимает. Да ещё добавим расходы на границу массива, если число элементов не укладывается целое число раз в вектор процессора.
Для уменьшения накладных расходов можно было бы обрабатывать элементы массива как свободные переменные, то есть составить программу, которая обрабатывала бы элементы попарно, потом результаты попарно и т.д. Но такой способ возможен только для фиксированного размера массива. Да и размер программы может оказаться значительным.
Однако последний способ или его модификация больше подходит для многоядерных архитектур, где можно было бы организовать обработку массива частями на разных ядрах или процессорах параллельно. Но здесь опять проявится ограничение в компиляции программы. Если размер массива динамически изменяется, то сложно или невозможно будет автоматически распараллеливать его обработку на разные ядра. Программа имеет фиксированное число команд и указателей. Или придётся разрешить модификацию программного кода. Что очень чревато.
А вот теперь обратимся к мультиклеточному процессору. Рассматривалась ли авторами процессора идея «мультикоманды»? Что я имею в виду. Это обычная машинная команда или группа команд, но она имеет динамический повторитель. В коде программы она занимает несколько байт, а во время исполнения программы дублируется в буфер команд заданное количество раз в зависимости от длины обрабатываемого массива. Дублировать можно сразу всю последовательность, что нецелесообразно, а можно сделать столько копий, сколько клеток в процессоре или даже ограничить количеством клеток, которые участвуют в этой программе. Каждую копию этой команды может обрабатывать своя клетка совершенно независимо и параллельно.
Понятно, что каждая последующая копия команды обрабатывает следующий или следующие элементы массива своей клеткой. Этот механизм почти избавлен от накладных расходов на организацию циклов, не увеличивает размер компилированной программы, позволяет распараллелить обработку элементов массива на любое число клеток процессора. Кроме того, одна из клеток будет выполнять крайнюю операцию обработки массива и отслеживать необходимость дальнейшей обработки. При достижении требуемых условий, действия с массивом можно прекратить. Конечно, выбор и местоположение мультикоманды и команды завершения определит компилятор, а дублировать команду будет уже процессор.
Если нет патентов и публикаций данной идеи. Этой публикацией я заявляю на неё авторское право от 17 мая 2015 года.
В данный момент автор публикации готов принять предложение работы.
Для процессоров, работающих с векторами, накладные расходы ниже. Количество циклов уменьшается в N раз, где N — количество одновременно обрабатываемых элементов массива. Однако, проблему это не снимает. Да ещё добавим расходы на границу массива, если число элементов не укладывается целое число раз в вектор процессора.
Для уменьшения накладных расходов можно было бы обрабатывать элементы массива как свободные переменные, то есть составить программу, которая обрабатывала бы элементы попарно, потом результаты попарно и т.д. Но такой способ возможен только для фиксированного размера массива. Да и размер программы может оказаться значительным.
Однако последний способ или его модификация больше подходит для многоядерных архитектур, где можно было бы организовать обработку массива частями на разных ядрах или процессорах параллельно. Но здесь опять проявится ограничение в компиляции программы. Если размер массива динамически изменяется, то сложно или невозможно будет автоматически распараллеливать его обработку на разные ядра. Программа имеет фиксированное число команд и указателей. Или придётся разрешить модификацию программного кода. Что очень чревато.
А вот теперь обратимся к мультиклеточному процессору. Рассматривалась ли авторами процессора идея «мультикоманды»? Что я имею в виду. Это обычная машинная команда или группа команд, но она имеет динамический повторитель. В коде программы она занимает несколько байт, а во время исполнения программы дублируется в буфер команд заданное количество раз в зависимости от длины обрабатываемого массива. Дублировать можно сразу всю последовательность, что нецелесообразно, а можно сделать столько копий, сколько клеток в процессоре или даже ограничить количеством клеток, которые участвуют в этой программе. Каждую копию этой команды может обрабатывать своя клетка совершенно независимо и параллельно.
Понятно, что каждая последующая копия команды обрабатывает следующий или следующие элементы массива своей клеткой. Этот механизм почти избавлен от накладных расходов на организацию циклов, не увеличивает размер компилированной программы, позволяет распараллелить обработку элементов массива на любое число клеток процессора. Кроме того, одна из клеток будет выполнять крайнюю операцию обработки массива и отслеживать необходимость дальнейшей обработки. При достижении требуемых условий, действия с массивом можно прекратить. Конечно, выбор и местоположение мультикоманды и команды завершения определит компилятор, а дублировать команду будет уже процессор.
Если нет патентов и публикаций данной идеи. Этой публикацией я заявляю на неё авторское право от 17 мая 2015 года.
В данный момент автор публикации готов принять предложение работы.
