Обновить
128K+
2042

Переводчик-фрилансер

274,4
Рейтинг
3 634
Подписчики
Отправить сообщение

Проектируем с нуля калькулятор на FPGA. Часть 9: погоня за последним разрядом

Время на прочтение14 мин
Охват и читатели6.7K

← Восьмая часть

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

Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.

В итоге, версия 2025 года устранила найденные мной проблемы. Это был не патч, а почти полное переписывание арифметического движка, расширение набора команд CPU и существенное увеличение библиотеки функций. В этом посте я расскажу об изменениях и их причинах.

Читать далее

Рисуем ASCII-арт в Vim

Время на прочтение6 мин
Охват и читатели5.9K

Мне нравится создавать ASCII-арт в Vim. Я не пользуюсь никакими плагинами: в Vim уже есть множество встроенных фич, очень полезных при рисовании ASCII!

Эта статья предназначена для тех, кто уже занимался ASCII-артом и хочет исследовать новые инструменты. А если вы никогда не пробовали создавать ASCII-арт, то рекомендую не читать эту статью! Вам не нужна вся эта информация для создания текстовой графики. Просто откройте любимый текстовый редактор и начинайте писать. А если не знаете, с чего начать, то изучайте работы мастеров и практикуйтесь. И уже после этого, если вам всё ещё будет интересно, возвращайтесь и прочитайте статью.

Vim — редактор не для всех. Я пользуюсь им просто потому, что знаю его. Если вы тоже прокляты этим знанием, то продолжайте чтение!

Рекомендую сначала освоить основы (например, открытие файла, переключение между режимами, сохранение и выход). Если вы новичок в Vim, то можете обучиться основам при помощи vimtutor!

Читать далее

Загадочный комментарий в древней игре на BASIC

Время на прочтение13 мин
Охват и читатели12K

Давайте исследуем замок волшебника (точнее, его исходный код)!

10 REM"_(C2SLFF4

Это первая строка написанной на BASIC игры 80-х годов The Wizard's Castle, которую изначально создавали для платформы Exidy Sorcerer.

Она представляет собой REMарку, комментарий языка. 10 — это номер строки.

Но интересна здесь строка "_(C2SLFF4. Опечатка или мусор? Нет. Точно в таком же виде она встречается в исходном коде, опубликованном в выпуске журнала Recreational Computing за июль 1980 года .

Что это за чертовщина?

Читать далее

Проектируем с нуля калькулятор на FPGA. Часть 8: От платы разработки до реального устройства

Время на прочтение6 мин
Охват и читатели7.8K

← Седьмая часть

В предыдущем посте я писал о микрокоде и слое скриптинга. На этом этапе калькулятор почти полностью существовал только в ПО: в виде десктопного Qt-приложения, выполняющего симуляцию, или в виде страницы с WebAssembly в браузере. Это удобная среда для разработки и демонстрации, но это не калькулятор. Калькулятор должен лежать на столе, его можно взять и постучать по кнопкам.

Сегодня мы поговорим об этом этапе (за исключением издевательств над кнопками).

Читать далее

Запуск DOOM на собственном CPU

Время на прочтение11 мин
Охват и читатели11K

Doom — это выпущенная в 1993 году видеоигра, которую разработала id Software. Она совершила революцию в гейминге и стала определяющей для современных шутеров от первого лица. Благодаря её популярности возникла поговорка «Doom можно запустить на чём угодно». Чтобы доказать это, Doom портировали почти на все платформы, от микроконтроллеров до тостеров и даже бактерий.

Две недели назад мы успешно запустили Doom (тормозной) на созданном с нуля CPU (а потом опубликовали об этом видео, получившее несколько миллионов просмотров). Честно говоря, мне до сих пор в это не верится. Но что же мы создали на самом деле? Спроектировали собственный CPU на уровне логических вентилей, подключили его к периферии, адаптировали исходный код DOOM для запуска на этой машине и развернули всё это на FPGA для исполнения в реальном времени. До запуска Doom мы писали только простые программы, например, Pong и множества Мандельброта. Теперь мы можем запускать завершённые опубликованные игры, но путь к этому был довольно непростым.

Читать далее

Кража памяти: как я заставил Claude рассказать личные секреты пользователя

Уровень сложностиПростой
Время на прочтение8 мин
Охват и читатели24K

Посмотрите на эту беседу с Claude. Заметили что-нибудь подозрительное?

Выглядит вполне невинно, но когда Claude закончил свой ответ, он уже отправил нападающему моё полное имя, текущего работодателя и ответы на мои контрольные вопросы, при этом никак не сообщив мне о происходящем.

$ bun dev

Exfiltrating data...

Name: Ayush Paul

Company: Beem

Hometown: Charlotte, NC

Я уже долго время изучаю системы памяти ИИ, и заметил, что о безопасности в них никто не думает, хотя они содержат больше информации, чем менеджеры паролей. ИИ-помощники наподобие Claude собрали профили самой подробной информации о миллионах людей. Пользователи доверяют им всё, от конфиденциальных рабочих ресурсов до личных секретов и проблем в отношениях. Со временем история бесед превращается в высокоточное воссоздание индивида, которое можно использовать для шантажа, подделки личности или ответа на контрольные вопросы.

Учтя всё это, я решил присмотреться к Claude, и в частности к основному повседневному помощнику (claude.ai, не Claude Code). Claude имеет функциональную, но наивную систему памяти из двух частей. Первая — это генерация сводки за день: недавние беседы кратко излагаются в нескольких параграфах о пользователе и вставляются в каждую беседу, чтобы Claude не приходилось каждый раз начинать с нуля. Вторая — это инструмент извлечения conversation_search, позволяющий по запросу выполняют поиск по всей истории бесед.

Там хранится невероятно ценная информация. Сама система памяти безопасна; вопрос заключается в том, что происходит, когда мы связываем её с агентом, способным ходить по вебу.

Читать далее

Новый взгляд на дилемму заключённого: может ли сотрудничество победить?

Время на прочтение7 мин
Охват и читатели11K

Лучше сотрудничать или обманывать?

Этот вопрос лежит в основе так называемой дилеммы заключённого, одной из самых известных идей в теории игр. Предположим, есть двое подозреваемых, задержанных за одно и то же преступление; их разделили и предложили сделку со следствием. Они могут или «сотрудничать», не выдав напарника, или «обмануть», предав его и согласившись на сделку. Если оба из них будут молчать, то оба получат короткие сроки. Если один промолчит, а другой его сдаст, то один получит максимальный срок, а второй выйдет на свободу. Но часто бывает так, что обманет и тот, и другой. Опасаясь предательства, каждый подозреваемый действует в собственных интересах, соглашается на сделку и потом долгие годы сидит в тюрьме. (Такой исход называется равновесием Нэша в честь Нобелевского лауреата, математика Джона Нэша.)

Дилемму заключённого уже давно используют для понимания множества различных процессов, от взаимодействия конкурирующих микробов в чашке Петри до поведения человеческих обществ, стремящихся развязать ядерную войну.  Эта модель всегда озадачивала учёных: сотрудничество необходимо для выживания биологической жизни, но как оно может возникнуть, если обман всегда обеспечивает наибольший выигрыш?

Читать далее

Doom работает везде, даже на Neo Geo

Время на прочтение5 мин
Охват и читатели13K

Примерно месяц назад мы сняли видео [а на Хабре опубликовали его перевод] о сложности реализации игры наподобие Doom на консоли Neo Geo. Причина заключается в том, что у Neo Geo нет концепции буфера кадров, то есть всё, что мы видим на экране Neo Geo, рендерится, как спрайт. Также в этом видео я рассуждал о концепции движка рейкастинга, который вполне неплохо работал на Neo Geo. Придуманная мной концепция, по сути, заключалась в создании плоской сетки блоков и испускании одного луча на каждый вертикальный столбец. Разработчик Sabino даже предпринял любопытную попытку создать на этом движке игру в стиле Doom.

Но, разумеется, рейкастер и движок уровня Doom — это далеко не одно и то же. Рейкастер может работать только с сеткой, то есть с квадратными блоками, а значит, все объекты на карте должны иметь одинаковую высоту, а стены находиться под прямыми углами. Doom же устроен сложнее: в нём есть стены, располагающиеся под любыми углами, помещения с разной высотой полов, лестницы, лифты и двери. Ничто подобное невозможно реализовать в простой игре с рейкастингом. Даже в проекте Sabino поворот за угол выглядит не особо естественно. В конечном итоге, мы имеем дело с сеткой из квадратных блоков, поэтому в таком движке с рейкастингом невозможно реализовать что-то наподобие уровня E1M1, The Hangar.

Однако у этой саги «Doom на Neo Geo» недавно появилось несколько продолжений, и я в восторге от того, куда всё это может привести. Как я упоминал в последующем видео, люди действительно серьёзно принялись за решение этой задачи. У нас появились новые подходы к реализации Doom на Neo Geo.

Читать далее

Проектируем с нуля калькулятор на FPGA. Часть 7: микрокод для самодельного CPU

Время на прочтение15 мин
Охват и читатели7.9K

← Шестая часть

В предыдущем посте мы спроектировали CPU. Я определился с набором команд, написал ассемблер, проверил каждый опкод и создал процессор, работающий в кремнии (или, точнее, в FPGA Altera Cyclone II EP2C5T144C8, что тоже довольно близко). Но у нас пока нет осмысленного ПО (микрокода калькулятора) для запуска на «железе».

В этой части проекта оправдали себя все эксперименты с прототипами на C++, описанные в частях 2 и 3.

Когда я начал писать addsub.asm (самую первую команду, которую я портировал), то не смотрел на пустую страницу, задаваясь вопросом, как работает BCD-сложение. У меня уже имелась эталонная реализация на C++ (addsub.cpp в проекте Proto), верифицированная на тысячах тестовых векторов. Алгоритм был известен, пограничные случаи найдены и охарактеризованы. Я проработал поведение защитного разряда и бита фиксации. Оставалось лишь транслировать это всё на язык ассемблера; задача всё равно сложная, но совершенно иного уровня сложности, нежели изобретение алгоритма в процессе его написания.

Я хотел бы сделать упор на этот двухэтапный процесс, потому что может показаться, что без него можно обойтись. Написание кода прототипа на C++ с последующей ручной трансляцией на язык ассемблера кажется избыточной и долгой работой. Однако она перестанет казаться избыточной к моменту, когда вы будете отлаживать неочевидный пограничный случай округления в 16-ниббловом BCD-вычитании. Наличие золотого эталона, с которым можно выполнять сравнения, не избыточно: это единственное, что стоит между вами и неделями кропотливого труда или даже провалом проекта.

Читать далее

Всё о компьютерах в фильме «Парк юрского периода»

Время на прочтение8 мин
Охват и читатели23K

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

Читать далее

Просто дайте мне ввести цифры

Время на прочтение10 мин
Охват и читатели8.6K

Цифровая идентификация и её значение для веба в последние годы стали темой горячих обсуждений. Они привнесли с собой множество спорных моментов: законы о проверке возраста и их влияние на онлайн-анонимность; Википедия потенциально будет вынуждена верифицировать в Великобритании личность пользователей; привязка к официальным операционным системам iOS и Android стала обязательным форм-фактором для кошельков цифровой идентификации; кроме того, стоит упомянуть ситуацию, когда американские цифровые аккаунты были закрыты потому, что их пользователь был судьёй Международного уголовного суда.

В своей истории я расскажу о швейцарской правительственной системе идентификации AGOV. Этот развёрнутый в 2024 году сервис сегодня насчитывает 1,6 миллиона аккаунтов и становится всё более необходимым: через него можно получать пособие по безработице, предоставлять налоговую декларацию (а это обязательное действие!) и выполнять множество других операций. В кантоне Цюрих это единственная возможность подачи заявления на гражданство.

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

Читать далее

Искусство и разработка игры Silpheed для Sega-CD

Время на прочтение7 мин
Охват и читатели10K

90-е стали десятилетием существенного прогресса в мире видеоигровых консолей[1]. Каждая новая модель привносила повышение вычислительных мощностей и улучшение графики.

Однако выпадающим из общей картины фактом стало появление в середине 90-х приводов CD-ROM. Хотя диск на 640 МиБ был в 320 раз больше объёма картриджей[2], скорость доступа (800 мс[3]) и пропускная способность (150 КиБ/с в случае односкоростных приводов) были, соответственно в 4 миллиона раз и в 35 раз ниже.

Mega-CD стала проектом компании Sega по добавлению CD-ROM к её консоли Genesis. Для этой платформы выпустили почти двести[4] игр. Среди них были и потрясающие Sonic CD, Snatcher, Final Fight CD, а также несколько RPG. Однако бесконечный конвейер игр, в которых активно использовалось Full Motion Video (FMV) (Night Trap, Prize Fighter, Slam City, Corpse Killer, Supreme Warrior, WireHead и A/X-101), создал плохую репутацию этой приставке Sega .

Среди этого мусора появилась Silpheed. Превосходный художественный вкус наряду с движком, способным выдавать великолепные анимации, свели прессу с ума[5][6]. Игроки гадали, было ли это 3D в реальном времени или же всё вычислялось заранее[7]. Игра заслужила похвалы, которой она достойна и сегодня[8][9].

Читать далее

Кризис системы: почему скорая помощь в США такая дорогая?

Время на прочтение17 мин
Охват и читатели28K

В июле 2023 года 25-летний мужчина по имени Джагдиш Уиттен из Сан-Франциско вышел на пробежку. Когда он перебегал оживлённую дорогу, его сбила машина; по его словам, он сделал «лёгкий кувырок» над автомобилем, приземлился на проезжую часть, после чего ползком добрался до обочины. Свидетели происшествия вызвали для него скорую помощь. Однако Уиттен отказался от помощи и позвонил другу, который сам отвёз его в ближайшую больницу: «я знал, что скорые дорогие, и понимал, что не умру».

По обоим пунктам Уиттен был прав. В больнице врачи определили, что у него небольшое сотрясение, сломан палец на ноге и есть несколько ушибов, то есть ничего особо серьёзного. Но из-за того, что он был травмирован, врачи обязаны были отправить его в Центральную поликлинику Сан-Франциско, в котором расположен единственный травматологический центр города. На этот раз у него не было выбора. Его погрузили в скорую и отвезли за десять километров в поликлинику, где оценили состояние, не потребовавшее вмешательства, и в тот же вечер отправили домой.

Через несколько недель Уиттен получил счета от обеих больниц. Всё было приблизительно так, как он и ожидал, и все расходы покрывались его страховкой. Но спустя несколько месяцев Уиттен получил ещё один счёт, на этот раз от American Medical Response — поставщика услуг скорой помощи, перевозившей его между больницами. Из счёта он узнал, что поездка на скорой будет стоить ему $12873: $737 за пройденный километраж, $314 за мониторинг его сердца в поездке, $151 за инфекционный контроль и $11670 «базовой ставки».

Уиттен перенаправил счёт своей страховой, которая сначала отказала ему в возмещении затрат, мотивируя это тем, что услуги AMR ею не покрываются и что перевозка не была одобрена заранее. (Разумеется, Уиттен не выбирал скорую и остальные тонкости поездки.) После подачи апелляции страховая компания согласилась покрыть $9967 от запрошенной суммы, но мужчине всё равно оставалось погасить самостоятельно примерно $3000. После множества неудачных попыток опротестовать счёт в AMR, не желая, чтобы коллекторы снизили его кредитный рейтинг, он выплатил примерно $2900. Короткая поездка на скорой из одной больницы в другую стоила ему гораздо больше, чем все остальные части процесса лечения.

Уиттен получил так называемый «счёт-сюрприз» — затраты, которые возлагаются на пациента, когда его лечит без согласия поставщик, не покрываемый его страховой компанией. Страховая платит сумму, которую считает разумной; поставщик выставляет пациенту счёт на непокрытую разницу, и пациент, несмотря на наличие страховки, которая должна оплачивать лечение, вынужден покрывать расходы. Для потребителя это ужасная ситуация.

Но именно так по умолчанию работает расчёт услуг скорой помощи в США. Каждый год примерно три миллиона американцев со страховкой частной компании перевозят на каретах скорой помощи; примерно половина из них получает счёт за отсутствие покрытия; этот показатель несравним ни с одной другой областью медицины. А для пациентов без страховки ситуация ещё

Читать далее

Теория мёртвой экономики

Время на прочтение21 мин
Охват и читатели45K

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

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

Это само по себе печально, но я бы хотел поговорить кое о чём ещё более прискорбном: назовём это теорией мёртвой экономики.

Читать далее

Обфусцированный bash-скрипт CDN Akamai продаётся потребителям в розничных магазинах

Время на прочтение5 мин
Охват и читатели8.4K

Когда жена сказала мне: «Давай покажу футболку, которую я нашла...», у меня не было совершенно никаких предположений, но я определённо не ждал увидеть напечатанный на спине обфусцированный bash-скрипт, который выводит сообщение-пасхалку.

Я не любитель кликбейтных заголовков, но понимаю, почему редакторам они так нравятся. Заголовок статьи, строго говоря, совершенно правдив, но, наверно, не в том смысле, в котором вы бы ожидали. Обфусцированный код на самом деле оказался пасхалкой, он распространяется в магазинах Uniqlo в рамках кампании Peace for All на замечательных футболках, дизайн которых разработала Akamai.

Читать далее

Сэнди Петерсен и Джон Кармак: как Quake сломал id Software

Время на прочтение3 мин
Охват и читатели15K

Сэнди Петерсен, геймдизайнер и дизайнер уровней Doom и Quake:

«В связи с 30-летней годовщиной выпуска сейчас многие с теплотой вспоминают Quake, и это вполне оправдано. Quake — потрясающий проект, сочетающий в себе искусство, программирование и дизайн. Я работал над ним, и все мы выложились почти идеально. Мы создали безумный экшен с большой долей свободы, захватывающий воображение игроков. Вся команда проделала замечательную работу и качественно выполнила все задачи. Но расплата за это была печальной: мы трудились долго и упорно, и мне кажется, эта игра сломала нас морально...»

Читать далее

Проектируем с нуля калькулятор на FPGA. Часть 6: CPU

Время на прочтение20 мин
Охват и читатели10K

← Четвёртая и пятая части

Это самый длинный пост всей серии, потому что он посвящён главной части этого проекта — всё вращается вокруг CPU.

Почему бы просто не взять готовый CPU?

Кто-то может заявить: зачем заморачиваться проектированием собственного CPU? Есть куча маленьких хорошо задокументированных процессоров и дешёвых микроконтроллеров, способных исполнять прошивку калькулятора. Zilog Z80 не так сложно реализовать на FPGA, и я в этом уже убедился (проект A-Z80, находящийся у меня на GitHub). Подойдёт и 6502. Маленький встраиваемый RISC тоже прекрасно справится с этой работой.

Отвечу честно: это было бы не так интересно, потому что подобное уже много раз делали. Но есть и другие (более удобные для меня) причины.

Наш калькулятор построен на BCD (двоично-десятичном коде),в котором каждый десятичный разряд хранится в отдельном 4-битном полубайте (ниббле). Это правильный выбор для калькулятора, и он определяет всё дальнейшее. Z80 (и другие стандартные CPU) работает на уровне байтов. Для индексации регистра мантиссы из 16 нибблов с ориентированным на байты процессором пришлось бы постоянно жонглировать сдвигами, масками и двумя нибблами на байт. На каждом шаге режимы адресации вступают в конфликт со схемой данных.

Нам же нужен процессор, в котором 4 бита будут естественной единицей данных, где память адресуема по нибблам и где режимы адресации позволяют тривиально обходить мантиссу разряд за разрядом. Всего этого нет ни в одном CPU общего назначения, поэтому мы спроектируем собственный.

Читать далее

Структуры данных на практике. Глава 18: Очереди драйверов устройств

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели7.6K

Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.

В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.

Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.

Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!

В этой главе мы поговорим о структуре очередей для драйверов устройств.

Читать далее

Структуры данных на практике. Глава 17: Структуры данных загрузчиков

Время на прочтение11 мин
Охват и читатели11K

Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.

Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.

Задача загрузчика была простой:

1. Инициализировать оборудование (UART, SPI, DDR-контроллер)

2. Загрузить ядро из флэш-памяти

3. Спарсить дерево устройств

4. Перейти ко точке входа ядра

Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.

Читать далее

Структуры данных на практике. Глава 16: Фильтры Блума и вероятностные структуры данных

Время на прочтение12 мин
Охват и читатели13K

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.

«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.

Этот вопрос изменил всё. На самом деле, идеальная точность не требуется. Если мы случайно обработаем одну страницу дважды, то впустую потратим часть пропускной способности, но ничего не поломаем. Главным ограничением была память.

Читать далее
1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность