Что может звуковая карта

[R9UHN]

Написание многопоточных приложений в то время не требовалось

Это как сказать. В BeOS это было фишкой.
Изначально два процессора закладывалось.
И прочие всякие DSP
Другое дело что бабло победило.
Маркетинг , маму его

[sgk]

Вернулся к версии W10 home. Пробовал не устанавливать драйвер видеокарты, время выполнения нестабильно от 9 до 20 мс. Установил драйвер видеокарты от AMD, время выполнения меняется на десятые доли секунды.

Сергей, если приложение изначально написано "в одну нитку", то больше одного ядра оно занять не может, отсюда и результат.

Первый собранный компьютер был с памятью 16 кБ (1986 год РК-86) и скорость выполнения операций 10 (десять) умножений в секунду под интерпретатором Бейсика. Сейчас 16 ГБ в миллион раз больше и быстродействие ПК в миллионы выше. По аналогии, может и современные программы могут оптимизировать "старое" ПО для использования ресурсов современных процессоров.

[vlad51]

А исходный код программы не нужен при этом, распраллеливание вычислений будет уже в экзешнике?

Писать программу придётся заново ИМХО

[vadim_d]

современные программы могут оптимизировать "старое" ПО

Тут очевидный путь - переписать с использованием многопоточности, но это требует исходников. Какого-то анализатора исполняемого кода на предмет его модификации с распараллеливанием операций там, где это возможно, я не видел, и вряд ли он понадобится - разработчики переписывают в первую очередь свой код, чтобы повысить его конкурентоспособност ь, думать о чужом екзешнике времени нет . Попадались ссылки на опенсорсный (или просто бесплатный?) анализатор, даже не пробовал, может что-то доведут до совершенства

скорость выполнения операций 10 (десять) умножений в секунду под интерпретатором Бейсика

Так вот и виден путь ПО: ОС в виде интерпретатора одного языка, одна программа в одно время, потом CP/M-80 как стандарт ОС на этот процессор, компиляторы под многие языки, но все еще однозадачность, MS-DOS - следующий процессор, а так все то же, разве что добавились программы TSR, которые оставались в памяти и продолжали работу, драйвер русской раскладки клавиатуры так делал, намек на многозадачность. Дальше - Windows, исходно многозадачный, и линукс тоже, но ядро пока было одно, и только с появлением многоядерных CPU многопоточность приложений довели до стандартных функций в языках программирования

[Леонид3]

Создать несколько потоков в программе просто, а вот предусмотреть, чтобы они не обращались к одним данным одновременно гораздо труднее, всё равно приходится их (потоки) синхронизировать. Маленькая программка для опыта

[Слушатель эфира]

Возникает вопрос

Сейчас у Сергея чуть не 20 кадров в секунду - кино, однако

а зачем больше и что это даст?
Ну вот подкрутили мы что-то в схеме, чтобы увидеть окончательный результат подкрутки нам надо получить полный набор новых данных от ЗК для пересчёта. Это время мы ведь не можем уменьшить.

[IG_58]

CP/M-80 как стандарт ОС на этот процессор, компиляторы под многие языки, но все еще однозадачность, MS-DOS - следующий процессор,

Вадим, Вы пропустили очень важный момент. Кроме однозадачной CP/M в те же славные времена для того же процессора существовала еще мультизадачная ISIS-II со своей экосисиемой. Это была реальная мультизадачность с реентерабельным кодом, с конкурирующими задачами, со своими компиляторами, линкером и локэйтором, специально для embedded. В CCCР ее портировали на несколько платформ, отличающихся только драйверами железа, для СМ-1800, для Электроники-К1 10/30, для МикроДат. Это только те платформы, которые мне известны (и для которых и под которые я лично писал много чего на PL/M-80 и на ASM80, даже удачно продал за хорошие деньги в один московский НИИ свой пакет автоматической реконфигурации комплекса технических средств). Система та была довольно популярна в узких кругах. И даже когда появились IBM-совместимые машины под Windows, в этой среде был кросс-платформенный пакет для разработки систем реального времени под ISIS-II. Система просуществовала вплоть до второй половины 90-х годов. До сих пор помню, как меня, молодого-зеленого, мордой тыкали в листинги, когда я для изделия написал нереентерабельный код в среде CP/M


Леонид3, их не синхронизировать, а диспетчеризировать надо, и код должен быть реентерабельным. Диспетчер ядра работает по прерываниям, генерируемым событиями во внешней среде и по меткам системного таймера, создаётся конкурентная многозадачная операционная среда, в которой задачи имеют различные приоритеты и конкурируют между собой за ресурсы машины. В каждый момент времени работает только 1 наиболее приоритетная и готовая к выполнению задача. Она прерывает исполнение менее приоритетной задачи, отбирает у нее процессор и сохраняет контекст этой задачи в ее собственном стеке. После обслуживания события эта задача отдаёт процессор следующей по иерархии задаче, восстанавливая из стека ее контекст и т.д.

[sgk]

Программа спектрального анализа "Осциллометр", частота дискретизации 192 кГц, измерение спектра сигнала и спектра фазовых шумов сигнала.
В таблице зависимость времени выполнения от количества точек для БПФ.

[vadim_d]

существовала еще мультизадачная ISIS-II со своей экосисиемой

Вот вспоминаю ее в советском исполнении на 80-м процессоре, но сколько помню, за раз запускалась одна программа, разрабатывать в ней можно было что угодно, и я под CP/M-80 как-то наваял на ассемблере систему с сопрограммами, переключавшимися по вызову монитора в embedded системе, несколько лет назад, когда вспоминали былое, кто-то сказал, что Микриум так сделан . Речь немного о другом - разбивке одного алгоритма (процесса) на несколько вычислительных ядер, тут обычно приходится сильно задумываться и об оптимизации доступа к памяти, когда у ядер есть локальная память с более быстрым доступом, и о синхронизации. А на комп с ISIS-II своим коллегам я поставил еще и CP/M-80, поскольку железо было цельнотянутым, а дисплейный драйвер сделал как у Роботрона-1715, так что все игрушки под него там весело бежали. Когда к ним кто-нибудь приезжал в командировку и видел беготню в лабиринте на экране, то замирали в недоумении

[AlexanderT]

приходится сильно задумываться и об оптимизации доступа к памяти

Наконец это прозвучало! Вспомним пришествие четвёртого пентиума, доступ к памяти был разделён на два канала и это позволило получить резкий прирост производительности на одном вычислительном ядре. Возьмём типичную на сегодня конфигурацию, это четыре ядра как минимум, а доступ к памяти как был двух канальным так и остался, получается ядра получают доступ к ОЗУ по очерёдности, что не просто шаг назад по сравнению с Р4 а два шага назад.