Вернулся к версии W10 home. Пробовал не устанавливать драйвер видеокарты, время выполнения нестабильно от 9 до 20 мс. Установил драйвер видеокарты от AMD, время выполнения меняется на десятые доли секунды.
Первый собранный компьютер был с памятью 16 кБ (1986 год РК-86) и скорость выполнения операций 10 (десять) умножений в секунду под интерпретатором Бейсика. Сейчас 16 ГБ в миллион раз больше и быстродействие ПК в миллионы выше. По аналогии, может и современные программы могут оптимизировать "старое" ПО для использования ресурсов современных процессоров.
Последний раз редактировалось sgk; 02.09.2020 в 22:48.
Тут очевидный путь - переписать с использованием многопоточности, но это требует исходников. Какого-то анализатора исполняемого кода на предмет его модификации с распараллеливанием операций там, где это возможно, я не видел, и вряд ли он понадобится - разработчики переписывают в первую очередь свой код, чтобы повысить его конкурентоспособност ь, думать о чужом екзешнике времени нет . Попадались ссылки на опенсорсный (или просто бесплатный?) анализатор, даже не пробовал, может что-то доведут до совершенства
Так вот и виден путь ПО: ОС в виде интерпретатора одного языка, одна программа в одно время, потом CP/M-80 как стандарт ОС на этот процессор, компиляторы под многие языки, но все еще однозадачность, MS-DOS - следующий процессор, а так все то же, разве что добавились программы TSR, которые оставались в памяти и продолжали работу, драйвер русской раскладки клавиатуры так делал, намек на многозадачность. Дальше - Windows, исходно многозадачный, и линукс тоже, но ядро пока было одно, и только с появлением многоядерных CPU многопоточность приложений довели до стандартных функций в языках программирования
Создать несколько потоков в программе просто, а вот предусмотреть, чтобы они не обращались к одним данным одновременно гораздо труднее, всё равно приходится их (потоки) синхронизировать. Маленькая программка для опыта
Вадим, Вы пропустили очень важный момент. Кроме однозадачной CP/M в те же славные времена для того же процессора существовала еще мультизадачная ISIS-II со своей экосисиемой. Это была реальная мультизадачность с реентерабельным кодом, с конкурирующими задачами, со своими компиляторами, линкером и локэйтором, специально для embedded. В CCCР ее портировали на несколько платформ, отличающихся только драйверами железа, для СМ-1800, для Электроники-К1 10/30, для МикроДат. Это только те платформы, которые мне известны (и для которых и под которые я лично писал много чего на PL/M-80 и на ASM80, даже удачно продал за хорошие деньги в один московский НИИ свой пакет автоматической реконфигурации комплекса технических средств). Система та была довольно популярна в узких кругах. И даже когда появились IBM-совместимые машины под Windows, в этой среде был кросс-платформенный пакет для разработки систем реального времени под ISIS-II. Система просуществовала вплоть до второй половины 90-х годов. До сих пор помню, как меня, молодого-зеленого, мордой тыкали в листинги, когда я для изделия написал нереентерабельный код в среде CP/M
Леонид3, их не синхронизировать, а диспетчеризировать надо, и код должен быть реентерабельным. Диспетчер ядра работает по прерываниям, генерируемым событиями во внешней среде и по меткам системного таймера, создаётся конкурентная многозадачная операционная среда, в которой задачи имеют различные приоритеты и конкурируют между собой за ресурсы машины. В каждый момент времени работает только 1 наиболее приоритетная и готовая к выполнению задача. Она прерывает исполнение менее приоритетной задачи, отбирает у нее процессор и сохраняет контекст этой задачи в ее собственном стеке. После обслуживания события эта задача отдаёт процессор следующей по иерархии задаче, восстанавливая из стека ее контекст и т.д.
Последний раз редактировалось IG_58; 03.09.2020 в 15:31.
Вот вспоминаю ее в советском исполнении на 80-м процессоре, но сколько помню, за раз запускалась одна программа, разрабатывать в ней можно было что угодно, и я под CP/M-80 как-то наваял на ассемблере систему с сопрограммами, переключавшимися по вызову монитора в embedded системе, несколько лет назад, когда вспоминали былое, кто-то сказал, что Микриум так сделан . Речь немного о другом - разбивке одного алгоритма (процесса) на несколько вычислительных ядер, тут обычно приходится сильно задумываться и об оптимизации доступа к памяти, когда у ядер есть локальная память с более быстрым доступом, и о синхронизации. А на комп с ISIS-II своим коллегам я поставил еще и CP/M-80, поскольку железо было цельнотянутым, а дисплейный драйвер сделал как у Роботрона-1715, так что все игрушки под него там весело бежали. Когда к ним кто-нибудь приезжал в командировку и видел беготню в лабиринте на экране, то замирали в недоумении
Спасибо от IG_58
Наконец это прозвучало! Вспомним пришествие четвёртого пентиума, доступ к памяти был разделён на два канала и это позволило получить резкий прирост производительности на одном вычислительном ядре. Возьмём типичную на сегодня конфигурацию, это четыре ядра как минимум, а доступ к памяти как был двух канальным так и остался, получается ядра получают доступ к ОЗУ по очерёдности, что не просто шаг назад по сравнению с Р4 а два шага назад.
Эту тему просматривают: 5 (пользователей: 0 , гостей: 5)