Средства и методы разработки

Мой пространный комментарий по этому поводу: Это продолжение стратегии - монстров клепать :). Между тем, своей популярностью компьютеры архитектуры x86 обязаны "среднему классу" пользователей, составляющих целую армию их потребителей. Да и в чисто культурном отношении освоение ПК заметно двигало прогресс вперед, повышая планку требований к интеллекту. Не секрет, что заметная часть юношества была увлечена компьютерами, несмотря на то, что большинство из них составляли геймеры. Т.к. даже будучи геймерами, они довольно сносно представляли работу компьютеров и разбирались в качестве компьютерного железа. Затем, вместе с лавинообразным распространением "носимых гаджетов" этот уровень резко упал - большинство мигрировало на смартфоны, обращение с которыми было много проще. На фоне этой эпидемии дебилизма производители компьютерного железа расслоились между мобилостроением и монтростроением, т.к. "средний класс" покупателей сильно поредел. И вот сейчас мы пожинаем плоды этого расслоения. А именно, процессоры развиваются не в сторону увеличения производительности, а преимущественно в сторону энергосбережения. Причем, при возникновении конфликта между этими тенденциями (а он и не может не возникнуть), энергосбережение побеждает. Отсюда и нашествие многоядерных процессоров по частоте едва дотягивающих до 2 ГГц, либо несильно эту частоту превосходящих. Т.е. та увлекательная гонка за частоту, приведшая в свое время к появлению Pentum-4, закончилась грустно - срезали не только частоту у процессоров, то и интеллект у потребителей. Сейчас частоты потихоньку (ну очень потихоньку!) поднимаются, но лишь за счет перехода на предельно мелкий техпроцесс, позволяющий за счет пониженного напряжения питания разгонять процессоры до больших частот, не опасаясь перегрева. В данном случае энергосбережение поддержало своего конкурента. Между тем, становится совершенно ясным, что какой-то гигантский суперпроцессор в общем-то и не нужен. Для среднего пользователя он оглушительно дорог, а потому и неэффективен в использовании. Тогда как в крупных корпорациях вполне можно было обойтись многопроцессорными системами (в том числе и кластерами) и обычных процессоров. Т.е. бизнес-задачи по своему уровню гораздо примитивнее тех же игровых задач, а потому ориентация на производство "процессоров для бизнеса" рассчитано только на то, что богатенькие Буратино будут в состоянии отвалить за вычислительный комплекс большую деньгу, не поморщившись. Именно этим объясняется эпопея с Itanium, который своих денег попросту не стоил, а был лишь психологическим приемом выуживания денег из богатого, но доверчивого потребителя. Отсюда и интерес производителей к тому, чтобы расширять пропасть (или ее внешнюю видимость) между компьютерами эконом-класса и бизнес-класса, позволяющая им строить все новые Itanium'умы. Поэтому маркетологи боятся этого AVX-512, как огня, т.к. по своей сути это предельно дешевое технологическое решение. В самом деле, если клепать новые ядра не западло, то отчего бы не удлинить векторный регистр, если на архитектуру это никак не усложняет? Да и операции в старшей половине этого регистра выполняются параллельно, младшей половине не мешая. Очевидно, что этот регистр(ы) можно было бы с тем же успехом удлинить даже до 1024 бита с минимальными изменениями структуры процессора. Однако тогда производительность компьютеров эконом-класса резко вырастет, и не на 5%, а в разы, чего по маркетинговым целям совершенно ни к чему. Отсюда и это бесконечное оттягивание вступления AVX-512 в силу, хотя совершенно очевидно, что необходимости перехода на 10 нм это не создает. В этом смысле было бы крайне полезно, если бы AMD своим ZEN'ом влупило бы полноценную векторную арифметику, тем более что этим она уже грозилась. Вплоть до введения команд для вектора произвольной длины, что позволило бы, не меняя системы команд, выпускать процессоры, как с более длинными векторными регистрами, так и с более короткими, в зависимости от запросов потребителей. Что касается "ништяков" под AVX-512, но к настоящему времени все они уже есть, т.к. были опробованы на сопроцеcсорах Xeon Phi, выпущенных ранее. Например, последняя версия Матлаба использует библиотеку MKL (в бинарном виде), которая поддерживает AVX-512 еще со времени появления первого Xeon Phi. Конечно, с каждой следующей версией что-то еще подчищается по части оптимизации специально под AVX-512, однако уже того, что есть, за глаза достаточно. Впрочем, я точно не знаю, в каких случаях Матлаб пользуется этой библиотекой, т.к. помимо нее, у него сохранились и свои собственные алгоритмы для того же типа расчетов, которые появились еще до внедрения MKL. Однако MKL имеет то преимущество, что она всеядна - имея в своем наборе отдельные примитивы для процессоров разного типа, она по ходу дела (при выполнении первой же функции) разбирается с тем, на каком процессоре она запущена, и динамически прилинковывает к себе dll-модуль с соответствующими ему примитивами. Соглашусь, что все эти СкайЛайки, КабиЛайки, КофеЛайки практически на одно лицо. Технические изменения, отличающие одну версию от другой, в практическом плане почти незаметны. И те 5% производительности, которой они друг от друга отличаются, обусловлены в основном тактовой частотой, т.к. ресурсы распараллеливания при обработке потока инструкций фактически исчерпаны. Лично я вообще не считаю необходимым переход на 10 нм, т.к. разумные усовершенствования вполне можно сделать и на 14 нм. Вот и AMD свой ZEN тоже на 14 нм сделала. А разумным решением я считаю такое - лучше выбросьте лишнее ядро, но удлините векторные регистры!!! Потому что реального распараллеливания вычислительной задачи по всем ядрам сразу практически не бывает никогда. Что мы имеем на той же MKL в практическом плане? А вот что! Операция скалярного произведения двух векторов (dot), которая своей скоростью на 80% и более определяет скорость алгебраических расчетов, вообще не распараллеливается между ядрами, даже когда тех в избытке! А распараллеливание по ядрам происходит лишь в операции умножения на матрицу, когда векторная операция dot производится с каждой строкой этой матрицы. И вот только тут есть возможность распараллелиться, выполняя операции над разными строками на разных ядрах процессора. Причем, в современных операционных системах оперативно запустить процесс на другом ядре не так-то просто - масса времени уйдет на регистрацию этого процесса у операционной системы, не говоря уже о том, что операционная система крайне косо смотрит на попытки указать ей, на каком ядре запускать процесс - чаще такое указание бывает вообще не предусмотрено. Или остальные ядра могут быть заняты тем, что пинги гоняют по сети :), тогда как ОС может решить поставить все вычислительные процессы в очередь на одно и то же ядро. Скажем, меня бы вполне устроила возможность установить рабочему потоку максимальный приоритет, чтобы его ни одно прерывание от задачи не отвлекало. Понимаю, что на одноядерном процессоре такая операция опасна - все может зависнуть, вместе с ходом системного времени, но почему бы не дать такую возможность на многоядерной машине? Пусть какое-то время таймер и клавиатуру обслуживает какое-то другое ядро, не перебивая вычислительный процесс. Однако API такой возможности приложению не дает. Почему я сейчас об этом говорю? Да потому, что система распределения времени периодически переключает процессор с процесса на процесс по сигналу прерывания от системного таймера. А при каждом таком переходе приходится сохранять в памяти содержимое всех векторных регистров, а при возвращении восстанавливать их содержимое из памяти. Если раньше сохранялись лишь регистры FPU87 (совмещенные с MMХ), то новые векторные регистры SSE/AVX с ними не совмещаются, а потому приходится сохранять и то и другое сразу. А если AVX расширится до 512, то это еще сильнее усугубит эту проблему. Отсюда и мое желание иметь возможность "затолбить" процесс на том ядре, где он был запущен, не прерывать его до тех пор, пока обработка данной строки матрицы не будет завершена. Поясню, что в момент завершения функции dot выполняется команда vzeroupper, указующая, что верхняя часть AVX-регистров пуста и сохранять ее не надо. В противном случае выполнение команды vzeroupper без толку, т.к. прерывание от таймера придет посреди процедуры и начнет спасательную операцию. Это я веду разговор к тому, что уже сейчас можно было бы поднять скорость вычислений почти вдвое, если бы задачу можно было запустить на чем-то вроде DOS'а. :)