Вы уверены, что доступ к вещественным и прочим SSE/AVX регистрам быстрее, чем к L1 cache?

Регистры обычно быстрее, чем память. А еще возможна ситуация, что всё вытиснилось из кэша и надо обращаться к оперативной памяти.

Тут два варианта: либо мы активно работаем со стеком, и тогда он в L1, либо он нам всё равно не нужен. 😊

Допустим, мы копировали один массив в другой и у нас в кэше нет уже этих данных, которые мы положили в стек. Обращение к памяти, может, допустим, занимать 1000 тактов процессора, а без обращения к стеку можно эти такты сэкономить.

Очень много предположений. 😊

Даже без этих предположений, почему бы не использовать другие доступные регистры, а так они просто будут простаивать. Какие здесь есть подводные камни? Один и вариантов, думаю может быть такой, что мы сохранили что-то в вещественных регистрах и после этого потребовалось сделать какую-то вещественную операцию, тогда надо эти данные оттуда куда-то в другое место копировать. А по поводу SSE какие могут быть проблемы?

Кроме того, что в SSE нормально загружаются только выровненные последовательные данные из памяти? В SSE-регистры из обычных копировать вообще можно?

емнип там были операции с невыровнеными данными

Да, но быстро работать они не будут. 😊

из обычных можно, movq (intel syntax)

тут похоже rustаманов много, а какие впечатления от Nim ? vs Rust?

У нима показался больно странный синтаксис, и кажется именование (методы/библиотеки/типы и т.д) не особо консистентное, но я им не особо пользовался. А раст прекрасен - как хаскель, только удобный и популярный (в вопросах либ, а не работы). Единственное фичи подтягиваются дольше, чем хотелось бы. Вроде бы те специализации вмержили в апстрим несколько лет назад, а все еще в стабильном компиляторе нет, и таких историй немалое множество.

+

Все сладости нестабильные

На самом деле и без них жить можно, у нас большой проект вполне себе на стейбле живет уже больше года

Про образование. Проблема в том, что каждый конкретный программист biased к своим любимым языкам, к своим любимым парадигмам, и считает, что учить надо именно так, чтобы максимизировать вовлечённость ученика в этот конкретный язык и парадигмы. Ответственный учитель должен абсолютно на 100% осознавать то, что он biased. Более того, он должен на 100% осознавать, почему он biased именно так, как biased, а не по-другому. Почему именно Haskell, а не Oberon. Иногда ответ может не понравится, но его нужно осознавать, чтобы своими ложными представлениями не заразить ученика. Ну, конечно, если у учителя уже нет тёплого местечка для таких учеников, которых он готовит под себя. Но тогда учитель должен честно объявлять о своих целях.

Например, если Вы начинаете учить человека со Схемы или Хаскеля, или Java, или Python, то он гарантированно получит огромные проблемы в понимании того, как работает железо, и для него работа на микроконтроллерах (а тема модная) будет очень долго казаться магией. У нас в универе такой эксперимент ставят на учащимися, и результат плачевен (с моей профессиональной точки зрения: люди могут идти в банки и кодить там, но запрограммировать простейший процесс на микроконтроллере или оптимизировать цикл для них - неподъёмная задача).

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

Мы ставим конкретную задачу, выбираем алгоритм решения, кодируем. При этом, нужно понимать, что для кодирования простых алгоритмов, и ассемблер может быть эффективным инструментом. Программистам обязательно нужно показывать, как именно работает машина.

Си - это не плохой язык программирования, это язык, абстрагирующий ассемблерные парадигмы программирования. И тем он хорош. Если бы я учил людей программированию с нуля, и если бы у меня была задача научить хорошего программиста, а не адепта своей Схемо-секты, я бы поступил так:

1. Изучение архитектуры машины и API операционки (занатия 3-4) и простейшие алгоритмы на ассемблере. Благо, есть QEMU, есть Dos-Box, можно запускать код.

2. Изучение более сложных алгоритмов: сортировка там, поиск в ширину, может быть (занятия 3-4). Программирование на Си со словами: вот смотрите, у нас в простых алгоритмах возникали циклы, ветвления, процедуры и подпрограммы. Смотрите, как это поднимается на уровень выше в удобном синтаксисе. Считайте, что после этого у человека сразу отпадают проблемы с кучей языков императивного семейства, потому что идиомы примерно одинаковы. Синтаксис не важен!

3. Дальше можно ветвиться (на ФП или на ООП, кому как нравится; благо JS позволяет писать в обоих стилях), поднимая степень сложности задач. Здесь бы я прошёл SICP уже на том языке, на котором нравится учителю. SICP прекрасен тем, что он учит кодировать различные алгоритмические структуры (может и HtDP учит, но я не читал).

Со словами: вот видите, как мы на Си уделяли кучу времени деталям управления памятью, бла-бла-бла, но это не всегда рационально. Если нужно разработать сложную систему, можно взять более мощный язык, с более мощными парадигмами, и писать гораздо более сложный код быстрее. При чём, парадигмы нужно объяснять с переводом на ассемблер, чтобы люди понимали, насколько так или иная конструкция дорогая и уместная. Чтобы, например, не было иллюзий, что ленивый map (без оптимизаций) быстрее, чем энергичный map через reverse (без оптимизаций).

Но таких курсов особо нет. Поэтому, по моему разумению, если человек вынужден сам учиться программировать, то надо взять книгу "Секреты программирования игр", которая закрывает пункты 1, 2 более или менее, а потом надо взять SICP и порешать её на любом языке, который захочется освоить.

Но начинать сразу с высокоуровневого языка - не целесообразно. Мозг сформирует нейронные связи под высокоуровневые представления, и потом переходить на низкий уровень, что актуально для компиляторщиков или (уверен) для следующей генерации программистов, которую засадят за IoT и всяких роботов, переходить будет крайне сложно. У меня вон магистранты и за полгода в libuv въехать не могут. Управление памятью для них - это мистика за 1000 печатями. Даже GCC из командной строки запустить - мучение, потому что они не понимают, как из текстов получается код. У них модель прошита так: в VSCode тексты, и мы нажимаем кнопочку run, и оно работает.

Это не "особо одарённые", это средний магистрант после программы обучения, которая начинается с Python, продолжается Haskell и Scheme, заканчивается C++

«мы нажимаем кнопочку run и оно работает»

Вполне человеческая реакция - к удобству быстро привыкаешь

Neng-Fa Zhou <neng.zhou@gmail.com>
01:01 (9 часов назад)
кому: Picat Отказаться от рассылки


The videos I made for my online PL course on "Introduction to Constraint Logic Programming Through Picat" are available on YouTube.

Video-1: Motivating examples: scanning and parsing
  https://youtu.be/sR7awIRK5RQ
Video-2: Picat's REPL environment, data types, operators, and basic built-ins
  https://youtu.be/cnfxMmyDAj4
Video-3: Recursion on numbers
  https://youtu.be/PFwczfFnXfY
Video-4: Recursion on lists and binary trees
  https://youtu.be/T0BwkW8QbP4
Video-5: Constraint solving
  https://youtu.be/sZCxjzSJttw

You hope they are useful, especially for beginners. The total time is about 2.5 hours. My speech is very slow, and you could play the videos at 1.5 speed rate.

Cheers,
Neng-Fa