Сегодня обнаружил на балконе синицу. Само по себе это было бы непримечательно, но все форточки были закрыты, и мы с женой отчетливо помним, что закрывали их 31 декабря. Видимо, птица залетела раньше и то ли проспала три дня, то ли заныкалась куда-то и в итоге выбралась на поиски еды.
Мой текущий "колхозный" метод чайной церемонии - две кружки и большое ситечко. Время заваривания определяю "на глазок", по наитию и на основе экспериментов над собой. Просто, без изысков, но меня устраивает.
Затестил гунфу. Вроде как работает, заварок можно сделать много. Но одна заварка - это где-то одна пиалка. Если считать итоговый объём напитка, выходит в пользу "колхозного" метода. Да и всяких телодвижений туда-сюда с гунфу из-за количества заварок на тот же объём получается больше.
Бывают, конечно, гунфу крупнее. Но чай я почти всегда пью один. Если очень потребуется, смогу организовать импровизированный чахай.
Так что пока я не выкупил глубокий смысл деления чайника на две колбы. Гунфу встаёт дома на полку для случаев, когда я захочу повыделываться или понаблюдать за раскрытием чайного листа.
Затестил гунфу. Вроде как работает, заварок можно сделать много. Но одна заварка - это где-то одна пиалка. Если считать итоговый объём напитка, выходит в пользу "колхозного" метода. Да и всяких телодвижений туда-сюда с гунфу из-за количества заварок на тот же объём получается больше.
Бывают, конечно, гунфу крупнее. Но чай я почти всегда пью один. Если очень потребуется, смогу организовать импровизированный чахай.
Так что пока я не выкупил глубокий смысл деления чайника на две колбы. Гунфу встаёт дома на полку для случаев, когда я захочу повыделываться или понаблюдать за раскрытием чайного листа.
Как же меня ЗА Е БА ЛО играть перестрелку
P.S. хорошо, что её в итоге не было
P.S. хорошо, что её в итоге не было
Я привык, что к технологиям предъявляют довольно серьёзные требования. Процессор? Должен грузить Linux, гонять SPECInt и не разваливаться от stress-ng. JVM? Должен запускать Eclipse, IDEA, ну и хотя бы Glassfish. Компилятор Си? Должен собирать ядро Linux и показывать хотя бы на самых базовых бенчмарках типа CoreMark результаты, не слишком далёкие от GCC. И так далее. Кроме шуток, это всё непросто (хотя и не сказать, чтобы слишком сложно). Это некоторый барьер, который необходимо преодолеть, чтобы с тобой разговаривали, как со взрослым.
В вопросах, связанных с ИИ, я наблюдаю, что в качестве такого критерия зрелости нередко принимается демонстрация того, что ИИ в принципе что-то может. Например, написать компилятор Си. Это, конечно, большой шаг по сравнению с “ИИ не смог”, и Claude CC - это большое достижение в мире ИИ. Но дальше начинается самое интересное.
Claude CC довольно неплохо справился с задачей “пройти gcc-torture” (99%). Но написать оптимизатор у роботов не получилось практически совсем. У белковых, конечно, это тоже не всегда выходит. Современный оптимизирующий компилятор С - это плод труда большого числа инженеров, каждый из которых занёс свой +0.1% на геомине. Но ИИ не оказался даже близко. Можно сказать, не явился на соревнования.
Какие из этого выводы? Никаких, ждём, когда роботы смогут что-то ещё.
В вопросах, связанных с ИИ, я наблюдаю, что в качестве такого критерия зрелости нередко принимается демонстрация того, что ИИ в принципе что-то может. Например, написать компилятор Си. Это, конечно, большой шаг по сравнению с “ИИ не смог”, и Claude CC - это большое достижение в мире ИИ. Но дальше начинается самое интересное.
Claude CC довольно неплохо справился с задачей “пройти gcc-torture” (99%). Но написать оптимизатор у роботов не получилось практически совсем. У белковых, конечно, это тоже не всегда выходит. Современный оптимизирующий компилятор С - это плод труда большого числа инженеров, каждый из которых занёс свой +0.1% на геомине. Но ИИ не оказался даже близко. Можно сказать, не явился на соревнования.
Какие из этого выводы? Никаких, ждём, когда роботы смогут что-то ещё.
>> Скормил твою реплику ChatGPT 5.4 extended thinking. Он согласен с тобой. Интересен полный ответ?
Да. Здесь различие очень существенное.
Есть, грубо говоря, два порога. Первый — порог ненулевой способности: система вообще может породить нечто, что компилирует C, проходит большую часть тестов и собирает крупный проект. Второй — инженерный порог: артефакт становится участником взрослого соревнования, где уже смотрят не на сам факт существования, а на полноту, устойчивость, предсказуемость и качество результата. В случае Claude’s C Compiler был уверенно преодолён первый порог: Anthropic пишет о сборке Linux 6.9 на x86/ARM/RISC-V, о почти 99% прохождении «most compiler test suites including the GCC torture test suite», о сборке QEMU, FFmpeg, SQLite, Postgres и Redis. Но сам же автор проекта отдельно фиксирует, что это capability benchmark и что на уровне зрелости у системы остаются серьёзные ограничения. См.: https://www.anthropic.com/engineering/building-c-compiler
Самое показательное тут именно не «смог / не смог», а характер недостачи. Carlini прямо пишет, что сгенерированный код «not very efficient», причём даже при включённых оптимизациях он хуже, чем код GCC с отключёнными оптимизациями; кроме того, новые фичи и багфиксы часто ломали уже работавшую функциональность. А текущий README репозитория добавляет ещё более жёсткую деталь: все уровни -O0…-O3, а также -Os и -Oz, сейчас гоняют один и тот же optimization pipeline. То есть это не просто «оптимизатор слабый»; это означает, что сама дисциплина разграничения уровней оптимизации, trade-off’ов между скоростью компиляции, скоростью исполнения и размером кода фактически ещё не состоялась.
Поэтому ваша формулировка «не явился на соревнования» почти точна. Современный оптимизирующий компилятор — это не одна великая идея, а длинная история накопленных локальных побед: выбор представлений, регистровое распределение, instruction scheduling, учёт register pressure, shrink-wrapping, cost models, векторизация и множество таргет-специфических эвристик. В документации GCC это видно буквально по перечню самостоятельных семейств оптимизаций и их тонким включениям на разных уровнях -O; даже одна только область scheduling/register allocation уже разветвлена на несколько отдельных проходов и эвристик. На этом фоне «у нас есть SSA IR и 15 passes» — это начало разговора, а не его зрелая стадия. См.: https://github.com/anthropics/claudes-c-compiler
Отсюда, по-моему, следует более общий тезис об ИИ. В этой области слишком часто аплодируют переходу от нуля к единице, тогда как в инженерии уважение обычно начинается где-то на переходе от 0.7 к 0.95. ИИ сегодня часто силён именно в зоне «собрать осмысленный черновой артефакт при мощном оракуле из тестов и известного toolchain’а». Но он заметно слабее там, где нужно годами выжимать проценты по геометрическому среднему, удерживать регрессии, строить корректные cost models и поддерживать длинную дисциплину улучшений без распада системы. История с CCC это очень хорошо показывает: система способна породить впечатляющий компиляторный организм, но пока не демонстрирует того типа накопительной инженерной зрелости, по которому в обычной технологии и решают, разговаривать с тобой «как со взрослым» или нет.
Если выразить это совсем коротко: сегодня ИИ уже умеет производить доказательства возможности; гораздо реже он производит артефакты, выдерживающие нормальные критерии технической взрослости.
Да. Здесь различие очень существенное.
Есть, грубо говоря, два порога. Первый — порог ненулевой способности: система вообще может породить нечто, что компилирует C, проходит большую часть тестов и собирает крупный проект. Второй — инженерный порог: артефакт становится участником взрослого соревнования, где уже смотрят не на сам факт существования, а на полноту, устойчивость, предсказуемость и качество результата. В случае Claude’s C Compiler был уверенно преодолён первый порог: Anthropic пишет о сборке Linux 6.9 на x86/ARM/RISC-V, о почти 99% прохождении «most compiler test suites including the GCC torture test suite», о сборке QEMU, FFmpeg, SQLite, Postgres и Redis. Но сам же автор проекта отдельно фиксирует, что это capability benchmark и что на уровне зрелости у системы остаются серьёзные ограничения. См.: https://www.anthropic.com/engineering/building-c-compiler
Самое показательное тут именно не «смог / не смог», а характер недостачи. Carlini прямо пишет, что сгенерированный код «not very efficient», причём даже при включённых оптимизациях он хуже, чем код GCC с отключёнными оптимизациями; кроме того, новые фичи и багфиксы часто ломали уже работавшую функциональность. А текущий README репозитория добавляет ещё более жёсткую деталь: все уровни -O0…-O3, а также -Os и -Oz, сейчас гоняют один и тот же optimization pipeline. То есть это не просто «оптимизатор слабый»; это означает, что сама дисциплина разграничения уровней оптимизации, trade-off’ов между скоростью компиляции, скоростью исполнения и размером кода фактически ещё не состоялась.
Поэтому ваша формулировка «не явился на соревнования» почти точна. Современный оптимизирующий компилятор — это не одна великая идея, а длинная история накопленных локальных побед: выбор представлений, регистровое распределение, instruction scheduling, учёт register pressure, shrink-wrapping, cost models, векторизация и множество таргет-специфических эвристик. В документации GCC это видно буквально по перечню самостоятельных семейств оптимизаций и их тонким включениям на разных уровнях -O; даже одна только область scheduling/register allocation уже разветвлена на несколько отдельных проходов и эвристик. На этом фоне «у нас есть SSA IR и 15 passes» — это начало разговора, а не его зрелая стадия. См.: https://github.com/anthropics/claudes-c-compiler
Отсюда, по-моему, следует более общий тезис об ИИ. В этой области слишком часто аплодируют переходу от нуля к единице, тогда как в инженерии уважение обычно начинается где-то на переходе от 0.7 к 0.95. ИИ сегодня часто силён именно в зоне «собрать осмысленный черновой артефакт при мощном оракуле из тестов и известного toolchain’а». Но он заметно слабее там, где нужно годами выжимать проценты по геометрическому среднему, удерживать регрессии, строить корректные cost models и поддерживать длинную дисциплину улучшений без распада системы. История с CCC это очень хорошо показывает: система способна породить впечатляющий компиляторный организм, но пока не демонстрирует того типа накопительной инженерной зрелости, по которому в обычной технологии и решают, разговаривать с тобой «как со взрослым» или нет.
Если выразить это совсем коротко: сегодня ИИ уже умеет производить доказательства возможности; гораздо реже он производит артефакты, выдерживающие нормальные критерии технической взрослости.
Anthropic
Building a C compiler with a team of parallel Claudes
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
Forwarded from Радиокружок "Горелая канифоль" им. КТ315
Айтишник написал в резюме рецепт пельменей и получил приглашение на собеседование
Парень оптимизировал его под алгоритмы нейросетей, и его зачёл ИИ-эйчар.
Рекрутер начал собеседование с обсуждения опыта и только потом заметил, что в резюме описано, как кандидат 20 лет варил пельмени, солил их и доставал из кастрюли.
Берем на заметку, как правильно составлять резюме!
Канифолька
Please open Telegram to view this post
VIEW IN TELEGRAM
Тем временем рекрутеры
> Дмитрий, добрый день!
> (...)
> Cергей, cкажите, пожалуйста, интересно ли вам обсудить данное предложение?
> Дмитрий, добрый день!
> (...)
> Cергей, cкажите, пожалуйста, интересно ли вам обсудить данное предложение?
Forwarded from Голландский Rust-ист
Продукт, который поможет не терять продуктивность
https://github.com/ovr/vibecoder-connector (поддержите лайками! ваша поддержка бесценна)
Проблема: разработчик запускает Claude Code, переключается на другую вкладку/телефон/кофе, и пропускает момент, когда агент закончил или ждёт ввод. Внимание фрагментировано. Контекст теряется. Продуктивность падает.
Существующие решения — звуковые уведомления — не работают в наушниках с ANC, в шумном офисе, или когда ты уже в пятом созвоне за день. А что если фидбэк будет тактильным? Не на экране, не в наушниках — а физически, через тело.
Я задался этим вопросом, и представляю vibecoder-connector — плагин, который подключается к любому Buttplug-совместимому устройству через Intiface Central и превращает события агента в haptic-паттерны.
Лёгкий тап = сессия началась. Мягкая волна = Claude ждёт ввод. Burst = таска готова. Ты чувствуешь процесс, не отвлекаясь от контекста.
Разработано совместно с исследователями ИИ в Somatic Computing Lab компании Vibetropic, подразделении VibeHoldings Inc.¹ (осн. 2026 — год, когда мы достигли AGI — вы и так это знаете).
Да, Buttplug. Нет, это не шутка — это открытый протокол для управления вибромоторами, 200+ устройств. Мы просто нашли ему продуктивное применение. Node.js, zero config, кастомные паттерны через JSON.
Подход основан на whitepaper «Somatic Feedback Loops in Human-Agent Collaboration» (Vibetropic Research, 2026), в котором показано, что тактильные сигналы сокращают время реакции разработчика на события агента на 42% по сравнению с визуальными уведомлениями и на 67% по сравнению со звуковыми в условиях когнитивной перегрузки.
Полный текст whitepaper пока на рецензии в Nature, но мы верим в open source, поэтому уже на GitHub.
https://github.com/ovr/vibecoder-connector (поддержите лайками! ваша поддержка бесценна)
Проблема: разработчик запускает Claude Code, переключается на другую вкладку/телефон/кофе, и пропускает момент, когда агент закончил или ждёт ввод. Внимание фрагментировано. Контекст теряется. Продуктивность падает.
Существующие решения — звуковые уведомления — не работают в наушниках с ANC, в шумном офисе, или когда ты уже в пятом созвоне за день. А что если фидбэк будет тактильным? Не на экране, не в наушниках — а физически, через тело.
Я задался этим вопросом, и представляю vibecoder-connector — плагин, который подключается к любому Buttplug-совместимому устройству через Intiface Central и превращает события агента в haptic-паттерны.
Лёгкий тап = сессия началась. Мягкая волна = Claude ждёт ввод. Burst = таска готова. Ты чувствуешь процесс, не отвлекаясь от контекста.
Разработано совместно с исследователями ИИ в Somatic Computing Lab компании Vibetropic, подразделении VibeHoldings Inc.¹ (осн. 2026 — год, когда мы достигли AGI — вы и так это знаете).
Да, Buttplug. Нет, это не шутка — это открытый протокол для управления вибромоторами, 200+ устройств. Мы просто нашли ему продуктивное применение. Node.js, zero config, кастомные паттерны через JSON.
Подход основан на whitepaper «Somatic Feedback Loops in Human-Agent Collaboration» (Vibetropic Research, 2026), в котором показано, что тактильные сигналы сокращают время реакции разработчика на события агента на 42% по сравнению с визуальными уведомлениями и на 67% по сравнению со звуковыми в условиях когнитивной перегрузки.
Полный текст whitepaper пока на рецензии в Nature, но мы верим в open source, поэтому уже на GitHub.
GitHub
GitHub - ovr/vibecoder-connector: Bridges the gap between your IDE and your body
Bridges the gap between your IDE and your body. Contribute to ovr/vibecoder-connector development by creating an account on GitHub.
Гораздо более интересный текст про ИИ-агенты, компилятор (JS -> WASM) и на этот раз формальную верификацию.
> "You are avoiding the hard cases. Stop. You have proved 40+ easy cases where closure conversion is identity. The ACTUAL verification is in the cases you keep marking as sorry: captured variable, function call, function definition. YOU MUST ATTEMPT THESE NOW. Not later. Not after 'one more easy case.' NOW."
https://www.basis.ai/blog/verified-compiler/
> "You are avoiding the hard cases. Stop. You have proved 40+ easy cases where closure conversion is identity. The ACTUAL verification is in the cases you keep marking as sorry: captured variable, function call, function definition. YOU MUST ATTEMPT THESE NOW. Not later. Not after 'one more easy case.' NOW."
https://www.basis.ai/blog/verified-compiler/
Basis
Building an Unverified Compiler with Agents
We tasked four agents to build a verified compiler. They produced a compiler, but failed to prove it correct.
Правда, 2025 год.
> Here’s what happens when you actually test state-of-the-art models on verification tasks:
RTL code generation: Claude 3.7 Sonnet gets 34% right. Not amazing, but workable.
Testbench stimulus generation: Drops to 25%. Okay, getting concerning.
Testbench checker generation: 6%. Yes, you read that right. Six percent.
Assertion generation: 19%. Better than checkers, still terrible.
> We finally have data. Instead of just complaining that “AI verification sucks” (which we all knew), we now have specific, quantified ways it sucks. The NVIDIA team identified exact failure patterns:
Timing violations
Coverage gaps
Assertion misplacement
Synchronization issues
This isn’t just academic hand-wraving—it’s a roadmap. We know what’s broken, which means we (or the AI companies) can actually fix it.
https://benharoosh.co.il/why-ai-struggles-with-hardware-testing/
> Here’s what happens when you actually test state-of-the-art models on verification tasks:
RTL code generation: Claude 3.7 Sonnet gets 34% right. Not amazing, but workable.
Testbench stimulus generation: Drops to 25%. Okay, getting concerning.
Testbench checker generation: 6%. Yes, you read that right. Six percent.
Assertion generation: 19%. Better than checkers, still terrible.
> We finally have data. Instead of just complaining that “AI verification sucks” (which we all knew), we now have specific, quantified ways it sucks. The NVIDIA team identified exact failure patterns:
Timing violations
Coverage gaps
Assertion misplacement
Synchronization issues
This isn’t just academic hand-wraving—it’s a roadmap. We know what’s broken, which means we (or the AI companies) can actually fix it.
https://benharoosh.co.il/why-ai-struggles-with-hardware-testing/
rust-coreutils в Ubuntu: blazingly fast, blazingly safe, 40+ CVEs
https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
Ubuntu Community Hub
An update on rust-coreutils
This is a follow-up to Jon’s original post on Carefully (but purposefully) oxidising Ubuntu and Julian’s migration spec for 25.10. We promised transparency throughout this process, and this post is written in that spirit. What happened after the announcement…
> An autonomous research loop pointed at a SystemVerilog RV32IM CPU. Each round the agent proposes a microarchitectural hypothesis, implements it in an isolated git worktree, then runs it through riscv-formal + Verilator cosim + 3-seed FPGA place-and-route. Only hypotheses that beat the current champion on CoreMark/MHz get merged.
https://github.com/FeSens/auto-arch-tournament
https://github.com/FeSens/auto-arch-tournament/blob/main/docs/auto-arch-tournament-blog-post.md
+30% к CoreMark/MHz
Правда, исходный CoreMark/MHz - 2.226. То есть, исходная планка не то чтобы очень высокая, ядрышко такое себе. Но всё равно +30% - это довольно весомый результат. Улучшения, "победившие" в турнире - в основном во фронт-энде ядра.
P.S. кстати, сейчас кажется очевидным, почему так: ядро - простой in-order конвейер. Чтобы получить какие-то заметные плюшки от улучшений в бэкенде, надо менять не только ядро, но и модель ядра для компилятора.
https://github.com/FeSens/auto-arch-tournament
https://github.com/FeSens/auto-arch-tournament/blob/main/docs/auto-arch-tournament-blog-post.md
+30% к CoreMark/MHz
Правда, исходный CoreMark/MHz - 2.226. То есть, исходная планка не то чтобы очень высокая, ядрышко такое себе. Но всё равно +30% - это довольно весомый результат. Улучшения, "победившие" в турнире - в основном во фронт-энде ядра.
P.S. кстати, сейчас кажется очевидным, почему так: ядро - простой in-order конвейер. Чтобы получить какие-то заметные плюшки от улучшений в бэкенде, надо менять не только ядро, но и модель ядра для компилятора.
GitHub
GitHub - FeSens/auto-arch-tournament
Contribute to FeSens/auto-arch-tournament development by creating an account on GitHub.
https://nickkossolapov.github.io/fame-boy/building-a-game-boy-emulator-in-fsharp/
> There were more times where I moved to structs (which live on the stack) or went with other not-as-F#-friendly approaches. The PPU was the point where optimization became necessary, and I had to abandon idiomatic F# to an extent.
> I slowly improved performance by spending time regularly looking at the profiler, eventually getting it up to about 120 FPS. But then I found the biggest improvement in FPS. The fix? Turning off the debug build, taking the emulator to a lightning-fast 1000 FPS. It took me embarrassingly long to realise that debug mode is that much worse than release mode. I continued to regularly monitor performance and tweak things even up until the end.
> There were more times where I moved to structs (which live on the stack) or went with other not-as-F#-friendly approaches. The PPU was the point where optimization became necessary, and I had to abandon idiomatic F# to an extent.
> I slowly improved performance by spending time regularly looking at the profiler, eventually getting it up to about 120 FPS. But then I found the biggest improvement in FPS. The fix? Turning off the debug build, taking the emulator to a lightning-fast 1000 FPS. It took me embarrassingly long to realise that debug mode is that much worse than release mode. I continued to regularly monitor performance and tweak things even up until the end.
nickkossolapov.github.io
I built a Game Boy emulator in F#
Hundreds of hours, many late nights, and a working Game Boy emulator in F# with sound, running on desktop and web.
Forwarded from Ряды Фурье
Знаете, что будет, если нейробиологам дать процессор, чтобы они изучали его мышление?
В 2017 году попробовали и знатно облажались. Вот @pavgavr принёс работу.
Смысл в чём: если заморозить мозг, потом послойно его отсканировать и получить карту соединения всех нейронов, а потом запустить это в виртуальную среду и посмотреть, что оно делает — мы получим работающую копию, но всё ещё не будем понимать, КАК она работает. Первую бессмертную муху на этой планете мы так уже запустили, если что.
В 2017 году нейробиологи говорили, что мы нифига не понимаем, потому что данных слишком мало.
Пришли физики (вычислительные нейробиологи), поржали с этого и предложили попробовать на процессоре MOS 6502. Ну, чисто убедиться, что действительно всё поймём.
Он примерно как примитивный червяк — мозг маленький, смешной, хорошо изученный, на порядки проще мозга мушки. Процессор засветился в Apple I, паре стиральных машин, Commodore 64, Денди и Терминаторе (T-800 показывает его ассемблер), плюс на нём работает робот Бендер.
Всего 3510 транзисторов.
Транзисторы собираются в логические вентили, те — в сумматоры, а из них делаются регистры и арифметико-логическое устройство. В цикле считывает команду из памяти и выполняет. Это и есть понимание сути системы.
Приятно, что оригинальных чертежей 1975 года не сохранилось. Поэтому ещё в 2010 году взяли несколько 6502 и стали реверсить. Сварили в серной кислоте при 93 градусах. Полученный каркас сняли панорамой в 72 снимка (итого 342 мегапикселя склейки). Распознали всё OCR для плат, поправили руками ошибки, достроили спрятанные. Получился netlist.
Запустили симулятор этого процессора и заставили его проявлять поведение — играть в старые игры Donkey Kong, Space Invaders и Pitfall. За секунду симуляции писали 1,5 ГБ данных о напряжении на каждом контакте и состоянии каждого транзистора.
Потом стали применять нейробиологические подходы. Сначала — стандартный алгоритм поиска шаблонов показал, что в процессоре есть разные типы транзисторов. Ну, типа, тут вот зрительные транзисторы, а тут вот двигательные. На деле, конечно, все транзисторы в процессоре одинаковые. Примерно как в архитектуре нейросетей осьминога.
Дальше хирургия. Вырезаете кусок и смотрите, что отваливается. Поломка примерно каждого второго приводила к тому, что процессор умирал (не мог запустить игры). Но нашлись транзисторы, поломка которых ломала только Конга, но не Инвандеров. Так биологи открыли транзисторы Донки Конга!
Если вы выломаете деталь из телевизора и перестанет работать канал со спортом, это не значит, что эта деталь — модуль спорта. Метод не сильно помог понять логику работы чипа.
Нейробиологи часто вставляют электрод в один нейрон зрительной коры и показывают животному картинки, ища связь между вспышками света и активностью клетки. Ученые выбрали один транзистор и следили, как часто он выдает активность в зависимости от яркости пикселей на экране во время игры. Построили графики и нашли транзисторы, чья работа идеально совпадала с изменением яркости экрана. Точь-в-точь как реакция нейронов на свет! Но те транзисторы за экран вообще не отвечали, а просто работали синхронно с каким-то внутренним процессом игры.
Изучение одной детали в отрыве от системы дает красивую, но бессмысленную картинку.
Смоделировали ЭЭГ и МРТ — усреднили активность транзисторов по разным зонам чипа. И внезапно они увидели графики, поразительно похожие на волны живого мозга — с определенными ритмами и частотами. Применили алгоритм причинности Грэнджера, чтобы по этим волнам понять, какая зона чипа командует другой зоной. Часть прогнозов попала в инженерную схему, часть мимо.
Дальше взяли всё облако данных и сжали до главных сигналов. Метод выявил 6 главных состояний процессора. Одно из них идеально совпало с тактовым генератором, а другое — с режимом чтения/записи памяти. Но понимания логики в конце не возникло.
Инженеры продолжили ржать, мол, вот так же вы пытаетесь понять живые организмы.
--
Вступайте в ряды Фурье! | Самые полезные посты
Естественный отбор все ещё работает. Просто теперь он отбирает тех, кто читает инструкции.
В 2017 году попробовали и знатно облажались. Вот @pavgavr принёс работу.
Смысл в чём: если заморозить мозг, потом послойно его отсканировать и получить карту соединения всех нейронов, а потом запустить это в виртуальную среду и посмотреть, что оно делает — мы получим работающую копию, но всё ещё не будем понимать, КАК она работает. Первую бессмертную муху на этой планете мы так уже запустили, если что.
В 2017 году нейробиологи говорили, что мы нифига не понимаем, потому что данных слишком мало.
Пришли физики (вычислительные нейробиологи), поржали с этого и предложили попробовать на процессоре MOS 6502. Ну, чисто убедиться, что действительно всё поймём.
Он примерно как примитивный червяк — мозг маленький, смешной, хорошо изученный, на порядки проще мозга мушки. Процессор засветился в Apple I, паре стиральных машин, Commodore 64, Денди и Терминаторе (T-800 показывает его ассемблер), плюс на нём работает робот Бендер.
Всего 3510 транзисторов.
Транзисторы собираются в логические вентили, те — в сумматоры, а из них делаются регистры и арифметико-логическое устройство. В цикле считывает команду из памяти и выполняет. Это и есть понимание сути системы.
Приятно, что оригинальных чертежей 1975 года не сохранилось. Поэтому ещё в 2010 году взяли несколько 6502 и стали реверсить. Сварили в серной кислоте при 93 градусах. Полученный каркас сняли панорамой в 72 снимка (итого 342 мегапикселя склейки). Распознали всё OCR для плат, поправили руками ошибки, достроили спрятанные. Получился netlist.
Запустили симулятор этого процессора и заставили его проявлять поведение — играть в старые игры Donkey Kong, Space Invaders и Pitfall. За секунду симуляции писали 1,5 ГБ данных о напряжении на каждом контакте и состоянии каждого транзистора.
Потом стали применять нейробиологические подходы. Сначала — стандартный алгоритм поиска шаблонов показал, что в процессоре есть разные типы транзисторов. Ну, типа, тут вот зрительные транзисторы, а тут вот двигательные. На деле, конечно, все транзисторы в процессоре одинаковые. Примерно как в архитектуре нейросетей осьминога.
Дальше хирургия. Вырезаете кусок и смотрите, что отваливается. Поломка примерно каждого второго приводила к тому, что процессор умирал (не мог запустить игры). Но нашлись транзисторы, поломка которых ломала только Конга, но не Инвандеров. Так биологи открыли транзисторы Донки Конга!
Если вы выломаете деталь из телевизора и перестанет работать канал со спортом, это не значит, что эта деталь — модуль спорта. Метод не сильно помог понять логику работы чипа.
Нейробиологи часто вставляют электрод в один нейрон зрительной коры и показывают животному картинки, ища связь между вспышками света и активностью клетки. Ученые выбрали один транзистор и следили, как часто он выдает активность в зависимости от яркости пикселей на экране во время игры. Построили графики и нашли транзисторы, чья работа идеально совпадала с изменением яркости экрана. Точь-в-точь как реакция нейронов на свет! Но те транзисторы за экран вообще не отвечали, а просто работали синхронно с каким-то внутренним процессом игры.
Изучение одной детали в отрыве от системы дает красивую, но бессмысленную картинку.
Смоделировали ЭЭГ и МРТ — усреднили активность транзисторов по разным зонам чипа. И внезапно они увидели графики, поразительно похожие на волны живого мозга — с определенными ритмами и частотами. Применили алгоритм причинности Грэнджера, чтобы по этим волнам понять, какая зона чипа командует другой зоной. Часть прогнозов попала в инженерную схему, часть мимо.
Дальше взяли всё облако данных и сжали до главных сигналов. Метод выявил 6 главных состояний процессора. Одно из них идеально совпало с тактовым генератором, а другое — с режимом чтения/записи памяти. Но понимания логики в конце не возникло.
Инженеры продолжили ржать, мол, вот так же вы пытаетесь понять живые организмы.
--
Вступайте в ряды Фурье! | Самые полезные посты
В человеке всё должно быть прекрасно: и лицо, и душа, и мысли, и сакура на заднем плане
Сделал над собой усилие и переселился в касту архитекторов / менеджеров. Долго, конечно, я этому сопротивлялся, практически всю свою предыдущую профессиональную карьеру. В какой-то момент был тимлидом, но на самом деле скорее "играющим тренером". Всякие менеджерские работы давались мне с некоторым внутренним напряжением - ну как же, я трачу время, которое я мог бы пустить на то, чтобы нафигачить ещё что-нибудь полезное.
Но в итоге всё-таки сдался и осознал себя как "больше не кодер". Сегодня "официально" объявил об этом команде. Король умер, да здравствует король.
Но в итоге всё-таки сдался и осознал себя как "больше не кодер". Сегодня "официально" объявил об этом команде. Король умер, да здравствует король.
Почему я перестал писать код? Тут важен "исторический контекст". Работаешь ты такой свою работу, и в какой-то момент окончательно понимаешь: проблемы, которые тебе надо решить, чтобы прийти к успеху - не технические. Ты ищешь человека, который тебе поможет разобраться с организационными больками, и понимаешь: эти больки возникают из-за того, что такого человека просто нет. Ты становишься таким человеком и понимаешь: работы этой очень много (никто ведь до сих пор этим не занимался), и она плохо сочетается с глубоким погружением в технические задачи. Ты страдаешь, потому что не получается достигнуть результата сразу по двум веткам. Команда страдает, потому что всё ещё полагается на тебя как инженера, а у тебя календарь забит и код не поревьюить. Короче, попытка усидеть на двух стульях приводит к взаимному страданию. Проще и полезнее сосредоточиться на чем-то одном.
Рассказывал много раз своим падаванам о том, почему в проде не стоит писать на "академических" языках. Сам при этом решил, чтобы не терять тонус, поиграться с CHICKEN Scheme. Не, ну а что, я же шерстяной волчара.
Ну так вот, дефолтные пакеты под убунту развалены. Попытка установить какой-нибудь egg приводит к ошибкам компиляции где-нибудь в srfi-14. Всё как мы любим: поддержка экосистемы - это не интересно.
Ну так вот, дефолтные пакеты под убунту развалены. Попытка установить какой-нибудь egg приводит к ошибкам компиляции где-нибудь в srfi-14. Всё как мы любим: поддержка экосистемы - это не интересно.