Fortran IV на EC 1045 застал в десятом классе - ходил на спецкурс в один из институтов, реальная работа там уже шла на PCшках, ЕСку отдали на съедение школьникам, можно было развлекаться под Примусом в терминале. Хотя ещё за год до нас терминалами пользовались сотрудники, школьники на спецкурсе набивали код на перфокартах.
Я к тому, что реально (чтобы позволить дописать код в середину) строк в блоке не сто, а десять - это и для "детского" кода маловато. Уже не помню, что тогда писал (дело было в шестом классе в конце 80х), но тетрадный листок програмки занимали. Хотя нас тогда структурированию кода не учили - ладно хоть вообще дали доступ к компам, так то информатика была только в старших классах.
Ну вот с AVX512 были нюансы. Хотя оно на клиенте никогда нормально (с точки зрения производительности) не работало.
ниткам-воркерам выполняться с одинаковой скоростью может помешать масса причин
Но по факту на однородных задачах типа умножения плотных матриц статическое разбиение данных по потокам с привязкой потоков к ядрам даёт максимальное ускорение на одинаковых процессорах - динамическая балансировка добавляет оверхед и ухудшает локальность доступов к памяти. Эффективно параллелить счётный код на гибридной архитектуре - та ещё задача )
Учитывая, что обычно изначально код писался с шагом 10 - 1.10,1.20 и т.д. - чтобы при необходимости вставить инструкцию в середину, более-менее осмысленный кусок занимал несколько первых цифр.
В смысле в любом порядке? Там же чёткая нумерация, и без аналога renum надо было аккуратно нумеровать строчки с каким-то шагом. Ну и арифметический if в стиле фортрана не самая удобная вещь. Впрочем, для программок на страничку, которые на каждом занятии надо набирать заново, это не так критично.
Согласен. Но у меня большие сомнения, что даже с идеальным источником времени акселерометр даст достаточную точность, чтобы оценить положение с точностью до метра после нескольких часов хождения по лесу.
Время для интеграции тоже нужно (не обязательно абсолютное), но у меня тоже ощущение, что точность навигации скорее в погрешность акселерометра упрётся.
Существовали и проекты изоляций процессов на уровне файловой системы вроде jails и chroot, но это совсем другая история
На мой взгляд это часть той же истории - сначала в Unix v7 был chroot, потом в FreeBSD придумали более продвинутый jail, после в Linux его обобщили до namespaces, которые уже стали ключевым элементом реализации контейнеров в целом и Docker в частности.
Не все алгоритмы ложатся на GPU - и как раз реализовывать кастомные вещи типа той же арифметики повышенной точности там сложнее. Ну и в целом CPU не так уж отстают - на втором месте в Top500 до сих пор Fugaku вообще без акселераторов, просто Arm c SVE. Но согласен, во многих случаях GPU экономически оправданнее.
Fortran IV на EC 1045 застал в десятом классе - ходил на спецкурс в один из институтов, реальная работа там уже шла на PCшках, ЕСку отдали на съедение школьникам, можно было развлекаться под Примусом в терминале. Хотя ещё за год до нас терминалами пользовались сотрудники, школьники на спецкурсе набивали код на перфокартах.
PS Обновил у себя документ - немного поехали разделы, 2.1 конкретно про Сапфиры, 2.2 про гибрид, 2.3-2.6 - разные поколения P ядер.
Я к тому, что реально (чтобы позволить дописать код в середину) строк в блоке не сто, а десять - это и для "детского" кода маловато. Уже не помню, что тогда писал (дело было в шестом классе в конце 80х), но тетрадный листок програмки занимали. Хотя нас тогда структурированию кода не учили - ладно хоть вообще дали доступ к компам, так то информатика была только в старших классах.
Ну вот с AVX512 были нюансы. Хотя оно на клиенте никогда нормально (с точки зрения производительности) не работало.
Но по факту на однородных задачах типа умножения плотных матриц статическое разбиение данных по потокам с привязкой потоков к ядрам даёт максимальное ускорение на одинаковых процессорах - динамическая балансировка добавляет оверхед и ухудшает локальность доступов к памяти. Эффективно параллелить счётный код на гибридной архитектуре - та ещё задача )
Intel® 64 and IA-32 Architectures Optimization Reference Manual - ссылки на pdf сейчас идут с https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html . Раздел 2.2 и соседние про P, глава 4 про E, в 2.1 немного о том, как они вместе уживаются.
Числодробить лучше на серверных процессорах, до которых пока E ядра не добрались.
Учитывая, что обычно изначально код писался с шагом 10 - 1.10,1.20 и т.д. - чтобы при необходимости вставить инструкцию в середину, более-менее осмысленный кусок занимал несколько первых цифр.
Разве там после, скажем, 1.90, выполнение не проваливалось автоматом в 2.10 ?
Спасибо. Слова refresh уже достаточно, чтобы поколение заинкрементить...
Что то уже запутался с нумерацией - про эти 14xxxK Интел пишет "Products formerly RAPTOR LAKE". Всё таки каким codename'ам соответствуют 13 и 14?
В смысле в любом порядке? Там же чёткая нумерация, и без аналога renum надо было аккуратно нумеровать строчки с каким-то шагом. Ну и арифметический if в стиле фортрана не самая удобная вещь. Впрочем, для программок на страничку, которые на каждом занятии надо набирать заново, это не так критично.
Как раз Фокал на БК у меня был первым ЯВУ. Бейсик после него выглядел весьма продвинутым и элегантным )
Вот тут - https://github.com/rhobbie/Mkf2 - инструкции как найти и запустить.
Это уже додумывание, в статье никакие партнёры не упоминаются.
Согласен. Но у меня большие сомнения, что даже с идеальным источником времени акселерометр даст достаточную точность, чтобы оценить положение с точностью до метра после нескольких часов хождения по лесу.
Время для интеграции тоже нужно (не обязательно абсолютное), но у меня тоже ощущение, что точность навигации скорее в погрешность акселерометра упрётся.
В последние годы видел скорее локальные vbs файлы во всяческих внутрикорпоративных админских тулах, и подозреваю что этого добра осталось ещё немало.
Совсем разные ОС. Прикладной API более-менее похож, но ядро и архитектура в целом существенно отличаются.
На мой взгляд это часть той же истории - сначала в Unix v7 был chroot, потом в FreeBSD придумали более продвинутый jail, после в Linux его обобщили до namespaces, которые уже стали ключевым элементом реализации контейнеров в целом и Docker в частности.
А что говорят исследователи из Оксфорда?
Не все алгоритмы ложатся на GPU - и как раз реализовывать кастомные вещи типа той же арифметики повышенной точности там сложнее. Ну и в целом CPU не так уж отстают - на втором месте в Top500 до сих пор Fugaku вообще без акселераторов, просто Arm c SVE. Но согласен, во многих случаях GPU экономически оправданнее.