Как работает компьютер. Простая статья для начинающих программистов

В этой статье изложено всё, что нужно знать об устройстве компьютера с точки зрения программиста, а именно: для чего нужен тактовый генератор, регистры, кэши и виртуальная память; что такое архитектура процессора; что такое машинный код и код ассемблера; чем отличается компиляция в машинный код в C, C++ или Rust от компиляции в байт-код виртуальной машины в языках типа Java и C#; в чём их отличие от интерпретируемых языков вроде JavaScript или Python; что такое динамические и статические библиотеки (.dll/.so, .lib/.a); что такое фреймворк; что такое API и web-API; и что собой представляет параллельное программирование с использованием многоядерных процессоров, векторных регистров и видеокарт.

https://habr.com/ru/articles/964572/

#процессор #кэш #регистр #виртуальная_память #компиляция #интерпретаторы #параллелизм #gpu #векторные_операции #api

Кэширование и всё, что с ним связано

Привет, хабр! Сегодня хочу рассказать об одной технологии, которая сопровождает нас буквально везде. От процессора в вашем смартфоне до глобальных сервисов вроде YouTube. Речь пойдет о кэшировании. Да, я знаю, тема кажется избитой. Но когда я впервые осознала, что одни и те же принципы работают на всех уровнях, от крошечного L1-кэша до распределенного Redis-кластера — это было похоже на инженерное просветление. Предлагаю и вам пройти этот путь вместе со мной.

https://habr.com/ru/companies/timeweb/articles/959676/

#кэш #кэшпамять #кэширование #redis #cdn #timeweb_статьи

[Перевод] Полное руководство по HTTP-кэшированию. Часть 2

Кэширование — скрытый двигатель, на котором держится веб. Именно оно делает сайты быстрыми, надежными и относительно недорогими в обслуживании. При правильной настройке кэширование снижает задержки, разгружает серверы и позволяет даже хрупкой инфраструктуре выдерживать резкие всплески трафика. При неправильной настройке или полном отсутствии кэширования сайты работают медленно, остаются уязвимыми для атак и обходятся очень дорого. В основе кэширования лежит сокращение лишней работы. Каждый раз, когда браузер, CDN или прокси обращается к серверу за ресурсом, который не изменился, впустую тратятся время и трафик. Когда сервер заново формирует или повторно отдает идентичный контент, это лишь добавляет нагрузки и увеличивает затраты. А при пиковом трафике — например, в "черную пятницу", во время вирусной публикации или DDoS-атаки — такие ошибки стремительно накапливаются и приводят к сбоям всей системы.

https://habr.com/ru/companies/timeweb/articles/958898/

#cache #caching #http #кэш #кэширование #nginx #redis #cdn #timeweb_статьи_перевод #кеширование

[Перевод] Полное руководство по HTTP-кэшированию. Часть 1

Кэширование — скрытый двигатель, на котором держится веб. Именно оно делает сайты быстрыми, надежными и относительно недорогими в обслуживании. При правильной настройке кэширование снижает задержки, разгружает серверы и позволяет даже хрупкой инфраструктуре выдерживать резкие всплески трафика. При неправильной настройке или полном отсутствии кэширования сайты работают медленно, остаются уязвимыми для атак и обходятся очень дорого. В основе кэширования лежит сокращение лишней работы. Каждый раз, когда браузер, CDN или прокси обращается к серверу за ресурсом, который не изменился, впустую тратятся время и трафик. Когда сервер заново формирует или повторно отдает идентичный контент, это лишь добавляет нагрузки и увеличивает затраты. А при пиковом трафике — например, в "черную пятницу", во время вирусной публикации или DDoS-атаки — такие ошибки стремительно накапливаются и приводят к сбоям всей системы.

https://habr.com/ru/companies/timeweb/articles/954906/

#cache #caching #http #кеширование #кэш #кэширование #nginx #redis #cdn #timeweb_статьи_перевод

Швейцария в картах Go: путешествие по Swiss Tables

Golang продолжает развиваться. Изначальные проектные решения ставятся под сомнения, а новые вызовы заставляют язык меняться: дженерики, итераторы, новая имплементация мап. Однако, даже нововведения приходят к нам не такими, как в других языках. Вспомните обсуждения сразу после релиза тех же дженериков. На Go, как мне кажется, в большинстве своём пишут люди, пришедшие из прочих языков, у кого Golang не первый ЯП. Они привыкли к другому подходу работы с абстракциями. И им порой не хватает того, что предлагает язык Гофера. Swiss Tables — попытка быть в тренде. С вами Кирилл Кузин — ведущий подкастов про IT на канале gIT, где вместе с коллегами по цеху рассматриваем индустрию под разными углами, открывая новые горизонты для вас и самих себя. А работаю ведущим разработчиком в Ви.Tech — IT-дочке ВсеИнструменты.ру. Там мы с командой пишем внутренние системы на Go под задачи бизнеса и по ходу дела разбираемся, как наши инструменты устроены и как реально влияют на процесс разработки. В этой статье речь пойдёт о новых мапах в версии Go 1.24, реализованных по принципу Swiss Tables — швейцарских таблиц. Попробуем найти ответы на вопросы о том, почему мапы изменились, что лежит в основе новой реализации и как к ней пришли.

https://habr.com/ru/companies/oleg-bunin/articles/934906/

#golang #Swiss_Tables #мапы #оптимизация_производительности #структуры_данных #кэш #go_124 #cockroach #алгоритмы

Гранулярное погружение в атаки на кэш в ARMv8. Разбираем типы атак и митигации

Привет! Без лишнего: в статье расскажу про атаки на кэш-память в процессорах семейства ARMv8. Подробно изучил их для совершенствования безопасности KasperskyOS: познакомлю с теорией и практикой, механизмами работы и способами митигации. Также кратко расскажу, как мы тестировали каждый способ атаки на KasperskyOS, какие из них оказались неприменимы, какие могут представлять угрозу и как микроядро с подобными угрозами справляется. Если интересно гранулярно погрузиться в типологию атак на кэш — добро пожаловать!

https://habr.com/ru/companies/kaspersky/articles/927440/

#информационная_безопасность #системное_программирование #кэш #armv8 #процессоры #атаки #микроядро #операционные_системы #ос #программирование

[Перевод] На сколько же медленнее произвольный доступ на самом деле?

Как вы, наверно, знаете, из-за наличия в компьютере различных кэшей (L1, L2, L3...) и того, что операции с памятью выполняются с линиями кэша размером примерно 64 байт каждая, для обеспечения максимальной производительности мы должны писать программы, обеспечивающие локальность . (Разумеется, диск здесь не показан) Но насколько хорошо вы это осознаёте? Допустим, у нас есть массив чисел с плавающей запятой и массив индексов первого массива. Есть программа, складывающая числа из первого массива в порядке, определяемом вторым массивом. То есть в этом примере мы будем складывать ε + α + δ + ζ + β + γ в таком порядке: Давайте рассмотрим всего два случая: индексы идут в порядке от первого до последнего или в произвольном порядке . До того, как я начал писать этот пост, я не мог ответить ни на один из следующих вопросов: 1. Насколько большим должен быть массив, чтобы разница производительности вычисления в двух порядках стала заметной? 2. Сколько в среднем тратится на каждый элемент в порядке от первого до последнего? 3. Насколько медленнее произвольный порядок последовательного в случае массивов, умещающихся в RAM? 4. Насколько медленнее произвольный порядок последовательного в случае массивов, не умещающихся в RAM? 5. Достаточно ли стандартного тасования Фишера-Йейтса для массивов перемешанных индексов для получения произвольного порядка? 6. Насколько медленнее порядок от первого до последнего в случае массивов, не умещающихся в RAM, при использовании файлов с отображением в память? 7. Максимально ли быстры файлы с отображением в память? Если вы уже знаете ответы на эти вопросы, то это замечательно! Если же нет, то делайте ваши предположения и проверьте их, прочитав пост.

https://habr.com/ru/articles/922800/

#кэш #memory_mapped_files #бенчмарки

[Перевод] 14 интересных фич Python (возможно, не совсем pythonic)

Python — один из самых широко используемых языков программирования в мире. Однако из-за его простоты, позволяющей быстро сделать что-то , он остаётся также одним из самых недооценённых. Если загуглить лучшие 10 продвинутых хитростей Python , то вы найдёте кучу постов или статей на LinkedIn с обзором тривиальных (но всё же полезных) вещей типа генераторов или кортежей . Я пишу на Python уже двенадцать лет, и за это время нашёл кучу очень интересных, недооценённых, уникальных или (как может кто-то сказать) «не-pythonic» хитростей, позволяющих по-настоящему расширить границы возможного для Python. Именно поэтому я решил собрать список из 14 лучших таких фич с примерами и дополнительными ресурсами на случай, если вы захотите изучить их глубже.

https://habr.com/ru/companies/ruvds/articles/905832/

#метаклассы #перегрузка #сигнатуры #дженерики #fстроки #кэш #ruvds_перевод

[Перевод] 14 интересных фич Python (возможно, не совсем pythonic)

Python — один из самых широко используемых языков программирования в мире. Однако из-за его простоты, позволяющей быстро сделать что-то , он остаётся также одним из самых недооценённых. Если загуглить лучшие 10 продвинутых хитростей Python , то вы найдёте кучу постов или статей на LinkedIn с обзором тривиальных (но всё же полезных) вещей типа генераторов или кортежей . Я пишу на Python уже двенадцать лет, и за это время нашёл кучу очень интересных, недооценённых, уникальных или (как может кто-то сказать) «не-pythonic» хитростей, позволяющих по-настоящему расширить границы возможного для Python. Именно поэтому я решил собрать список из 14 лучших таких фич с примерами и дополнительными ресурсами на случай, если вы захотите изучить их глубже.

https://habr.com/ru/companies/ruvds/articles/905832/

#метаклассы #перегрузка #сигнатуры #дженерики #fстроки #кэш #ruvds_перевод

Кэш. Теория кэширования. Устройство и разновидности кэша

Кэш — это временное хранилище данных, предназначенное для ускорения доступа к часто используемой информации. Он работает по принципу сохранения уже обработанных данных, чтобы при повторном запросе не выполнять те же вычисления или не запрашивать информацию из медленных источников, таких как база данных или внешний сервер. Благодаря кэшу приложения работают быстрее, снижается нагрузка на систему, и пользователи получают мгновенный отклик вместо долгого ожидания. Однако реализация кэша сопряжена с рядом сложностей. Например, нужно решать, какие данные хранить, как долго их держать в кэше и когда удалять устаревшую информацию. Ошибки в управлении кэшем могут приводить к устаревшим / несогласованным данным, или даже к более долгому времени получения ответа, чем без применения кэша. Также важно учитывать ограничения памяти, ведь хранение слишком большого объема данных может привести к излишнему расходу ресурсов и снижению производительности. Перед началом изучения разновидностей кэшей и принципов их работы, предлагаю определить часто используемые термины: Стать гуру кэша

https://habr.com/ru/articles/874546/

#Кэш #system_design #системное_программирование #программирование #кэширование_данных #алгоритмы

[Перевод] Миф о RAM

Миф о RAM — это верование о том, что память современного компьютера напоминает идеальную память с произвольным доступом. Кэш люди считают оптимизацией для малых данных: если они умещаются в L2, то будут обрабатываться быстрее; если нет, то тут уж ничего не поделаешь. Вероятнее всего, что самым быстрым разбиения данных будет такой код (я использую в качестве псевдокода Python; можете представить, что я пишу это на вашем любимом низкоуровневом языке): groups = [[] for _ in range(n_groups)] for element in elements: groups[element.group].append(element) Он и в самом деле линеен (то есть асимптотически оптимален), и мы всё равно должны выполнять доступ к произвольным индексам, так что кэш здесь нам ни в чём бы не помог. В реальности, когда количество групп высоко, такой код не задействует большую часть производительности, а некоторые асимптотически более медленные алгоритмы могут выполнять сегментирование гораздо быстрее. В основном они применяются в базах данных на диске, но, как ни странно, полезны даже в случае данных в RAM.

https://habr.com/ru/articles/868452/

#кэш #работа_с_памятью #оптимизация_кода #озу #оперативная_память

[Перевод] Невероятно быстрый подсчёт байтов

Оказалось, что тема суммирования целых чисел в кодировке ASCII в Haswell со скоростью memcpy гораздо популярнее, чем я мог ожидать. Именно поэтому я решил поучаствовать и в другом челлендже в жанре HighLoad: подсчёт uint8 . В настоящее время я занимаю всего лишь 13 место в списке лидеров, проигрываю первому месту около 7%, но уже узнал немало интересного. В этом посте я полностью опишу моё решение, в том числе, удивительный паттерн считывания из памяти. Используя его, можно примерно до 30% (по сравнению с обычным последовательным доступом) повысить скорость передачи в контексте одноядерных рабочих нагрузок, ограниченных размером кэша. По-видимому, этот метод малоизвестен. Как и в других постах автора, программа настроена для следующих входных характеристик высоконагруженной системы: Intel Xeon E3-1271 v3 @ 3,60 ГГц, ОЗУ 512 МБ, Ubuntu 20.04. В ней используется только AVX2, а AVX512 не используется.

https://habr.com/ru/articles/856334/

#память #кэш #оптимизация #низкоуровневое_программирование

Дилемма 3n+1 на Java. Кэшируем рекурсию

Приветствую всех, сегодня я хочу рассказать про одну из самых интересных неразгаданных загадок математики. Гипотеза Коллатца, или же дилемма 3n+1 прославилась благодаря простоте своей формулировки, при этом оставаясь не доказанной уже более 90 лет. В этом выпуске : обзор самой гипотезы, код-снипеты, кэширование, рекурсия, и много чего еще. Поехали. Краткая формулировка, то бишь немного измененная выдержка из википедии Collatz conjecture — Wikipedia Гипотеза Коллатца — Википедия (wikipedia.org) : Берём любое натуральное число n: 1) Если оно чётное, то делим его на 2, 2) Если нечётное, то умножаем на 3 и прибавляем 1. Над полученным числом выполняем те же самые действия, и так далее.

https://habr.com/ru/articles/839352/

#гипотеза_коллатца #Guava_cache #collatz_conjecture #кэш #оптимизация #3n+1_problem

[Перевод] Компиляторные оптимизации сложны, так как компиляторы забывчивы

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

https://habr.com/ru/companies/timeweb/articles/826998/

#timeweb_статьи_перевод #компиляторы #оптимизация #shl #consumer #acquire #цп #memory #кэш

[Перевод] Сила кэширования: повышаем производительность API и масштабируемость

В этой статье о том, как использовать кэширование для оптимальной производительности API и веб-приложений. А также подробный обзор на методы кэширования на стороне клиента, на стороне сервера и в CDN для более быстрой и надежной работы.

https://habr.com/ru/companies/spaceweb/articles/825030/

#кэш

Как я делаю build больших Android/iOS проектов со 128 GB памяти на старом Mac

Наверняка вы не раз сталкивались с проблемой нехватки памяти на вашем ПК при билде проектов? Недавно мне стало не хватать основной памяти на диске, где установлена система MacOS. Решением проблемы послужило приобретение внешнего SSD диска. Как же настроить работу билдов Android и iOS на внешнем диске и перенести все проекты и приложения? Об этом и пойдет речь в этой статье. Приятного чтения!

https://habr.com/ru/articles/816417/

#внешний_диск #gradle #кэш #kmp #xcodebuild #android_studio

[Перевод] Как Uber обслуживает более 40 миллионов чтений в секунду из онлайн-хранилища с помощью встроенного кэша

Привет, Хабр! Представляю вам перевод статьи "How Uber Serves Over 40 Million Reads Per Second from Online Storage Using an Integrated Cache" автора Preetham Narayanareddy. Из неё вы узнаете, как в Uber проектировалась система кэширования на основе Redis, с какими сложностями и тонкостями пришлось столкнуться разработчикам, и как в итоге им удалось создать действительно высокопроизводительное решение.

https://habr.com/ru/articles/811627/

#кэш #redis #высокая_производительность #базы_данных #архитектура_системы

Эффективное обновление состояний в БД из сервисов потоковой обработки событий

Как хранить сложные сущности в БД? Что нужно сделать, чтобы не перезаписывать весь рекламный баннер для обновления одного лишь заголовка? Рассмотрим как минимум 5 независимых и взаимно совместимых идей для многократного снижения нагрузки на чтение и запись подобных объектов. Меня зовут Юрий Печатнов, я уже 6 лет работаю в Яндексе и занимаюсь сервисами потоковой обработки. Это большие распределенные системы, читающие сообщения из большой распределенной очереди и создающие полезный выход. Полезным выходом могут быть сообщения в другой распределенной очереди и/или обновление состояний в БД. Поговорим о том, как их эффективно обновлять.

https://habr.com/ru/companies/oleg-bunin/articles/788038/

#нагрузка #базы_данных #снижение_нагрузки_на_чтение #снижение_нагрузки_на_запись #потоковая_обработка_данных #распределенные_системы #сжатие_данных #хранение_данных #консистентность #кэш

Новый алгоритм с открытым исходным кодом потенциально может изменить управление веб-трафиком в больших масштабах.
#кэш #очистка
https://news.emory.edu/stories/2024/01/esc_cache_sifting_22-01-2024/story.html

[Перевод] Механизм перезапускаемых последовательностей (Rseq) при работе с TCMalloc

❯ Кэши для отдельных ядер процессора В TCMalloc кэши для отдельных ядер процессора реализуются при помощи перезапускаемых последовательностей (man rseq(2)) под Linux. Эту возможность ядра разработали Пол Тёрнер и Эндрю Хантер из Google , а также Мэтью Дезнойерс из EfficiOS. При помощи перезапускаемых последовательностей можно вплоть до завершения выполнять область памяти (атомарно, относительно других потоков, выполняющихся на том же ядре процессора), либо выходить из этого процесса, если ядро прервёт этот процесс, например, вытеснив его или прервавшись на обработку сигнала. Если вы хотите организовать перезапуск системы при миграции с ядра на ядро или при вытеснении процесса, то наиболее общий случай такой операции можно оптимизировать (не переносить с ядра на ядро тот процесс, который уже выполняется), избегая атомарных операций. Можно оптимизировать и более редкий случай – вытеснение как таковое. В результате такого компромисса нужно обеспечить, чтобы на всех путях выполнения нашего кода поддерживались такие операции перезапуска. Вся последовательность, кроме окончательного сохранения в памяти, когда изменение фиксируется, должна быть приспособлена к перезапуску.

https://habr.com/ru/companies/timeweb/articles/789470/

#timeweb_статьи_перевод #Rseq #TCMalloc #Google #EfficiOS #ядро #ID #ПК #C++ #массивы #ЦП #begin #x86 #процессор #кэш