Любой серьёзный алгоритм работает с большими векторами/матрицами и ускорение от параллелизации не помешает.
и (в некоторых случаях) выполнения на разных конвейерах.
Ну да, соответственно в AVX512 у нас два векторных FMA за такт (на нормальном серверном процессоре), а в x87 - только отдельные скалярные сложения/умножения по одному за такт.
Сам не работал, общался с человеком, который подобным занимался (оно и в обратную сторону работает - в каких то случаях можно вместо обычного дабла использовать два сингла для улучшения скорости при похожей точности). Вот тут - https://arxiv.org/abs/2303.04353 - пишут, как использовать два дабла для улучшения точности (эффективно получается 106 бит на мантиссу, что всё равно лучше, чем extended double на x87).
выбор на этом заседании стоял между копированием оригинальной IBM/360 и… копированием копий(!) IBM/360!
Вот и я к этому. Но всё таки система команд это ещё не всё, так что различий (особенно в плане реальных шагов до получения работающей машины) было достаточно, что и видно из дискуссии - спасибо за текст!
С историей серии ЕС странности. Британская ICL System 4 - вроде как тоже клон IBM 360, так что непонятно, что изменилось настолько кардинально чтобы заставить Рамеева уйти из проекта.
Да просто комбинация сетки и GUI. В принципе если руками обрабатывать X11 протокол - то там те же сокеты и select() справится - но высокоуровневые библиотеки дадут свои API для ожидания событий без доступа к потрохам.
Давайте тогда конкретно. Расскажите, как в одном потоке без поллинга ждать события GUI от gtk и сетевые соединения. Я бы всё таки завёл на это отдельные потоки.
Если пользоваться микрософтовскими тулами - то отдельный исходник на MASM, реализующий вызываемые из C/C++ функции; насколько помню, поддержку инлайн ассемблера при компиляции под Win64 убрали. В gcc/clang можно и инлайн вставки делать.
Для умножения матриц и прочей линейной алгебры тоже неплохо работает )
Автовекторизация - дело тонкое, работает не всегда. Собственно, для этого часто и нужен ассемблер в наше время.
То есть обработать параллельно несколько FP64x2 чисел не получается?
Не уверен, что они в коде на C++ смогли эффективно запользовать векторные инструкции.
Любой серьёзный алгоритм работает с большими векторами/матрицами и ускорение от параллелизации не помешает.
Ну да, соответственно в AVX512 у нас два векторных FMA за такт (на нормальном серверном процессоре), а в x87 - только отдельные скалярные сложения/умножения по одному за такт.
Сам не работал, общался с человеком, который подобным занимался (оно и в обратную сторону работает - в каких то случаях можно вместо обычного дабла использовать два сингла для улучшения скорости при похожей точности). Вот тут - https://arxiv.org/abs/2303.04353 - пишут, как использовать два дабла для улучшения точности (эффективно получается 106 бит на мантиссу, что всё равно лучше, чем extended double на x87).
Я понял, и я именно о 128 бит на одно число.
x87 в 21ом веке? seriously? Подозреваю, что хорошая ручная реализация 128битных FP на AVX 512 будет побыстрее.
Запользовать, скажем, AMX для своего алгоритма, не покрытого MKL.
Вот и я к этому. Но всё таки система команд это ещё не всё, так что различий (особенно в плане реальных шагов до получения работающей машины) было достаточно, что и видно из дискуссии - спасибо за текст!
С историей серии ЕС странности. Британская ICL System 4 - вроде как тоже клон IBM 360, так что непонятно, что изменилось настолько кардинально чтобы заставить Рамеева уйти из проекта.
Да просто комбинация сетки и GUI. В принципе если руками обрабатывать X11 протокол - то там те же сокеты и select() справится - но высокоуровневые библиотеки дадут свои API для ожидания событий без доступа к потрохам.
В смысле? Просто в сишном коде, зависящем только от gtk и libc.
Давайте тогда конкретно. Расскажите, как в одном потоке без поллинга ждать события GUI от gtk и сетевые соединения. Я бы всё таки завёл на это отдельные потоки.
Когда я видел Turbo Vision, она работала в текстовом режиме MS DOS.
В принципе и на однобитном PC спикере можно было издавать практически произвольные звуки, когда то писал для себя проигрыватель WAV файлов под ДОС.
Ничего, всё вроде понятно ) Да, базовые 400/800 действительно ущербны - хотя с расширением до 48k уже можно жить.
Кстати, чем принципиально XL/XE отличались от более ранних 400/800?
В начале 90х многие знакомые писали под ДОС на Турбо Паскале в таком стиле )
Если пользоваться микрософтовскими тулами - то отдельный исходник на MASM, реализующий вызываемые из C/C++ функции; насколько помню, поддержку инлайн ассемблера при компиляции под Win64 убрали. В gcc/clang можно и инлайн вставки делать.
Сейчас скорее регистры (когда хватает) - стандарт, а стек - legacy на древних платформах типа 32-битного Интела )