Information
- Rating
- Does not participate
- Location
- Ростов-на-Дону, Ростовская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Project Manager, Software Architect
Project management
People management
APCS
Linux
Python
C++
Lisp
Assembler
Rust
Плюс в карму за отсылки к Fallout!
Но и без учёта оригинальной подачи - очень полезная статья. Благодарю!
Благодарю. Много нового для себя почерпнул.
Т.е. всё упирается в необходимость программистам обязательно учитывать особенности архитектуру процессора в своих алгоритмах? А есть такая необходимость потому, что невозможно силами компилятора реструктурировать под иную архитектуру?
В принципе, если подумать, действительно не очевидно как сохранить задуманное разработчиком поведение, но переделать на многопоточный код, в котором почти каждая последующая конструкция использует результат вычислений предыдущей...
Наверное эффект будет как в ПК-играх начала 00-х. Когда запускаешь на современном многоядерном процессоре и удивляешься, что игра использует 2 ядра, а остальные не задействованы.
Либо сделать более сложный backend для популярных компиляторов, которые смогут модифицировать структуру кода под новую архитектуру таким образом, чтобы логика поведения программы осталась ожидаемой для программиста. Например как в случае с современным Эльбрус - предсказание условных переходов реализовано в backend компилятора, а не в процессоре (x86_64).
Речь идёт о полноценном С++ в ядре linux? Или некоторое подмножество с урезанным runtime?