Переводчик-фрилансер
Я давний пользователь устройств Apple, и меня всегда радовала беспроблемная интеграция оборудования и ПО, ставшая отличительной чертой экосистемы Apple. Однако мой недавний опыт взаимодействия iPad Air 11" M2 заставил меня задаться вопросом, не потеряла ли Apple видение того, что раньше делало её продукты исключительными.
Deep Research компании OpenAI создан для меня, но я не могу им пользоваться. Это ещё одно потрясающее демо, увы, поломанное. Но ломается оно очень интересным образом.
По большей мере я зарабатываю на жизнь исследованиями и анализом. Я думаю о данных, которые хочу увидеть, и ищу их; собираю и сопоставляю их, создаю графики, решаю, что они скучные, и пробую снова, нахожу новые способы и новые данные для понимания и объяснения проблемы, пишу текст и составляю графики, пытаясь выразить то, что я думаю. А потом я разговариваю об этом с людьми.
При этом часто требуется большой объём ручного труда: под каждым графиком скрывается айсберг. И похоже, Deep Research предназначен именно для меня. Подходит ли он под мои задачи?
Я могу протестировать его на новой задаче, но прежде чем тратить время и кредиты, к счастью, можно воспользоваться образцом отчёта со страницы OpenAI. Этот отчёт посвящён тому, что я достаточно хорошо изучил — смартфонам. Давайте исследуем его.
Совсем недавно моя машина была в таком запущенном состоянии, что я едва мог подключиться к ней через ssh. 3200% нагрузки на CPU — полностью использовались все 32 ядра хоста! Сравните это с моим последним багом, когда использовалось всего одно ядро, то есть 100%
К счастью, я использовал среду выполнения Java 17, у которой были дампы потоков с указанием времени CPU!
Эта анимация Рика состоит из 240 строк кода. Никаких библиотек и изображений. В статье я покажу, как использовать шейдеры GPU и поля расстояний со знаком для создания подобных анимаций для видео, видеоигр и просто для развлечения! В оригинале статьи даже есть интерактивный редактор кода, благодаря которому вы сможете поэкспериментировать с примерами.
Взгляните на эти два QR-кода. Отсканируйте их, если хотите: обещаю, в них нет ничего опасного.
Слева HTTPS://EDENT.TEL/ в верхнем регистре, а справа — https://edent.tel/ в нижнем.
Можно чётко заметить, что слева QR-код «меньше», то есть в нём меньше битов данных. Оба ведут на один и тот же URl, единственное различие заключается в регистре.
Что здесь происходит?
Во французском сабреддите я наткнулся на пост с интересной гипотезой:
Чем ближе точка к вокзалу, тем хуже там кебаб.
Пост на французском привлёк достаточно большое внимание, учитывая относительно небольшой размер сабреддита; это доказывало, что многие с ним согласны. Впрочем, в комментариях были и критики, рассказывающие истории, противоречащие сформулированной гипотезе.
Я решил, что мне нечем заняться, ведь я вылетевший с учёбы выгоревший безработный с новоприобретённым диагнозом «аутизм», поэтому стоит пожертвовать немного своего времени на благую цель — проведение этого неформального «исследования». В пределах следующих трёх рабочих дней мне на почту точно придёт Нобелевская премия мира и куча рабочих офферов.
Есть одна очень миленькая математическая задачка, которая может быть интересна людям на очень разных уровнях:
У вас есть четыре двойки и какое-то целевое натуральное число. При помощи любых математических операций сгенерируйте целевое число при помощи этих двоек, не используя больше никаких цифр.
Некоторые примеры могут придумать и дети из начальной школы. В средних классах дети узнают о степенях, факториалах и так далее, что существенно расширяет диапазон.
Что вы делаете с незакрытыми вкладками браузера? На мой взгляд, они занимают слишком много места на экране, поэтому на этой неделе я разобрался, как запустить в этих вкладках Pong.
Это 240 вкладок браузера в плотной сетке 8x30. И в них запущен Pong! Видно, что мяч и ракетки перемещаются по canvas в окне и во всех вкладках.
Код (ужасный) можно посмотреть на GitHub. Но как он работает?
Когда я написал статью о том, почему установщик Windows 95 использовал три операционные системы [перевод на Хабре], в которой сказал, что установщик на основе MS-DOS был бы текстовым, то мне возразили: «Но ведь MS-DOS могла отображать графику! Вы что там, все глупые?»
Да, MS-DOS могла работать с графикой, в том смысле, что она не очень мешала программисту работать с графикой. Но абсолютно всё ему приходилось делать самому. Не существовало графических примитивов, кроме вызова BIOS для отрисовки отдельного пикселя. Всё остальное было на разработчике, который и не собирался пользоваться вызовом BIOS для отрисовки пикселей, потому что он был медленным. Чтобы добиться хоть какой-то производительности, приходилось непосредственно работать с буфером кадров.
Итак, теперь нам нужно написать графическую библиотеку для отрисовки чего-то сложнее, чем отдельный пиксель. К счастью, для Windows 95 требовалась минимум VGA-видеокарта, поэтому ей не приходилось беспокоиться о CGA или EGA. Напомню, что VGA-адаптер требовал работы с планарными режимами, что было очень утомительно. К счастью, у нас есть способная помочь команда спецов по планарным режимам VGA, работающая в соседних кабинетах над видеодрайверами Windows.
За последние три недели я устранил пару проблем с производительностью, что потенциально сэкономило компании несколько сотен тысяч долларов (я подрядчик, поэтому, к сожалению, не получаю никаких премий).
Как я нашёл эти проблемы? Можно назвать это необъяснимой, основанной на опыте интуицией, шестым чувством нёрда; у меня просто возникло ощущение, что с системой что-то не так. За свои двадцать с лишним лет опыта я видел множество приложений и знал, что где-то в этой системе есть узкое место.
Я создал тестовый сценарий, чтобы точно замерить пропускную способность системы от времени, запустил инстанс VisualVM и прошерстил десятки потоков, трассировок стеков, снэпшотов памяти и CPU. Я обнаружил проблемы, написал их исправления и запустил всё заново. Бум! Производительность возросла в десять с лишним раз. Мой начальник и коллеги были счастливы, а продуктивность повысилась. Меня похвалили, и я ощутил отдачу от выполненного долга.
Но стоит помнить, что, строго говоря, это не были баги. Успешно проходили все юнит-тесты и интеграционные тесты, тесты BDD, линтеры, статический анализ кода и было выполнено несколько раундов проверок кода. Проблемы заключались в двух невинных строках кода (спрятанных среди тысяч других), казалось бы, не вызывавших никаких трудностей. Слава Богу, проблемы были найдены на этапе разработки и не затронули ни одной системы в продакшене (мои коллеги теперь могли выполнять свои тесты быстрее, поэтому скорость разработки сильно возросла).
Как уместить словарь размером 250 КБ в 64 КБ ОЗУ с возможностью выполнения быстрого поиска? Для справки: даже современные методики сжатия наподобие gzip -9 не могут сжать этот файл до размера меньше 85 КБ.
В 1970-х Дуглас Макилрой столкнулся с этой непростой задачей при реализации проверки правописания для Unix в AT&T. Из-за ограничений компьютера PDP-11 весь словарь должен был умещаться всего в 64 КБ ОЗУ. Кажется, подобную задачу решить невозможно.
Вместо того, чтобы использовать стандартные методики сжатия, Дуглас воспользовался преимуществами свойств данных, разработав алгоритм сжатия, отличавшийся от теоретического минимума сжатия всего на 0,03 бита. И по сей день этот рекорд остаётся непревзойдённым.
История spell в Unix — это не только любопытный исторический факт. Это мастер-класс по проектированию в условиях жёстких ограничений: анализа первооснов задачи, применения математических наблюдений и проектирования изящных решений, работающих в условиях строгого дефицита ресурсов.
[Прим. пер.: на Хабре уже был перевод этой статьи, но незавершённый примерно на четверть.]
Неправда.
Калькулятор должен показывать результат введённого математического выражения. А это намно-о-ого сложнее, чем кажется.
В этом посте я расскажу величайшую историю о разработке приложения-калькулятора.
На изображении выше показан калькулятор из iOS.
Заметили что-нибудь?
Он посчитал неправильно.
(10100) + 1 − (10100) равно 1, а не 0.
Android считает правильно. А причина, по которой он это делает, абсолютно безумна.
Меня заинтриговал комментарий GuB-42 на Hacker News:
При помощи последовательностей ZWJ (Zero Width Joiner) теоретически можно закодировать в один эмодзи неограниченный объём данных.
Действительно ли можно закодировать в один эмодзи произвольные данные?
tl;dr: да, однако я нашёл решение и без ZWJ. На самом деле, можно закодировать данные в любой символ Unicode. Например, в этом предложении есть скрытое послание: This sentence has a hidden message󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑. (Попробуйте вставить его в декодер.)
Рендеринг обводки (контуров) — это техника, часто используемая в играх или из эстетических, или из геймплейных соображений. Например, в игре Sable контуры применяются для создания стиля, напоминающего комиксы, а в The Last of Us контуры используются для выделения врагов, когда игрок переходит в режим скрытности.
В этом посте мы расскажем о пяти способах рендеринга контура вокруг объекта.
Неопределённое поведение (undefined behavior, UB) в языке программирования C — постоянный источник жарких споров между программистами. С одной стороны, UB может быть важным для оптимизаций компилятора. С другой стороны, оно упрощает появление багов, которые приводят к проблемам безопасности.
Хорошая новость: N3322 был принят для C2y, что позволит устранить неопределённое поведение из этого конкретного участка языка C и сделать всё показанное ниже чётко определённым:
memcpy(NULL, NULL, 0);
memcmp(NULL, NULL, 0);
(int *)NULL + 0;
(int *)NULL - 0;
(int *)NULL - (int *)NULL;
Итак, теперь у нас есть первая приблизительная оценка видимости листьев из порталов, хранящаяся в массиве mightsee каждого портала. Вычислять, что именно видно через последовательность порталов, сложно, поэтому мы вместо этих вычислений используем «консервативную» оценку. Она ни за что не скроет лист, который должен оставаться видимым.
«Это просто задача отсечения»
Свет внезапно выключается. Вы сидите в огромном конференц-зале. Кто-то включает проектор. На экране сам Майкл Абраш! Похоже, это знаменитый доклад Quake Postmortem с GDC 1997.
Он говорит о порталах.
Мы берём плоскости отсечения, ограничивающие максимальный объём видимого, и отсекаем их по всё более дальним порталам, пока они не пропадут.
Градиентное текстурирование — это методика оптимизации 3D-текстурирования, в первую очередь предназначенная для мобильных видеоигр. В ней используются текстурные карты низкого разрешения и градиентные цвета, позволяющие снизить ресурсную нагрузку на игровые без ущерба качеству графики. Благодаря применению градиентов в низкополигональных 3D-моделях симулируются такие эффекты, как освещение, тени и глубина, позволяя избавиться от необходимости в текстурах высокого разрешения, потребляющих больше ресурсов.
Эта методика обеспечивает эффективный баланс между производительностью и визуальным качеством, оптимизирует время загрузки и улучшает игровой процесс. Кроме того, она позволяет гибко менять цветовые палитры и может адаптироваться под разные 3D-модели, снижая размеры файлов и оптимизируя использование памяти.
Цель ARC Prize Foundation — определять и измерять потенциал идей, делающих вклад в создание AGI. Для этого мы стремимся создавать самую надёжную международную среду для инноваций.
Пока у нас нет сильного искусственного интеллекта (AGI), а инновации по-прежнему ограничены: увеличение масштабов чистого предварительного обучения LLM — ошибочный путь, хоть он и остаётся доминирующим в отрасли ИИ и в глазах широкой публики.
Такие нарративы важны, потому что они влияют на экономическую активность, например, на инвестиции, темы исследований, финансирование, геополитику и так далее. Например, в 2023-2024 годах в новые LLM-стартапы инвестировали примерно 20 миллиардов долларов. Для сравнения: в новые AGI-стартапы инвестировали всего около 200 миллионов долларов.
Мы создали в июне премию ARC 2024, чтобы привлечь внимание к ограничениям масштабирования LLM и повысить популярность полезного бенчмарка ARC-AGI-1 при движении в новом направлении, требующем от ИИ-систем адаптации к новым, неизвестным им задачам, а не полагаться только на запоминание.
TLDR: ИИ — это не ваш помощник, а разработчик-джун, имитирующий профессионализм. Доверяйте ему на свой страх и риск.
Я уже четыре дня занимаюсь своим хобби-проектом. Я был уверен, что реализую его. У меня был хороший план и большой интерес к проекту. Позвольте мне познакомить вас с Deskthang. Это настольный уведомлятор. Во время работы я хочу оставлять свой телефон в другой комнате и получать только важные уведомления. В случае сбоя конвейера развёртывания я хочу, чтобы устройство на моём столе загоралось красным и показывало мне логотип gitlab. Я не хочу, чтобы мне приходилось проверять телефон, почту или другие источники, которые могут отвлечь от работы.
Вы когда-нибудь хотели узнать, как работала предварительно вычисленная видимость в Quake? Я хотел, поэтому написал программу vis.py, воссоздающую этот алгоритм на Python. В этой статье представлена вся информация, необходимая для понимания vis, — инструмента, применявшегося в Quake, Half-Life и играх на Source Engine.
В процессе разработки Quake возникла проблема перерисовки (overdraw), то есть многократной записи одного и того же пикселя во время рендеринга кадра. Видимым остаётся лишь последний цвет, а все предыдущие записи оказываются лишней тратой ресурсов. Это плохо, если в вашей игре используется программный рендеринг, и так выжимающий последние соки из компьютера середины 90-х годов.
Как снизить объём перерисовки? Давайте начнём с высокоуровневого обзора возможных решений.