Полагаю, относительно VLIW надо бы сделать несколько поправок:
Во-первых, более-менее нормальные алгоритмы планирования инструкций и регистров вроде как есть. Например, я зашёл на страницу публикаций МЦСТ и нашёл статью 2010 года: http://mcst.ru/doc/ivanov_101228.pdf Выглядит достаточно адекватно.
Для VLIW в случае Эльбруса есть возможность скомпилировать универсальный код, который запустится на всех версиях от v2 (или v3, не помню уже, всё равно это уже старое железо) до современной v6. Правда, придётся пожертвовать частью производительности.
Причём тут адреса? Речь идёт про наличие данных в кеше!
Мы ж про конфликты говорили. А это неразрывно связано с адресами.
Впрочем, если Ваша речь — про наличие данных в кэше, то я и не возражал вроде…
write after read — это, вроде бы, вообще не конфликт. Может вы имеете в виду read after write? Да, на эту тему что-то вроде есть bypass'ы — но это всё равно не критично. Они только в последних поколениях появились.
Я имел в виду именно то, что написал. RAW (read after write) к теме разговора не относится. WAR — вполне однозначно конфликт: если поменять операции местами, то изменится результат read => изменится результат исполнения программы. И этот конфликт OoO обязан так или иначе решить.
Отдельно про байпассы: это ж седая древность. ЕМНИП, эти штуки ещё с самого появления конвейеров появились. Просто много байпассов в процессоре сложно делать, вот и ставят их только на самые перспективные в смысле ускорения пары стадий конвейера.
Вопрос в том, что такое «не сильно потерять в производительности». Раза в два — это «сильно» или «не сильно»?
Откуда данные про 2 раза?
А что в случае с VLIW делать? Предусматривать множество планов, где каждая операция может «зависнуть»? Так никакого кода не хватит, чтобы все такие случаи грамотно учесть.
Ваш вариант про предусмотреть всё такое, разумеется, не катит. Но ведь есть другие оптимизации, и я их даже перечислил.
Конечно, в идеальном исполнении с идеальным компилятором VLIW проиграет OoO. Но реально надо уже смотреть на конкретные реализации.
Никаким боком Trace Cache к спекулятивным операциям не относится: это средство ускорения выборки операций.
UPD. Погорячился, косвенно относится. У меня сложилось впечатление, что это такой интересный предсказатель переходов. В принципе, там нужно предусмотреть очистку конвейера от уже начатых операций, но всё же это не спекулятивность.
Не знает. В том-то и дело, что не знает. Ни VLIW не знает, ни механизм OoO. Последнему, впрочем, это не нужно: он видит какие инструкции из «пула» можно исполнять (хотя бы и спекулятивно), а какие «застряли».
Эээ, а как они тогда вообще работают с памятью, не зная адресов? Ну и Вы только что отказали OoO в возможности корректно обрабатывать как минимум конфликты типа write after read по одному и тому же адресу.
Но в кеш он не смотрит и ему это не нужно. Все решения принимаются «пост-фактум». А для VLIW-компилятора это-таки нужно.
Вы имеете в виду, что VLIW-компилятору нужно знать, окажутся ли данные в кэше или в памяти? Если это правильная трактовка, то да, в идеале это нужно знать. Но имхо с достаточно хорошо отработавшими оптимизациями размещения данных в памяти и всякими предподкачками доля промахов кэша достаточно мала, чтобы не сильно потерять в производительности, предположив все данные лежащими в L1.
В однопотоке VLIW «сливает» и достаточно сильно, увы.
I need proof.
ЕМНИП, в какой-то статье я читал, что однопоточно Эльбрус 1 ГГц был эквивалентен чему-то типа 2,6 ГГц Интела. Но это нужно гуглить.
Я же имел в виду ещё и спекулятивное выполнение, когда процессор выполняет одновременно обе ветки кода, а затем одну отбрасывает. Это можно сделать и на VLIW, но сложно.
В смысле сложно? Если сделать в системе команд спекулятивные операции (а в VLIW Эльбрусе они есть — пруф), то это окажется не сложнее, чем в суперскаляре: оставшиеся механики отставки результата операции совпадают.
Так мы ж говорим здесь о том, как замаскировать эти задержки, использовав время ожидания на что-нибудь другое. Я по инерции продолжал говорить про предсказатель переходов, хотя с моей стороны было правильнее переключиться на механизм OoO.
Out-of-order действительно сам организует порядок исполнения операций, и пока одна команда ждёт данных, может запустить не зависящие от неё операции. При этом в динамике он знает, где какие адреса и потому знает, где будут конфликты => имеет больше свободы в размещении команд. Компилятор в данной ситуации имеет меньше свободы, так как вынужден использовать различные сложные варианты анализа адресов и консервативно оценивать возможность возникновения конфликтов. Поэтому в идеале in-order подход с явным параллелизмом проиграет out-of-order'у.
В реальной же ситуации у нас кроме самого OoO/in-order начинают играть прочие факторы. Например, предподкачка данных или ограниченность буфера предвыборки команд в out-of-order. Ну и оптимизации размещения данных в памяти со стороны компилятора. Так что в реальном мире не настолько очевидно, кто кого и как обыгрывает.
Конечно, вы можете это реализовать статически в compile-time, но в силу огромной сложности это будет менее эффективно.
Скорее не из-за огромной сложности (реализовать аналог на самом процессоре сложнее, чем программно), а из-за недостаточности данных в статике. То есть предсказатель перехода в процессоре имеет больше данных, чем компилятор.
А так да, это известная проблема VLIW.
Изменить архитектуру процессора так, чтобы в нём было много регистров. Я думаю, 32 или 64 регистра общего назначения — нормально.
Давно уж сделано. ЕМНИП, в Эльбрусе вообще 192 архитектурных регистра.
Изменить архитектуру процессора так, чтобы для разных режимов процессора (как правило, их два: user-space и kernel-space; по хорошему надо бы иметь отдельный interrupt-space) был свой набор регистров. Ну, user-space и kernel-space должны иметь общие регистры для обмена данными при системных вызовах; а вот для interrupt-space нужен полностью собственный набор регистров. Это избавит от необходимости сохранять регистры в память при переключении контекста. Впрочем, потребность в кэше это вряд ли снизит.
Зачем такие сложности, если можно сделать регистровое окно поверх большего количества архитектурных регистров? Например, у Вас есть 128 физических регистров и хотите сделать окно в 32 регистра. Тогда нужно добавить команды циклического сдвига окна на +32 (call) и -32(return), простое переименование регистров (номер физического регистра = номер архитектурного + 32 * номер окна) и механизм вытеснения данных в память из этого регистрового файла при сдвиге окна на уже занятое место.
3 пункт вообще не понял: сами по себе регистровые файлы уже давно сделаны. Это те самые регистровые файлы, про которые Вы говорите, или нет?
Изменить архитектуру компьютера, отказавшись от общей памяти для всех ядер.
Тоже не вполне понял. Вы имеете в виду сделать верхний уровень кэш-памяти приватным для каждого ядра?
В каком-то смысле это эквивалентно увеличению скорости оперативной памяти — время отклика сохраняется, а вот скорость чтения/записи больших объёмов растёт примерно пропорционально количеству пулов памяти.
Почему?
Ну и количество коллизий при одновременном обращении нескольких ядер в память — тоже снизится.
Есть ещё вариант, для родителей более дешёвый и в условиях Физтеха более осмысленный. Если с базовой кафедрой повезло, то на магистра имеет смысл на ней же и остаться, получить максимум знаний и умений, и уже на PhD уезжать (а там студенту уже за работу платят, и родителям не придётся его снабжать). Впрочем, с большой вероятностью на такой базе и работа на кандидата будет очень годной, а после PhD, как я слышал, больше смотрят на годность самой работы, а не место её выполнения.
Да и вообще, имхо нормальные работодатели смотрят в первую очередь знания, навыки (тут играет качество образования) и наличие корочки (если всё же очень хочется завести трактор), чем место получения образования: человек может быть неучем и после Гарварда, а может быть очень толковым после условного Зажопинского Заборостроительного. Жаль, что не все работодатели такие…
Разумное замечание. Но эти позиции прямо противоречат друг другу, только если считать, что студент получит только степень бакалавра. Если же студент получит вдобавок степень магистра (в том ВУЗе, который более соответствует его целям) или даже PhD, то место учёбы в бакалавриате уже перекрывается ВУЗами более позднего образования. Например, мне известны примеры, когда бакалавром человек стал на Физтехе, а в более рейтинговую магистратуру уехал за рубеж.
Впрочем, как я слышал, принципы набора «там» всё же несколько проще: явная разница в отношении есть только у выпускников ВУЗов Лиги Плюща (я для примера беру США). То есть к выпускникам российских, европейских и американских ВУЗов не из Лиги Плюща отношение примерно одинаковое. А уж в этих условиях имхо качество образования играет роль уже не как критерий для HR, а как чуть лучшие результаты на собеседовании.
Спорный момент с ВУЗами: рейтинги ВУЗов — всё же не самый показательный критерий, чтобы определять их конкурентоспособность. Обычно в рейтинги входят не только нормальные критерии типа «качество образования», но и «уровень исследований» (в России у ВУЗов с этим плохо не потому, что они плохие, а потому, что за исследования у нас обычно отвечают не учебные институты), какой-нибудь «гендерный баланс» (при честном приёме в университет эта характеристика от ВУЗа не зависит) и иногда ещё что-нибудь странное типа «количества специализаций» (специализированные ВУЗы типа Физтеха в таких случаях проваливаются, так как гуманитариев не готовят). И «качество образования» среди этих характеристик весит не очень много.
Для примера возьмём рейтинг THE: 30% — качество обучения, 60% в сумме дают исследования, остальные 10% дают за международную кооперацию (иностранных студентов, иностранных преподавателей и прочее) и пользу для индустрии. То есть родителя школьника должна имхо интересовать не общая позиция ВУЗа в рейтинге, а его оценка в части рейтинга за качество образования. Я тут для примера посмотрел оценки за качество обучения в THE 2019 и вижу: МГУ на 23 месте в мире, МФТИ около 89 места (рядом с ним шведский Королевский университет, TU Delft, RWTH Aachen).
Отдельно стоит упомянуть методологию сбора оценок за качество образования: это так просто не определяется. Например, в том же THE половина оценки за качество — репутация ВУЗа среди опрашиваемых. То есть среди американцев и (вероятно) англичан. При такой методологии имхо стоит ожидать, что оценки английских и американских ВУЗов в среднем будут лучше, чем у университетов прочих стран: свои университеты они знают, а из наших знают разве что Физтех, МГУ, ИТМО и ещё пару. Вот и нет у остальных какой-либо репутации, то есть снижены баллы.
В общем, на рейтинги нужно ориентироваться с большой оглядкой, а лучше для каждого рейтинга разобраться в методологии и выделить именно нужные характеристики.
Ну а по сути выводов из рейтингов, то имхо готовить ребёнка к иностранному ВУЗу полезно хотя бы из соображений подтянуть английский и «попытка — не пытка».
А непосредственно само производство чипов и плат под них после того как разработка завершена — партиями по несколько тысяч штук это уже в общем достаточная серия, себестоимость 1 единицы в которой не должна сильно от миллионных тиражей отличаться.
(мои сведения не из личного опыта, а через третьи руки) Насколько мне известно, как раз в этом пункте себестоимость единицы в зависимости от размера партии сильно падает, так как материалы и корпусировка не очень дорогие, в отличие от изготовления фотошаблонов. То есть если фирма заказывает партию в условные 10 тысяч штук, и делает так раз в 2 года, в следующую партию внося исправления (т.е. нужно перевыпустить хотя бы часть шаблонов), то у неё себестоимость каждой штуки и будет в условную тысячу долларов. Если же та же фирма будет делать партию в миллион штук на тех же условиях (раз в 2 года с перевыпуском части шаблонов), то себестоимость штуки у неё будет условные 50 долларов.
ну а цена на продукцию вообще не выдерживает критики.
Это следствие двух факторов:
Низкий спрос на «Эльбрусы».
Высокая цена партии, слабо зависящая от её размера.
ЕМНИП, цена производства одной партии процессоров начинается от нескольких млн долларов за минимальный размер порядка тысяч штук и растёт от размера партии слабо. То есть если продавать процессоры миллионами, то цена за штуку будет порядка десятков и сотен долларов, а если тысячами — то возрастёт до тысяч и более. И тут, как я понимаю, МЦСТ находится во второй категории.
Аналогично затраты на разработку у какого-нибудь Intel размазываются на миллионы проданных процессоров, а у МЦСТ — на гораздо меньшее количество.
Вообще говоря, профита может и не быть, а может быть и деградация. Это сильно зависит от того, как мы эту структуру данных используем. Поэтому к оптимизации AoS->SoA нужно подходить с осторожностью.
Почему оная оптимизация вообще может сработать на утрированном примере: допустим, у нас есть массив структур с 8 4-байтовыми полями, а в некоем цикле мы обращаемся к 3-му полю каждого элемента массива в цикле, причём итерируемся по индексу элемента массива. Допустим, размер кэш-линии L1 у нас 64 байта. Тогда мы можем загружать в кэш-линию по 2 элемента массива, из которых реально в данном конкретном цикле будем трогать 2 4-байтовых поля. Итог: каждые 2 итерации получаем промах кэша L1. После преобразования (именно в SoA, хотя обычно делают несколько AoS с элементами меньшего размера и связями между структурами, чтобы нормально обрабатывать обращения к структурам по указателю) получим промах кэша L1 на каждые 16 итераций — в 8 раз реже. Профит!
А если мы в другом цикле трогаем все поля структуры в течение итерации? Тогда до преобразования был 1 кэш-промах на 2 итерации. После преобразования у нас получится, что все поля лежат в разных кэш-линиях (если нам повезло обойтись без коллизий, но такие коллизии — всё же редкость), что даёт по 1 кэш-промаху на 16 итераций в каждой кэш-линии — 8 кэш-промахов на 16 итераций. Никакого профита, если нам повезло. А если не повезло, то вообще деградацию получили.
Ну и пример с деградацией, подобный Вашему: при случайном доступе, как обычно делается в списках, у нас вместо одного кэш-промаха на всю нашу структуру по 1 промаху на каждое поле, которое трогаем.
Как следствие всего вышесказанного, для проведения оптимизации AoS->SoA крайне желательно исследовать код на такие сценарии использования.
Невыполнение этих требований верно только в случае, если элементы этих списков лежат в разных пулах. А если для всех списков данного типа использовать один пул (то есть три: пул данных, пул prev и пул next)? Тогда пострадает утилизация кэша, но вставки и удаления других списков в данном станут за O(1).
Я не автор, но, очевидно, да.
Пруф — работы по Structure Layout Optimizations и (в частности) Structure Peeling и Structure Splitting. То, что сделал автор, — как раз Structure Peeling в версии разрезания не на 2 структуры, а на раздельные поля, с обходом вопросов по корректности указателей после разрезания с помощью замены на индексы. Такого рода оптимизации обязаны сохранять логику использования, так как применяются в компиляторах.
Сколько раз сталкивался — всё нормально. При этом платное — только зубы.
образование
Начальное и среднее в Москве — имхо от «нормально» до «очень хорошо» (это в случае лицеев и прочих гимназий). Например, из 200-х — 300-х в рейтинге из 854 московских школ народ спокойно или почти спокойно поступает в МГУ, на Физтех и прочие топовые ВУЗы Москвы. А выпускники третьей в том же рейтинге школы могут себе позволить поступать во всякие MIT и Гарварды.
По высшему — разброс куда больше. Есть и всякие ноунеймы, и Физтех с МГУ. Вы же не будете отрицать, что в последних качество образования очень хорошее?
Полагаю, относительно VLIW надо бы сделать несколько поправок:
Во-первых, более-менее нормальные алгоритмы планирования инструкций и регистров вроде как есть. Например, я зашёл на страницу публикаций МЦСТ и нашёл статью 2010 года: http://mcst.ru/doc/ivanov_101228.pdf Выглядит достаточно адекватно.
Для VLIW в случае Эльбруса есть возможность скомпилировать универсальный код, который запустится на всех версиях от v2 (или v3, не помню уже, всё равно это уже старое железо) до современной v6. Правда, придётся пожертвовать частью производительности.
ЕМНИП на русском языке out-of-order называют внеочередным выполнением.
Мы ж про конфликты говорили. А это неразрывно связано с адресами.
Впрочем, если Ваша речь — про наличие данных в кэше, то я и не возражал вроде…
Я имел в виду именно то, что написал. RAW (read after write) к теме разговора не относится. WAR — вполне однозначно конфликт: если поменять операции местами, то изменится результат read => изменится результат исполнения программы. И этот конфликт OoO обязан так или иначе решить.
Отдельно про байпассы: это ж седая древность. ЕМНИП, эти штуки ещё с самого появления конвейеров появились. Просто много байпассов в процессоре сложно делать, вот и ставят их только на самые перспективные в смысле ускорения пары стадий конвейера.
Откуда данные про 2 раза?
Ваш вариант про предусмотреть всё такое, разумеется, не катит. Но ведь есть другие оптимизации, и я их даже перечислил.
Конечно, в идеальном исполнении с идеальным компилятором VLIW проиграет OoO. Но реально надо уже смотреть на конкретные реализации.
UPD. Погорячился, косвенно относится. У меня сложилось впечатление, что это такой интересный предсказатель переходов. В принципе, там нужно предусмотреть очистку конвейера от уже начатых операций, но всё же это не спекулятивность.
Эээ, а как они тогда вообще работают с памятью, не зная адресов? Ну и Вы только что отказали OoO в возможности корректно обрабатывать как минимум конфликты типа write after read по одному и тому же адресу.
Вы имеете в виду, что VLIW-компилятору нужно знать, окажутся ли данные в кэше или в памяти? Если это правильная трактовка, то да, в идеале это нужно знать. Но имхо с достаточно хорошо отработавшими оптимизациями размещения данных в памяти и всякими предподкачками доля промахов кэша достаточно мала, чтобы не сильно потерять в производительности, предположив все данные лежащими в L1.
I need proof.
ЕМНИП, в какой-то статье я читал, что однопоточно Эльбрус 1 ГГц был эквивалентен чему-то типа 2,6 ГГц Интела. Но это нужно гуглить.
В смысле сложно? Если сделать в системе команд спекулятивные операции (а в VLIW Эльбрусе они есть — пруф), то это окажется не сложнее, чем в суперскаляре: оставшиеся механики отставки результата операции совпадают.
Out-of-order действительно сам организует порядок исполнения операций, и пока одна команда ждёт данных, может запустить не зависящие от неё операции. При этом в динамике он знает, где какие адреса и потому знает, где будут конфликты => имеет больше свободы в размещении команд. Компилятор в данной ситуации имеет меньше свободы, так как вынужден использовать различные сложные варианты анализа адресов и консервативно оценивать возможность возникновения конфликтов. Поэтому в идеале in-order подход с явным параллелизмом проиграет out-of-order'у.
В реальной же ситуации у нас кроме самого OoO/in-order начинают играть прочие факторы. Например, предподкачка данных или ограниченность буфера предвыборки команд в out-of-order. Ну и оптимизации размещения данных в памяти со стороны компилятора. Так что в реальном мире не настолько очевидно, кто кого и как обыгрывает.
Скорее не из-за огромной сложности (реализовать аналог на самом процессоре сложнее, чем программно), а из-за недостаточности данных в статике. То есть предсказатель перехода в процессоре имеет больше данных, чем компилятор.
А так да, это известная проблема VLIW.
Давно уж сделано. ЕМНИП, в Эльбрусе вообще 192 архитектурных регистра.
Зачем такие сложности, если можно сделать регистровое окно поверх большего количества архитектурных регистров? Например, у Вас есть 128 физических регистров и хотите сделать окно в 32 регистра. Тогда нужно добавить команды циклического сдвига окна на +32 (call) и -32(return), простое переименование регистров (номер физического регистра = номер архитектурного + 32 * номер окна) и механизм вытеснения данных в память из этого регистрового файла при сдвиге окна на уже занятое место.
3 пункт вообще не понял: сами по себе регистровые файлы уже давно сделаны. Это те самые регистровые файлы, про которые Вы говорите, или нет?
Тоже не вполне понял. Вы имеете в виду сделать верхний уровень кэш-памяти приватным для каждого ядра?
Почему?
И опять-таки почему?
Да и вообще, имхо нормальные работодатели смотрят в первую очередь знания, навыки (тут играет качество образования) и наличие корочки (если всё же очень хочется завести трактор), чем место получения образования: человек может быть неучем и после Гарварда, а может быть очень толковым после условного Зажопинского Заборостроительного. Жаль, что не все работодатели такие…
Впрочем, как я слышал, принципы набора «там» всё же несколько проще: явная разница в отношении есть только у выпускников ВУЗов Лиги Плюща (я для примера беру США). То есть к выпускникам российских, европейских и американских ВУЗов не из Лиги Плюща отношение примерно одинаковое. А уж в этих условиях имхо качество образования играет роль уже не как критерий для HR, а как чуть лучшие результаты на собеседовании.
Для примера возьмём рейтинг THE: 30% — качество обучения, 60% в сумме дают исследования, остальные 10% дают за международную кооперацию (иностранных студентов, иностранных преподавателей и прочее) и пользу для индустрии. То есть родителя школьника должна имхо интересовать не общая позиция ВУЗа в рейтинге, а его оценка в части рейтинга за качество образования. Я тут для примера посмотрел оценки за качество обучения в THE 2019 и вижу: МГУ на 23 месте в мире, МФТИ около 89 места (рядом с ним шведский Королевский университет, TU Delft, RWTH Aachen).
Отдельно стоит упомянуть методологию сбора оценок за качество образования: это так просто не определяется. Например, в том же THE половина оценки за качество — репутация ВУЗа среди опрашиваемых. То есть среди американцев и (вероятно) англичан. При такой методологии имхо стоит ожидать, что оценки английских и американских ВУЗов в среднем будут лучше, чем у университетов прочих стран: свои университеты они знают, а из наших знают разве что Физтех, МГУ, ИТМО и ещё пару. Вот и нет у остальных какой-либо репутации, то есть снижены баллы.
В общем, на рейтинги нужно ориентироваться с большой оглядкой, а лучше для каждого рейтинга разобраться в методологии и выделить именно нужные характеристики.
Ну а по сути выводов из рейтингов, то имхо готовить ребёнка к иностранному ВУЗу полезно хотя бы из соображений подтянуть английский и «попытка — не пытка».
(мои сведения не из личного опыта, а через третьи руки) Насколько мне известно, как раз в этом пункте себестоимость единицы в зависимости от размера партии сильно падает, так как материалы и корпусировка не очень дорогие, в отличие от изготовления фотошаблонов. То есть если фирма заказывает партию в условные 10 тысяч штук, и делает так раз в 2 года, в следующую партию внося исправления (т.е. нужно перевыпустить хотя бы часть шаблонов), то у неё себестоимость каждой штуки и будет в условную тысячу долларов. Если же та же фирма будет делать партию в миллион штук на тех же условиях (раз в 2 года с перевыпуском части шаблонов), то себестоимость штуки у неё будет условные 50 долларов.
Это следствие двух факторов:
ЕМНИП, цена производства одной партии процессоров начинается от нескольких млн долларов за минимальный размер порядка тысяч штук и растёт от размера партии слабо. То есть если продавать процессоры миллионами, то цена за штуку будет порядка десятков и сотен долларов, а если тысячами — то возрастёт до тысяч и более. И тут, как я понимаю, МЦСТ находится во второй категории.
Аналогично затраты на разработку у какого-нибудь Intel размазываются на миллионы проданных процессоров, а у МЦСТ — на гораздо меньшее количество.
Почему оная оптимизация вообще может сработать на утрированном примере: допустим, у нас есть массив структур с 8 4-байтовыми полями, а в некоем цикле мы обращаемся к 3-му полю каждого элемента массива в цикле, причём итерируемся по индексу элемента массива. Допустим, размер кэш-линии L1 у нас 64 байта. Тогда мы можем загружать в кэш-линию по 2 элемента массива, из которых реально в данном конкретном цикле будем трогать 2 4-байтовых поля. Итог: каждые 2 итерации получаем промах кэша L1. После преобразования (именно в SoA, хотя обычно делают несколько AoS с элементами меньшего размера и связями между структурами, чтобы нормально обрабатывать обращения к структурам по указателю) получим промах кэша L1 на каждые 16 итераций — в 8 раз реже. Профит!
А если мы в другом цикле трогаем все поля структуры в течение итерации? Тогда до преобразования был 1 кэш-промах на 2 итерации. После преобразования у нас получится, что все поля лежат в разных кэш-линиях (если нам повезло обойтись без коллизий, но такие коллизии — всё же редкость), что даёт по 1 кэш-промаху на 16 итераций в каждой кэш-линии — 8 кэш-промахов на 16 итераций. Никакого профита, если нам повезло. А если не повезло, то вообще деградацию получили.
Ну и пример с деградацией, подобный Вашему: при случайном доступе, как обычно делается в списках, у нас вместо одного кэш-промаха на всю нашу структуру по 1 промаху на каждое поле, которое трогаем.
Как следствие всего вышесказанного, для проведения оптимизации AoS->SoA крайне желательно исследовать код на такие сценарии использования.
Пруф — работы по Structure Layout Optimizations и (в частности) Structure Peeling и Structure Splitting. То, что сделал автор, — как раз Structure Peeling в версии разрезания не на 2 структуры, а на раздельные поля, с обходом вопросов по корректности указателей после разрезания с помощью замены на индексы. Такого рода оптимизации обязаны сохранять логику использования, так как применяются в компиляторах.
Сколько раз сталкивался — всё нормально. При этом платное — только зубы.
Начальное и среднее в Москве — имхо от «нормально» до «очень хорошо» (это в случае лицеев и прочих гимназий). Например, из 200-х — 300-х в рейтинге из 854 московских школ народ спокойно или почти спокойно поступает в МГУ, на Физтех и прочие топовые ВУЗы Москвы. А выпускники третьей в том же рейтинге школы могут себе позволить поступать во всякие MIT и Гарварды.
По высшему — разброс куда больше. Есть и всякие ноунеймы, и Физтех с МГУ. Вы же не будете отрицать, что в последних качество образования очень хорошее?
Чего не знаю, того не знаю. Может быть.