Вообще, для подобных Gareware Programmable ASIC вижу, что необходимо не только вылить в кремнии - но построить экосистему, придумать для каких целей использовать
Например для локальных LLM. В соседних постах пытаются запускать DeepSeek на локальных компах, и работает это все сейчас довольно медленно.
Я считаю, то что получилось воспроизвести правила классического Го в непрерывности - это очень красиво!
При этом правила слишком неформальные - не понятно как в это нормально играть. В интерфейсе нет никакого подсчета очков, а также Ко не работает.
Вообще мы думали - может нам это в Gymnasium(OpenAI Gym) запихнуть (сделать среду с наградой) и постараться обучить RL агента играть в совершенно, по сути, новую игру.
Еще можно придумать, что вместо 64 может быть любое натуральное число, вот здесь можно поиграться (и посмотреть исходники): http://kvanttt.github.io/BaseNcoding/
Интересно, почему транскрипция лучше получается для фортепиано, а для других инструментов всё ещё в разработке
Я могу только предположить, что транскрипция звуков от инструментов с ладами (дискретными нотами) должна быть проще и точнее транскрипции безладовых (например, скрипка). Несмотря на то, что на гитаре как правило есть лады, вариативность извлекаемых звуков у нее больше, что усложняет. А еще может просто не дошли до реализации других инструментов, начали со стандартного фортепиано.
Это было возможно в не очень хорошем качестве и до массового появления нейросетей, а уж после я думаю качество может вырасти практически до человеческого.
Изменения ритма в одном такте (см Таривердиева, например) - откуда оно поймет ?! Плюс живой музыкант не играет как метроном или музыкальная табакерка - на записанные инструкции композитора накладывается личная интерпретация. Как они собираются осеивать одно от другого ?
Например на основе обучения на стилях разных композиторов и исполнителей?
А выделить атаки нот - тут ИИ не надо. Товарищ Фурье давно всем объяснил как выделять спектры...
Может и не надо, только сигнал и игра далеко не всегда идеальные.
По C еще все более понятно, потому что это легаси и на нем легко выстрелить себе в ногу. Менее очевидно в чем киллер фича Hare по сравнению с новыми языками, такими как zig, v, nim, Rust и возможно другими. Хорошо бы увидеть детальное сравнение.
Уже не один раз предлагались подобные подходы, но никогда не взлетало.
Существует много вариантов: UTF-8 или UTF-16; с BOM или без него; CR, LF или CRLF; little-endian или big-endian — это лишь самые популярные варианты. К сожалению, мир не смог договориться об одном стандарте, поэтому то и дело приходится сталкиваться с проблемами: испорченные диффы, ошибки в тулзах, проблемы с копированием, нечитаемый текст на фронте.
Настолько давно не видел проблем именно из-за кодировки файла, что даже не помню точное название используемой сейчас. Всё работает по всех текстовых редакторах.
Но если мы говорим о форматировании, для меня это выглядит странно: почему мы должны заботиться о пустых строках, табуляции или пробелах, ограничениях по длине строк и других несущественных деталях?
Существенные - мы код пишем, чтобы его можно было позже комфортно читать людям, а не только машинам.
Еще один уровень абстракции между кодом и хранилищем. Зачем нам имена файлов и ограничения с ними связанные?
Нет никаких ограничений, имена файлов подчеркивают их контент.
А еще мы работаем на разных файловых системах, и они предоставляют нам разные функции. Чувствительность к регистру или нет? Жесткие и символические ссылки. Права доступа. Атрибуты. Все эти особенности не имеют отношения к нашему коду, по крайней мере, вы обычно не можете прочитать о них в спецификации вашего языка.
Такие проблемы возникают иногда, но не настолько часто, чтобы ради них менять всё.
Я упомянул проблемы, с которыми сталкивался лично. Каждый раз мне приходилось тратить время на погружение в особенности файловых систем и поиск обходного пути. И далеко не всегда результат удовлетворял меня, чаще решение представляло собой костыль.
Поэтому собрались разработать свой стандарт, который конечно же будет поддерживаться везде.
Однако это еще не все, парсинг происходит много раз и после загрузки: при изменении кода, при переключении веток, при компиляции.
Теперь самое главное - почему вы решили что парсинг занимает основное время компиляции? Есть еще семантический анализ, генерация кода, оптимизация, которые работают намного медленней парсинга. Как правило, хороший парсер работает молниеносно и совсем не является бутылочным горлышком. Логичней тогда уж оптимизировать инкрементальную компиляцию или систему отображения кода, с которым в данный момент разработчик работает непосредственно.
Каким бы эффективным не был парсер, но он загружает ваш процессор и память. Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.
То же самое может случиться с вашим AST представлением. И только одному парсеру на самом деле тяжело будет заполнить всю память.
Все становится намного хуже, когда вы работаете в команде. Мы используем специальное программное обеспечение для слияния изменений, но оно работает ужасно:
Когда вы перемещаете класс в другой файл — это новый класс.
Когда вы перемещаете функцию на несколько строк вверх или вниз — это новая функция.
Когда вы меняете имя любого идентификатора — у вас появляются изменения во всех файлах, которые его используют.
Это не проблема систем контроля версий, которые работают с текстами. Теоретически можно придумать умный дифф, только почему-то мало кому это нужно. В AST-подходе не будет никаких сущностей, которые можно именовать?
Когда два человека вносят изменения в один файл — возникают конфликты.
А это относится к представлению кода? В AST-подходе конфликты будут сами решаться чудесным образом?
Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Совсем не очевидно как и то, какой подход может быть лучше.
Мы сможем сэкономить на размере данных если использовать enum для ключевых слов.
А какая экономия получится? Вот код в очень больших проектах занимает до нескольких сотен мегабайт, в малых проектах это мегабайты. Реально имеет смысл экономить, особенно учитывая что всякие ресурсы могут весить на порядки больше?
Чтение из локальной БД будет сравнимо по скорости с чтением с диска.
У хороших парсеров для языков без сложных конструкций (таких как C++) скорость парсинга не сильно медленней чтения файлов с диска.
Форматирование AST должно быть быстрее парсинга.
Должно быть? Настолько быстрей, вы делали замеры? Стоит ли овчинка выделки?
Я представляю это как нечто вроде режима исправлений в Google Docs: некоторые части заменяются, другие перемещаются куда-то или удаляются.
А можно будет откатиться на одну из предыдущих версий при необходимости? Посмотреть изменения с нескольких "коммитов"? И другие вопросы актуальные для версионирования.
Далее, код, который в работе, не обязательно будет синтаксически верный, там может быть набросок с ошибками, но, если хранить код нужно в виде абстрактного синтаксического дерева, то сохранить код не получится до того, как он не станет синтаксически корректным, так получается?
Вообще говоря хорошие парсеры парсят любую последовательность символов, включая совсем ошибочный код (будет просто много узлов с пометкой error). Так что теоретически проблема решаема, но зачем?
Потому что если Вы пишете бред и кто-то называет это бредом - это не хамство, а чистая правда
Я не считаю это правдой и порядочностью. Ловко вы перешли, на то, что если кто-то (вы) называет это бредом, то это чистая правда. Нет, это не так работает - помимо вашего мнения есть и другие.
И я заминусил карму далеко не только за эту фразу. Вот я считаю, что многие ваши сообщения непоследовательные и тоже бредовые.
Вот именно. И поэтому порядочные люди на Хабре карму никому не снижают. :)
Есть функционал хабра, который такое позволяет. Если вас он не устраивает, никто не заставляет пользоваться этим сайтом. Если приняли правила игры, то не обижайтесь. И еще порядочные люди не переходят на личности и не хамят.
Если у вас бригадный подряд, и вы бригадой организованно гнобите всех, кто не нравится, никакая статья не спасёт. Я только не поняла, на что конкретно Ваша бригада заточена.
Это ваши фантазии про какие-то бригады. А вообще хорошие статьи спасут - проверено на себе, вам тоже советую попробовать.
Это был риторический вопрос. Ответа на него я не жду. И отвечать Вам не буду, т.к. не люблю зря убивать время. Успехов :)
Уже столько времени и сообщений потратили на этот и другие треды, видимо все же любите.
Люблю находить и внедрять подобные оптимизации. К сожалению, это далеко не всегда возможно и приходится довольствоваться ускорением хотя бы на пару процентов (например, в компиляторе Kotlin).
Если инференс многопоточный, то скорей всего ни temperature, ни seed не помогут (из-за того, что все это это запускается на ОС не реального времени, а диспетчеризация потоков недетерминированная). Даже если и получится, то нейросетку нельзя будет обновлять, т.к. любое переобучение может сломать детерминированность.
Было бы странно, если компания запретила пользоваться своими продуктами своим же разработчикам, большинство из которых все еще русские.
Например для локальных LLM. В соседних постах пытаются запускать DeepSeek на локальных компах, и работает это все сейчас довольно медленно.
При этом правила слишком неформальные - не понятно как в это нормально играть. В интерфейсе нет никакого подсчета очков, а также Ко не работает.
Можно еще рассмотреть https://github.com/google-deepmind/open_spiel . Там, кстати, классическое Го тоже реализовано. Это вроде даже больше специализировано для подобных игр.
Нейросети прекрасно справляются с Го и без AGI.
Еще можно придумать, что вместо 64 может быть любое натуральное число, вот здесь можно поиграться (и посмотреть исходники): http://kvanttt.github.io/BaseNcoding/
Я могу только предположить, что транскрипция звуков от инструментов с ладами (дискретными нотами) должна быть проще и точнее транскрипции безладовых (например, скрипка). Несмотря на то, что на гитаре как правило есть лады, вариативность извлекаемых звуков у нее больше, что усложняет. А еще может просто не дошли до реализации других инструментов, начали со стандартного фортепиано.
Подобные алгоритмы распознавания известны с давних времен. Но ИИ может значительно улучшить качество за счет знаний, полученных в результате обучения.
Это было возможно в не очень хорошем качестве и до массового появления нейросетей, а уж после я думаю качество может вырасти практически до человеческого.
Например на основе обучения на стилях разных композиторов и исполнителей?
Может и не надо, только сигнал и игра далеко не всегда идеальные.
Интересно, когда-нибудь TPU можно будет купить простым смертным за доступную цену?
По C еще все более понятно, потому что это легаси и на нем легко выстрелить себе в ногу. Менее очевидно в чем киллер фича Hare по сравнению с новыми языками, такими как zig, v, nim, Rust и возможно другими. Хорошо бы увидеть детальное сравнение.
Есть еще zig, v, nim
Однако стоит не забывать, что при частоте 3 ГГц свет проходит около 10 см. На таких частотах все будет упираться в скорость обмена данных с памятью.
Уже не один раз предлагались подобные подходы, но никогда не взлетало.
Настолько давно не видел проблем именно из-за кодировки файла, что даже не помню точное название используемой сейчас. Всё работает по всех текстовых редакторах.
Существенные - мы код пишем, чтобы его можно было позже комфортно читать людям, а не только машинам.
Нет никаких ограничений, имена файлов подчеркивают их контент.
Такие проблемы возникают иногда, но не настолько часто, чтобы ради них менять всё.
Поэтому собрались разработать свой стандарт, который конечно же будет поддерживаться везде.
Теперь самое главное - почему вы решили что парсинг занимает основное время компиляции? Есть еще семантический анализ, генерация кода, оптимизация, которые работают намного медленней парсинга. Как правило, хороший парсер работает молниеносно и совсем не является бутылочным горлышком. Логичней тогда уж оптимизировать инкрементальную компиляцию или систему отображения кода, с которым в данный момент разработчик работает непосредственно.
То же самое может случиться с вашим AST представлением. И только одному парсеру на самом деле тяжело будет заполнить всю память.
Это не проблема систем контроля версий, которые работают с текстами. Теоретически можно придумать умный дифф, только почему-то мало кому это нужно. В AST-подходе не будет никаких сущностей, которые можно именовать?
А это относится к представлению кода? В AST-подходе конфликты будут сами решаться чудесным образом?
Совсем не очевидно как и то, какой подход может быть лучше.
А какая экономия получится? Вот код в очень больших проектах занимает до нескольких сотен мегабайт, в малых проектах это мегабайты. Реально имеет смысл экономить, особенно учитывая что всякие ресурсы могут весить на порядки больше?
У хороших парсеров для языков без сложных конструкций (таких как C++) скорость парсинга не сильно медленней чтения файлов с диска.
Должно быть? Настолько быстрей, вы делали замеры? Стоит ли овчинка выделки?
А можно будет откатиться на одну из предыдущих версий при необходимости? Посмотреть изменения с нескольких "коммитов"? И другие вопросы актуальные для версионирования.
Пока не верится.
И рассогласованность со всем остальным.
Вообще говоря хорошие парсеры парсят любую последовательность символов, включая совсем ошибочный код (будет просто много узлов с пометкой error). Так что теоретически проблема решаема, но зачем?
DeepMind уже занимаются проблемой адаптации LLM для подобных игр и получается неплохо: https://storage.googleapis.com/deepmind-media/papers/SchultzAdamek24Mastering/SchultzAdamek24Mastering.pdf
Не поможет: тут проводили такой эксперимент, правда с игрой Го: https://habr.com/en/articles/884588/
Я не считаю это правдой и порядочностью. Ловко вы перешли, на то, что если кто-то (вы) называет это бредом, то это чистая правда. Нет, это не так работает - помимо вашего мнения есть и другие.
И я заминусил карму далеко не только за эту фразу. Вот я считаю, что многие ваши сообщения непоследовательные и тоже бредовые.
Есть функционал хабра, который такое позволяет. Если вас он не устраивает, никто не заставляет пользоваться этим сайтом. Если приняли правила игры, то не обижайтесь. И еще порядочные люди не переходят на личности и не хамят.
Это ваши фантазии про какие-то бригады. А вообще хорошие статьи спасут - проверено на себе, вам тоже советую попробовать.
Уже столько времени и сообщений потратили на этот и другие треды, видимо все же любите.
Люблю находить и внедрять подобные оптимизации. К сожалению, это далеко не всегда возможно и приходится довольствоваться ускорением хотя бы на пару процентов (например, в компиляторе Kotlin).
Повод не надуманный, выше объяснил почему.
Так теперь уже не анонимно - я признался, что это сделал я. Неанонимного способа изменения кармы на хабре не существует.
Ну это же не мои проблемы - вам надо было больше статей писать или хотя бы одну хорошую, чтобы была возможность ответить.
Звучит как "программа добровольно-принудительного выхода".
Если инференс многопоточный, то скорей всего ни temperature, ни seed не помогут (из-за того, что все это это запускается на ОС не реального времени, а диспетчеризация потоков недетерминированная). Даже если и получится, то нейросетку нельзя будет обновлять, т.к. любое переобучение может сломать детерминированность.