Понимание уровней вычислений


9

Извините за мой запутанный вопрос. Я ищу несколько указателей.

До сих пор я работал в основном с Java и Python на уровне приложений, и у меня есть только смутное представление об операционных системах и оборудовании. Я хочу понять гораздо больше о более низких уровнях вычислительной техники, но это становится действительно подавляющим. В университете я изучал микропрограммирование, то есть как процессоры запрограммированы для реализации кодов ASM. До сих пор я всегда думал, что не сделаю больше, если узнаю больше о «низком уровне».

У меня один вопрос: как вообще возможно, что оборудование почти полностью скрыто от разработчика? Точно ли сказать, что операционная система является программным уровнем для аппаратного обеспечения? Один небольшой пример: в программировании я никогда не сталкивался с необходимостью понять, что такое L2 или L3 Cache. Для типичной среды бизнес-приложений почти никогда не нужно понимать ассемблер и более низкие уровни вычислений, потому что в настоящее время существует технологический стек практически для всего. Я предполагаю, что весь смысл этих более низких уровней состоит в том, чтобы предоставить интерфейс более высоким уровням. С другой стороны, мне интересно, как сильно могут влиять нижние уровни, например, вся эта графическая вычислительная штука.

Итак, с другой стороны, существует теоретическая отрасль информатики, которая работает над абстрактными компьютерными моделями. Тем не менее, я также редко сталкивался с ситуациями, когда мне было полезно размышлять о категориях моделей сложности, проверке доказательств и т. Д. Я вроде знаю, что существует класс сложности, называемый NP, и что их практически невозможно решить за большое количество N. То, что я пропускаю, является ссылкой для структуры, чтобы думать об этих вещах. Мне кажется, что есть разные виды лагерей, которые редко общаются.

Последние несколько недель я читал о проблемах безопасности. Здесь, так или иначе, большая часть различных слоев объединяется. Атаки и эксплойты почти всегда происходят на более низком уровне, поэтому в этом случае необходимо изучить детали уровней OSI, внутреннюю работу ОС и т. Д.


1
На этот (отличный вопрос) есть отличный ответ programmers.stackexchange.com/questions/81624/…
Puckl

Атаки и подвиги могут происходить на всех уровнях. Если я напишу уязвимый PHP-скрипт, его можно будет использовать независимо от базовой ОС, не говоря уже об аппаратном обеспечении.
tdammers

1
Нашел отличную книгу на тему: «Элементы вычислительных систем: создание современного компьютера из первых принципов» Ноам Нисан, Шимон Шокен.
Доклад

Еще во времена досов, использование языка ассемблера для графических подпрограмм VGA было единственным способом добиться какой-либо производительности, но, полагаю, я не знал, что делаю! Но за последние 10 или более лет моей карьеры мне не приходилось смотреть на что-то столь низкое. И сейчас я в основном не знаю, что происходит на этих уровнях. Редко мне даже нужно выделить или очистить собственную память. Я подозреваю, что многие в моей команде не знают, что такое стек! Во многих отношениях неэффективно кодировать на таком уровне, изобретая колесо, так сказать. Скорее мы стоим на плечах гигантов.
Гэвин Хоуден

Ответы:


19

Ключевое слово для размышления об этих вещах - абстракция .

Абстракция просто означает намеренное игнорирование деталей системы, чтобы вы могли думать о ней как о едином неделимом компоненте при сборке более крупной системы из множества подсистем. Это невероятно мощно - написание современной прикладной программы с учетом деталей распределения памяти и различий регистров и времени выполнения транзистора было бы возможно каким-то идеализированным способом, но это несравнимо легче недумать о них и просто использовать операции высокого уровня. Современная вычислительная парадигма основывается на нескольких уровнях абстракции: твердотельная электроника, микропрограммирование, машинные инструкции, языки программирования высокого уровня, API-интерфейсы для ОС и веб-программирования, программируемые пользователем среды и приложения. Практически никто не может постичь всю систему в наше время, и нет даже мыслимого пути, по которому мы могли бы когда-либо вернуться к такому положению вещей.

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

Вопрос безопасности интересен, потому что недостатки и «утечки» в абстракции часто могут быть использованы для нарушения целостности системы. Когда API постулирует, что вы можете вызывать методы A, B и C, но только если выполняется условие X, легко забыть об этом условии и быть неподготовленным к последствиям, которые происходят, когда условие нарушается. Например, классическое переполнение буфера использует тот факт, что запись в ячейки памяти приводит к неопределенному поведению, если вы сами не выделите этот конкретный блок памяти. API только гарантирует, что что- топроизойдет в результате, но на практике результат определяется деталями системы на следующем более низком уровне - о котором мы сознательно забыли! Пока мы выполняем условие, это не имеет значения, но если нет, злоумышленник, который понимает оба уровня, может обычно направлять поведение всей системы по своему желанию и вызывать плохие вещи.

Случай с ошибками при выделении памяти особенно плох, потому что оказалось очень, очень сложно управлять памятью вручную без единой ошибки в большой системе. Это можно рассматривать как неудачный случай абстракции: хотя с помощью C можно делать все, что вам нужно.mallocAPI, это просто легко злоупотреблять. Части сообщества программистов теперь считают, что это было неправильное место для введения границы уровня в систему, и вместо этого продвигают языки с автоматическим управлением памятью и сборкой мусора, которая теряет некоторую мощность, но обеспечивает защиту от повреждения памяти и неопределенного поведения , На самом деле, основной причиной того, что в настоящее время все еще используется C ++, является именно тот факт, что он позволяет вам точно контролировать, какие ресурсы приобретаются и когда высвобождаются. Таким образом, основной раскол между управляемыми и неуправляемыми языками сегодня можно рассматривать как разногласие относительно того, где точно определить уровень абстракции.

То же самое можно сказать и о многих других основных альтернативных парадигмах в вычислительной технике - эта проблема действительно возникает все время, когда приходится создавать большие системы, потому что мы просто не можем с нуля разрабатывать решения для сложных требований, общих сегодня. (Общая точка зрения в AI в эти дни является то , что человеческий мозг на самом деле делает работу как то - поведение , возникающее через петлю обратной связи, в широком масштабе , соединенные между собой сети и т.д. , а не из отдельных модулей и слоев с простым, отведенной интерфейсы между ними, и что именно поэтому мы имели настолько мало успеха в моделировании нашего собственного интеллекта.)


1
Большое спасибо. Таким образом, пример сборки мусора / управления памятью, вероятно, является наиболее известным примером такого взаимодействия. Нил Гершенфельд написал несколько интересных вещей, хотя я понимаю только некоторые из них.
RParadox

... Очень хороший момент о сложности. Если только машины могут проектировать наши машины, к чему это приведет? Если люди ИИ говорят об ИИ, создающих более умных ИИ, возможно, мы почти на месте. ;)
RParadox
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.