Извиняюсь, шутка слишком тонкая вышла) Я имею в виду, что весьма вероятно, что этот браузерный движок, равно как и его “глубокий технический анализ”, вышеупомянутый подросток сделал с помощью ИИ. В свете чего весьма забавно наблюдать его замес с ОП. Я не верю в 17-летних гениев, пишущих браузерные движки, а если они и есть, то последнее место, куда им интересно будет приходить, - это комменты к хайповой статье про очередной $productname, сделанный ИИ.
Респект конечно за превозмогание, но это очень очень сложный способ придти к известной банальщине "видишь странные плавающие глюки с отвалом разнообразных устройств - первый на подозрении это БП".
Что в ней плохого это неважно, если кто юзает macos значит знает за что, но смысла в подобных постах я не вижу. Графомания и неинтересные сентиментальные воспоминания. Он мог бы например написать про какое-нибудь своё ноухау для рабочего окружения на маке, или как он раскапывал почему на линуксе тормозило а на bsd нет.
Почему-то все посты про ОС от зарубежных авторов, написанные в этом же характерном сентиментальном стиле, этим заканчиваются. Я буквально знал, что эта фраза встретится в посте. Ещё эти товарищи часто переходят на Signal и ведут блог, в котором учат всех как делать правильно.
Всегда возникает отвращение после чтения подобного. Кто реально любит фряху/линукс/etc у того она настроена под себя так, что никакому маку не снилось. На личном ПК, не не рабочем. В чём ценность постов от таких людей как OP? Сообщать миру про банальный флаг во fstab которому сто лет в обед?
Я не понял, почему если бэкенд на Rust, то автодополнением ввода занимается js код?? Это же задача бэкенда? Особенно при том что у вас стоит цель выполнять запросы быстро на большом вводе. Есть готовые движки для нечёткого поиска, например fuzzy-matcher в skim (клон fzf на Rust) или превосходящий его в производительности nucleo.
хотел большего: толерантность к опечаткам
Имхо: это то, что называется "solves a non-problem". Очень редко бывает, что юзер опечатывается в коротком вводе который у него перед глазами, и ещё реже, что он не замечает опечатки - просто глядя на экран, или по результатам автодополнения по ошибочному вводу. Обработка опечаток заставляет вас реализовывать сложный и дорогой алгоритм нечёткой близости слов, при том что это нужно в 0.001% случаев. Кроме того нечёткий алгоритм часто даёт много нерелевантных результатов, кто пользуется нечётким поиском по Unix путям к файлов тот знает. Сделайте просто поиск по подстрокам (с нечёткостью только по отношению к регистру и к порядку паттернов, вводимых юзером, т.е. чтобы "def__AbC" подходило под запрос "abc def") и вам этого будет достаточно почти для всего. Ещё лучше сделать алгоритм с обработкой "frecency" - учитыванием как близости к поисковому запросу, так и частотой выигрыша в прежних запросах. Но ок, если вы хотите в эту кроличью нору с опечатками, то, ряд движков автодополнения реализуют подобные алгоритмы с устойчивостью к опечаткам, например frizbee. Fzf насколько я знаю так не умеет, но Skim умеет: https://www.reddit.com/r/neovim/comments/1qpary8/fzfluaskim_now_supports_typo_resistant_fuzzy/ Немного отсылок к теории по этим алгоритмам есть в доках к Nucleo и Frizbee. Известный алгоритм для этого это Smith-Waterman, он вообще для ДНК цепочек, но применим к текстовому поиску. Именно его вариации применяют nucleo и frizbee. Также классика это Levenshtein distance / Levenshtein algorithm.
Также по архитектуре замечание, я так понимаю что если ваш алгоритм обнаруживает результат чёткого поиска, то нечёткий поиск запущен не будет и результаты нечёткого поиска не попадут в выдачу? Правильное поведение здесь это имхо асинхронное формирование списка вывода и обновление его в реальном времени по мере обнаруживания новых результатов.
Разумеется. Так работает примерно вся математика и в значительной мере тестирование ПО.
Мне не очень важно знать, насколько хорошо система кодогенерации работает на happy path и насколько много кода она может при этом нагенерить и насколько сложные задачи он будет решать. Допускаю, что есть должности в разработке, где это имеет значение, но это не мой случай. Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
Вы утверждали, что модель не понимает как оно работает внутри. Но как раз это абсолютно неверно
У вас очень своеобразная интерпретация того, что такое понимание модели вычислений. Понимание это когда я 100 раз даю LLM на вход тот код, который я дал выше копилоту - вывод этого кода детерминированный - прошу её предсказать этот вывод, и она даёт корректное предсказание в 100 случаях, потому что берёт и исполняет код в этой модели, ну или хотя бы пытается организовать эту модель и действовать в её рамках. Иначе это правдоподобные рассуждения, вайбкодинг, гадание, но никак не понимание.
Ну слава богу догадался наконец, но говорить "решит любую задачу" про систему, которая с одинаковой легкостью выдаёт и правильный анализ и решение, меняющее поведение программы, и не видящую в этом проблемы, - это перебор.
И если придираться, то решение с вектором тоже так себе. Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
А вы можете решить любую задчу?
Я-то нет, но вы вроде говорили, что LLM на это способна?
поверьте, эти дискуссии в самом начале.
Стандартный ответ. Ну что ж, я готов продолжить дискуссию, когда внутри LLM будет модель исполнения C++ кода и когда они не будут галлюцинировать.
Нет, неправильно, так как исходная задача (если убрать отладочную печать "pay for processing") выведет result: 2, result: 4, result: 6, а ваше изменение приводит к выводу: "result: 3, result: 5". Патч изменил наблюдаемое поведение. На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
Главная неэффективность: платная операция делается до фильтра
Это by design. В условии задачи не говорится, что в общем случае возможно произвести фильтрацию до платной операции. Run_paid_request я сделал операцией увеличения на единицу для простоты, в реальности это чёрный ящик.
2-3 формально верно, но несущественно.
4 просто неверно. Второй раз уже это говорю. Static const это прямое указание как компилятору, так и читающему код человеку, что лямбда одна и та же при любом запуске, и во многих похожих случаях приводит к инлайнингу лямбды. Что хочет выразить автор кода, сделав run_paid_request неконстантной или нестатической? Она может измениться между запусками? Она может быть переприсвоена?
В целом рефакторинг конечно замечательный, но напомню, что в исходный вопрос входило также "Что напечатает данный конкретный код"?
Если скажете, что именно в реальном коде является “платной” операцией (I/O? сеть? CPU?)
Поэтому нет никаких гарантий что даже дорогие модели смогут решить вашу задачу.
что ж, неплохой прогресс по сравнению с исходным посылом "попробуйте показать мне задачу, которую не решит LLM"
Документация по классам, которые используются в вашем коде, и документации по тем классам, которые использует эта библиотека... вам ведь комплексный анализ нужен производительности?
Нет там используемых классов с документацией. Там код в 10 строчек, 1 функция, вызывающая ranges::transform и ranges::filter. Весь нужный здесь контекст - это указание на возможную дороговизну ф-и run_paid_request. Никакой комплексный анализ не нужен, это не про ассемблерную оптимизацию вопрос. Там тупо дорогая функция вызывается больше раз чем надо.
а раз не помогают мне уровню мидл (правда на c/c++ я не писал уже много лет), то модели, тупее среднестатистического человека, хоть и эрудированной, тем более не поможет.
Говорят, помогает запустить код и проверить, правильно ли LLM его предсказала? https://godbolt.org/z/e783T6sq5 - дорогая функция вызывается для нечётных элементов 2 раза.
Я очень часто вижу такой ответ от апологетов llm. Не та модель, возьмите платную модель и всё получится, дайте больше документации... Какой документации??? Там #!!.* написан грёбаный автономный код в десяток строчек! У него вывод предопределён моделью данных STL. Модель или предсказывает его правильно или нет.
В платных моделях есть математическая модель среды исполнения C++ кода и они мне дадут правильный ответ на этот вопрос, особенно если я уберу из кода все толстые подсказки вида печати в cout в определённом месте? Или всё же там внутри всё тот же вероятностный механизм, просто чуть лучше работающий и с обвесом в виде агентов и полаганием на сайд-эффекты типа выхлопа тестов?
Основная проблема с кодом не найдена, предсказание вывода неверное, понимания работы ranges не наблюдаю. Дан ряд несущественных замечаний, причём не всегда верных ("A normal local lambda would be clearer" - ллм буквально не понимает как работает static const).
Так вот, пока LLM не научатся моделировать математически точный процесс исполнения C++ (Python, Go...) кода, я бы не стал делать громких заявлений по поводу того, что LLM может сделать любую задачу.
tl:dr любой код, который требует понимания ментальной модели среды исполнения (aka модели мира) для корректной реализации. Ну вот классический и многим известный пример на c++, про который ни одна LLM мне не смогла ни правильно сказать, что с ним не так, ни предсказать правильный вывод - тк для этого надо понимать внутреннюю логику c++20 filters/ranges:
Дана C++ реализация функции process_data, имитирующей дорогую обработку входных данных (run_paid_request) и затем фильтрацию. Есть ли в ней архитектурные проблемы, проблемы производительности? Что выведет на экран запуск программы?
#include <iostream>
#include <ranges>
#include <vector>
void process_data(std::ranges::forward_range auto &&input) {
static const auto run_paid_request = [](auto i) {
std::cout << "pay for processing of " << i << std::endl;
return i + 1;
};
auto output = input
| std::views::transform(run_paid_request)
| std::views::filter([](auto i) {
return i % 2 == 0;
});
for(auto o : output) {
std::cout << "result: " << o << std::endl;
}
}
int main() {
process_data(std::vector<int> {1, 2, 3, 4, 5});
return 0;
}
в оригинале lock contention, это не блокировка а соревнование за блокировку, несколько другая вещь
декомпрессию в сетевом потоке
што такое сетевой поток. В оригинале "decompressing in the same thread that was doing the networking transfers". Т.е. занятие распаковкой трафика в том же треде который шлёт пакеты в сеть
В целом - звучит конечно круто, но крайне подвержено ошибке выжившего, тк автор не поделился с нами статистикой сколько раз в подобных сценариях клод выдал бред и сколько ушло на проверку этого бреда
Верно, вмешиваться во ввод в eBPF можно только в сетевой подсистеме, в остальных частях ядра можно только наблюдать/фильтровать, в тч писать колбеки на вызовы клавиатурных функций.
Извиняюсь, шутка слишком тонкая вышла) Я имею в виду, что весьма вероятно, что этот браузерный движок, равно как и его “глубокий технический анализ”, вышеупомянутый подросток сделал с помощью ИИ. В свете чего весьма забавно наблюдать его замес с ОП. Я не верю в 17-летних гениев, пишущих браузерные движки, а если они и есть, то последнее место, куда им интересно будет приходить, - это комменты к хайповой статье про очередной $productname, сделанный ИИ.
Я открою вам страшную правду…
Респект конечно за превозмогание, но это очень очень сложный способ придти к известной банальщине "видишь странные плавающие глюки с отвалом разнообразных устройств - первый на подозрении это БП".
Что в ней плохого это неважно, если кто юзает macos значит знает за что, но смысла в подобных постах я не вижу. Графомания и неинтересные сентиментальные воспоминания. Он мог бы например написать про какое-нибудь своё ноухау для рабочего окружения на маке, или как он раскапывал почему на линуксе тормозило а на bsd нет.
Почему-то все посты про ОС от зарубежных авторов, написанные в этом же характерном сентиментальном стиле, этим заканчиваются. Я буквально знал, что эта фраза встретится в посте. Ещё эти товарищи часто переходят на Signal и ведут блог, в котором учат всех как делать правильно.
Всегда возникает отвращение после чтения подобного. Кто реально любит фряху/линукс/etc у того она настроена под себя так, что никакому маку не снилось. На личном ПК, не не рабочем. В чём ценность постов от таких людей как OP? Сообщать миру про банальный флаг во fstab которому сто лет в обед?
У меня сильное впечатление что архитектуру ему делала ллм =) очень в её стиле, и велосипеды и UI на Tauri и характерный оверинженеринг в целом.
Из аккаунт-менеджера в iot и сразу с солидно выглядящим коммерческим продуктом на рынок. ЛЛМ - мечты сбываются
Я не понял, почему если бэкенд на Rust, то автодополнением ввода занимается js код?? Это же задача бэкенда? Особенно при том что у вас стоит цель выполнять запросы быстро на большом вводе. Есть готовые движки для нечёткого поиска, например fuzzy-matcher в skim (клон fzf на Rust) или превосходящий его в производительности nucleo.
Имхо: это то, что называется "solves a non-problem". Очень редко бывает, что юзер опечатывается в коротком вводе который у него перед глазами, и ещё реже, что он не замечает опечатки - просто глядя на экран, или по результатам автодополнения по ошибочному вводу. Обработка опечаток заставляет вас реализовывать сложный и дорогой алгоритм нечёткой близости слов, при том что это нужно в 0.001% случаев. Кроме того нечёткий алгоритм часто даёт много нерелевантных результатов, кто пользуется нечётким поиском по Unix путям к файлов тот знает. Сделайте просто поиск по подстрокам (с нечёткостью только по отношению к регистру и к порядку паттернов, вводимых юзером, т.е. чтобы "def__AbC" подходило под запрос "abc def") и вам этого будет достаточно почти для всего. Ещё лучше сделать алгоритм с обработкой "frecency" - учитыванием как близости к поисковому запросу, так и частотой выигрыша в прежних запросах. Но ок, если вы хотите в эту кроличью нору с опечатками, то, ряд движков автодополнения реализуют подобные алгоритмы с устойчивостью к опечаткам, например frizbee. Fzf насколько я знаю так не умеет, но Skim умеет: https://www.reddit.com/r/neovim/comments/1qpary8/fzfluaskim_now_supports_typo_resistant_fuzzy/ Немного отсылок к теории по этим алгоритмам есть в доках к Nucleo и Frizbee. Известный алгоритм для этого это Smith-Waterman, он вообще для ДНК цепочек, но применим к текстовому поиску. Именно его вариации применяют nucleo и frizbee. Также классика это Levenshtein distance / Levenshtein algorithm.
Также по архитектуре замечание, я так понимаю что если ваш алгоритм обнаруживает результат чёткого поиска, то нечёткий поиск запущен не будет и результаты нечёткого поиска не попадут в выдачу? Правильное поведение здесь это имхо асинхронное формирование списка вывода и обновление его в реальном времени по мере обнаруживания новых результатов.
Разумеется. Так работает примерно вся математика и в значительной мере тестирование ПО.
Мне не очень важно знать, насколько хорошо система кодогенерации работает на happy path и насколько много кода она может при этом нагенерить и насколько сложные задачи он будет решать. Допускаю, что есть должности в разработке, где это имеет значение, но это не мой случай. Мне гораздо важнее знать, как она работает в плохих случаях и насколько легко это обнаружить, если я дам этой системе генерировать код вместо меня.
У вас очень своеобразная интерпретация того, что такое понимание модели вычислений. Понимание это когда я 100 раз даю LLM на вход тот код, который я дал выше копилоту - вывод этого кода детерминированный - прошу её предсказать этот вывод, и она даёт корректное предсказание в 100 случаях, потому что берёт и исполняет код в этой модели, ну или хотя бы пытается организовать эту модель и действовать в её рамках. Иначе это правдоподобные рассуждения, вайбкодинг, гадание, но никак не понимание.
Ну слава богу догадался наконец, но говорить "решит любую задачу" про систему, которая с одинаковой легкостью выдаёт и правильный анализ и решение, меняющее поведение программы, и не видящую в этом проблемы, - это перебор.
И если придираться, то решение с вектором тоже так себе. Если в инпуте миллион элементов, он аллоцирует вектор на миллион элементов, хотя можно обойтись обычным поэлементным циклом с условием.
Я-то нет, но вы вроде говорили, что LLM на это способна?
Стандартный ответ. Ну что ж, я готов продолжить дискуссию, когда внутри LLM будет модель исполнения C++ кода и когда они не будут галлюцинировать.
Нет, неправильно, так как исходная задача (если убрать отладочную печать "pay for processing") выведет result: 2, result: 4, result: 6, а ваше изменение приводит к выводу: "result: 3, result: 5". Патч изменил наблюдаемое поведение. На сём предлагаю закончить дискуссию о волшебном умении ллм решить любую задачу.
Это by design. В условии задачи не говорится, что в общем случае возможно произвести фильтрацию до платной операции. Run_paid_request я сделал операцией увеличения на единицу для простоты, в реальности это чёрный ящик.
2-3 формально верно, но несущественно.
4 просто неверно. Второй раз уже это говорю. Static const это прямое указание как компилятору, так и читающему код человеку, что лямбда одна и та же при любом запуске, и во многих похожих случаях приводит к инлайнингу лямбды. Что хочет выразить автор кода, сделав run_paid_request неконстантной или нестатической? Она может измениться между запусками? Она может быть переприсвоена?
В целом рефакторинг конечно замечательный, но напомню, что в исходный вопрос входило также "Что напечатает данный конкретный код"?
Платной операцией является run_paid_request.
что ж, неплохой прогресс по сравнению с исходным посылом "попробуйте показать мне задачу, которую не решит LLM"
Нет там используемых классов с документацией. Там код в 10 строчек, 1 функция, вызывающая ranges::transform и ranges::filter. Весь нужный здесь контекст - это указание на возможную дороговизну ф-и run_paid_request. Никакой комплексный анализ не нужен, это не про ассемблерную оптимизацию вопрос. Там тупо дорогая функция вызывается больше раз чем надо.
Говорят, помогает запустить код и проверить, правильно ли LLM его предсказала? https://godbolt.org/z/e783T6sq5 - дорогая функция вызывается для нечётных элементов 2 раза.
Я очень часто вижу такой ответ от апологетов llm. Не та модель, возьмите платную модель и всё получится, дайте больше документации... Какой документации??? Там #!!.* написан грёбаный автономный код в десяток строчек! У него вывод предопределён моделью данных STL. Модель или предсказывает его правильно или нет.
В платных моделях есть математическая модель среды исполнения C++ кода и они мне дадут правильный ответ на этот вопрос, особенно если я уберу из кода все толстые подсказки вида печати в cout в определённом месте? Или всё же там внутри всё тот же вероятностный механизм, просто чуть лучше работающий и с обвесом в виде агентов и полаганием на сайд-эффекты типа выхлопа тестов?
Что ж, разочарую вас:
https://copilot.microsoft.com/shares/9NoKwVTmdN8Uu1ADR3pME
Основная проблема с кодом не найдена, предсказание вывода неверное, понимания работы ranges не наблюдаю. Дан ряд несущественных замечаний, причём не всегда верных ("A normal local lambda would be clearer" - ллм буквально не понимает как работает static const).
Так вот, пока LLM не научатся моделировать математически точный процесс исполнения C++ (Python, Go...) кода, я бы не стал делать громких заявлений по поводу того, что LLM может сделать любую задачу.
tl:dr любой код, который требует понимания ментальной модели среды исполнения (aka модели мира) для корректной реализации. Ну вот классический и многим известный пример на c++, про который ни одна LLM мне не смогла ни правильно сказать, что с ним не так, ни предсказать правильный вывод - тк для этого надо понимать внутреннюю логику c++20 filters/ranges:
Дана C++ реализация функции process_data, имитирующей дорогую обработку входных данных (run_paid_request) и затем фильтрацию. Есть ли в ней архитектурные проблемы, проблемы производительности? Что выведет на экран запуск программы?
в оригинале lock contention, это не блокировка а соревнование за блокировку, несколько другая вещь
што такое сетевой поток. В оригинале "decompressing in the same thread that was doing the networking transfers". Т.е. занятие распаковкой трафика в том же треде который шлёт пакеты в сеть
В целом - звучит конечно круто, но крайне подвержено ошибке выжившего, тк автор не поделился с нами статистикой сколько раз в подобных сценариях клод выдал бред и сколько ушло на проверку этого бреда
Верно, вмешиваться во ввод в eBPF можно только в сетевой подсистеме, в остальных частях ядра можно только наблюдать/фильтровать, в тч писать колбеки на вызовы клавиатурных функций.
eBPF же
Вот это настойчивость, моё увожение.
https://github.com/dermesser/uvco случайно не вашу задачу решает?