А я думаю, речь не о вас. Потому что ваша критика, несмотря на якобы тот же вывод, имеет совершенно другой посыл: вы говорите, чего не хватает, чтобы сделать статью ещё более полезной (или просто полезной), а не просто набрасывает на вентилятор.
Я когда читал, думал почти теми же словами, хотя сам себе и отвечал: ну да, QEMU, но скорее всего так же запустится из BIOS, UEFI, etc. Ну да, /boot - это вообще мало отношения имеет к тому, что такое ядро.
Но даже со всеми оговорками, направление-то у статьи правильное - больше людей вдохновиться пойти и потрогать лапками ядро, прошивки, драйвера и всё, что людей отталкивает, потому что издалека выглядит магией.
Писать код вообще очень быстро, без всякого AI, не понимаю сути проблемы. Объяснить идею кодом проще и быстрее, чем на естественном языке, за редкими исключениями, когда, скажем, уже есть достаточно полная спецификация.
Намного сложнее же код читать. Поэтому не понимаю, почему люди оптимизируют простое и быстрое за счёт ухудшения сложного и медленного.
Ну сейчас ассемблер - это тоже очень промежуточное представление, не всегда чисто по ассемблеру можно разницу понять. А JIT таки выдает ассемблерные листинги по самому первому запросу, было бы кому попросить)
Ну вообще-то нет. Это только самый верхний слой вопроса. Дальше неплохо понимать, во что этот код переваривается после JIT. Дальше было бы неплохо понимать, а как с данными, расположенными таким образом, работает процессор и кэши. Вообще неплохо было бы понимать, что не O-нотацией единой живёт производительность, и что то, что написано в исходниках стандартной библиотеки зачастую совсем не то, что будет реально исполняться (интринсики, несколько уровней JIT и т.д.).
песочница с чистым холодным процессорным временем и гарантией того что это влезет в его кэш
Это - что? И в какой кэш? В JVM используется много разных интересных оптимизаций, улучшающих как локальность данных, так и локальность кода. Плюс в продакшене у вас будет не песочница, а реальность, и интерференции с реальностью всё сильно меняют. Пример: моно/дуо/мегаморфизм, из-за которых JIT в бенчмарках показывает такой же результирующий код с лямбдами, как без них, но в реальности часто всё сыпется. Поэтому к измерениях в песочницах нужно относиться с соответствующим скепсисом, а мерить нужно не только CPU-time, но и Wall-time тоже, артефакты бывают разными.
Произвольный доступ вместо последовательного для любой блочной памяти или кэша это катастрофа а виртуальная машина своим жиром делает именно так.
Ещё раз к локальности данных. Как раз перемещающий GC (т.е. любой современный GC) в среднем по больнице обеспечивает прекрасную локальность по данным, они чаще всего физически лежат рядом. Исключение: плохо сконфигуринованные low-latency GC, они часто вымывают кэши постоянным сканом памяти. Если на это нужны гарантии - этого тоже можно добиться для экстремальных случаев, работая с памятью напрямую (массивы и/или off-heap решения, коих тоже минимум два в стандартной библиотеке). Работая просто с массивами, когда данных прям много, мне удавалось доходить до того, что узким местом являлось, например, предсказание ветвлений (не из-за JVM, а из-за обычного пользовательского кода).
тесты обязательно прогонять на N от 0 до миллиона чтобы посмотреть что творится "внизу" ступеньки
Тесты нужно не просто прогонять на 0 ... (очень много). Нюансов вагон и тележка. Тестировать перформанс вообще очень сложно, но начать можно и даже с wall-clock. Лучше тестировать плохо, чем не тестировать вообще. Но да, для Java есть state of the art решения, вроде JMH, которые большУю часть головной боли берут на себя.
С другой стороны, профилировать намного проще. Потому что только в реальном кейсе можно понять, а что вообще вам нужно. Ускорить холодный старт? Обеспечить высокую среднюю производительность? Гарантировать отсутствие деградации в плохих случаях? И так далее. Затем, насмотревшись на профиля, придет и некоторое базовое понимание "законов перформанса" для конкретно ваших случаев. Ну и ещё раз про проще: при профилировании "кнопочка нажаль картинка получиль", думать почти не нужно, всё видно, и всё реально, а не фантомные боли неправильно сконфигурированной тестовой системы.
Ну так фокусироваться надо не на редких положительных случаях, а на ситуации в целом. И в целом "писать код" в норме AI-агентами для меня дольше, хуже и т.д. Нет, конечно, у многих коллег код получается ещё хуже, чем если бы их сгенерил больной разум LLM, но тут уж извините, не в LLM дело.
Вообще, "я бы два часа вникал в то, что происходит в тесте"... Ну как-то без комментариев. У меня не бывает такого, чтобы два часа - это было много. Ну вот вникал бы я два часа. И? Зато я бы не тратил полдня на то, чтобы "объясняться" с AI. Конечно, если это какая-то левая хрень, с которой мне потом не работать - то пожалуйста, на здоровье. А если я потратил эти 2 часа, или даже два дня, чтобы самому лучше разбираться в предметной области, с которой мне же потом и жить... Плохо что ли? Хорошо!
Для меня AI - это Гугл на стероидах + относительно вменяемый перевод с языка А на язык Б, где язык может быть как естественным, так и программирования. Ну и "отмывочная". Нельзя вставить кусок GPL-кода к себе, но можно попросить сгенерировать. Ну и что, что он примерно такой же. Интересно, кто-нибудь когда-нибудь что-то с этим сделает?
Да, AI изменил нашу жизнь. Но к сожалению, не потому что мы время от времени используем его в уместных ситуациях, а потому что другие ничего другого и не умеют. А может это и хорошо - кто-то же должен потом за этим всем убирать, а конкуренции будет только меньше.
А у меня противоположный опыт. Да, он может объяснить отдельные инструкции и даже некоторые их типичные сочетания, и это реально экономит время. Но найти проблему, а тем более с ней что-то сделать - это исключительно если угадал пальцем в небо.
Нормальный джавист знает, как работает "магическая херабора в спринге". И если не знает, как работает эта конкретная херабора, быстро поймет в крайнем случае на этапе возникновения проблемы, а в идеале - на этапе принятия решения, какую херабору использовать, а какую нет.
Нормальный джавист понимает хотя бы примерно, во что привращается его код после javac, а самые "нормальные", хотя бы примерно представляют, во что он превращается после JiT'а и может это проверить хотя бы с помощью профилирования.
Хотя бы зачаточные навыки работы без IDE (не знание всего подряд наизусть и не скорость набора букв) тоже большой плюс - это помогает писать код и в голове тоже, что в свою очередь, помогает его в голове же и отлаживать, что важно, когда у вас есть проблемы в продакшене, а не на локальной машине.
В общем, ваш комментарий дополняет сказанное в статье, а не противоречит ему. И даже если кто-то заблуждается, всё-таки лицемерие и заблуждение, мягко говоря, не одно и то же.
Чтобы не попадать в ситуацию, когда сравнивается тёплое с мягким, можно использовать любой вменяемый профайлер. Если мы говорим про JVM-based языки, то async-profiler. Посмотрите что именно у вас занимает время, и всё встанет на свои места. Окажется, что по понятным причинам, цикл, написанный корректно, абсолютно всегда быстрее лямбд (как минимум в указанных языках). Единственное возможное исключение: когда JIT смог соптимизировать лямбды до полностью эквивалентного состояния, но даже в этом случае, это зачастую хрупкое и шаткое состояние, любой чих (даже далеко от предполагаемого места) может его сломать.
Лучше, чтобы кто-то подал в суд, чем чтобы все промолчали. Толку, конечно же не будет, но не всё измеряется толком. Что-то нужно делать и "ради искусства". Моё уважение инициативной группе.
Ну так всё верно, высокая константа, разница начинает идти "в плюс" на десятках тысяч. Поэтому стандартная сортировка нигде не radix sort. Предполагается, что если у вас специальные условия, например, прям очень много данных - вы сами напишите (или возьмёте) что-то идеально подходящее.
С этим полностью согласен. Я только к тому, что и люди тоже далеко от идеала. Другое дело, что у человека больше шансов научиться, в LLM судя по всему мы уже в асимптотических улучшениях, если не хуже.
Про дебагер никто не говорил. Это может быть (как было в ОК, когда я там работал) системой экстренной доставки критических правок. Она считалась наиболее безопасной как раз по причине локальности и верифицируемости изменений.
Кажется мир в целом идёт (обратно?) к тому, что многие вещи проще сделать самому, чем заказывать у кого-то. Не только в софте, но и в быту. Инструменты становятся доступнее людей, информация тоже доступна как никогда.
А я думаю, речь не о вас. Потому что ваша критика, несмотря на якобы тот же вывод, имеет совершенно другой посыл: вы говорите, чего не хватает, чтобы сделать статью ещё более полезной (или просто полезной), а не просто набрасывает на вентилятор.
Я когда читал, думал почти теми же словами, хотя сам себе и отвечал: ну да, QEMU, но скорее всего так же запустится из BIOS, UEFI, etc. Ну да, /boot - это вообще мало отношения имеет к тому, что такое ядро.
Но даже со всеми оговорками, направление-то у статьи правильное - больше людей вдохновиться пойти и потрогать лапками ядро, прошивки, драйвера и всё, что людей отталкивает, потому что издалека выглядит магией.
В текущем законодательстве не запрещено конечному пользователю смотреть Ютуб, запрещено провайдеру его показывать. По крайней мере пока.
Писать код вообще очень быстро, без всякого AI, не понимаю сути проблемы. Объяснить идею кодом проще и быстрее, чем на естественном языке, за редкими исключениями, когда, скажем, уже есть достаточно полная спецификация.
Намного сложнее же код читать. Поэтому не понимаю, почему люди оптимизируют простое и быстрое за счёт ухудшения сложного и медленного.
Ну сейчас ассемблер - это тоже очень промежуточное представление, не всегда чисто по ассемблеру можно разницу понять. А JIT таки выдает ассемблерные листинги по самому первому запросу, было бы кому попросить)
Ну вообще-то нет. Это только самый верхний слой вопроса. Дальше неплохо понимать, во что этот код переваривается после JIT. Дальше было бы неплохо понимать, а как с данными, расположенными таким образом, работает процессор и кэши. Вообще неплохо было бы понимать, что не O-нотацией единой живёт производительность, и что то, что написано в исходниках стандартной библиотеки зачастую совсем не то, что будет реально исполняться (интринсики, несколько уровней JIT и т.д.).
Простите, у вас тоже как-то всё в кучу.
Это - что? И в какой кэш? В JVM используется много разных интересных оптимизаций, улучшающих как локальность данных, так и локальность кода. Плюс в продакшене у вас будет не песочница, а реальность, и интерференции с реальностью всё сильно меняют. Пример: моно/дуо/мегаморфизм, из-за которых JIT в бенчмарках показывает такой же результирующий код с лямбдами, как без них, но в реальности часто всё сыпется. Поэтому к измерениях в песочницах нужно относиться с соответствующим скепсисом, а мерить нужно не только CPU-time, но и Wall-time тоже, артефакты бывают разными.
Ещё раз к локальности данных. Как раз перемещающий GC (т.е. любой современный GC) в среднем по больнице обеспечивает прекрасную локальность по данным, они чаще всего физически лежат рядом. Исключение: плохо сконфигуринованные low-latency GC, они часто вымывают кэши постоянным сканом памяти. Если на это нужны гарантии - этого тоже можно добиться для экстремальных случаев, работая с памятью напрямую (массивы и/или off-heap решения, коих тоже минимум два в стандартной библиотеке). Работая просто с массивами, когда данных прям много, мне удавалось доходить до того, что узким местом являлось, например, предсказание ветвлений (не из-за JVM, а из-за обычного пользовательского кода).
Тесты нужно не просто прогонять на 0 ... (очень много). Нюансов вагон и тележка. Тестировать перформанс вообще очень сложно, но начать можно и даже с wall-clock. Лучше тестировать плохо, чем не тестировать вообще. Но да, для Java есть state of the art решения, вроде JMH, которые большУю часть головной боли берут на себя.
С другой стороны, профилировать намного проще. Потому что только в реальном кейсе можно понять, а что вообще вам нужно. Ускорить холодный старт? Обеспечить высокую среднюю производительность? Гарантировать отсутствие деградации в плохих случаях? И так далее. Затем, насмотревшись на профиля, придет и некоторое базовое понимание "законов перформанса" для конкретно ваших случаев. Ну и ещё раз про проще: при профилировании "кнопочка нажаль картинка получиль", думать почти не нужно, всё видно, и всё реально, а не фантомные боли неправильно сконфигурированной тестовой системы.
Ну так фокусироваться надо не на редких положительных случаях, а на ситуации в целом. И в целом "писать код" в норме AI-агентами для меня дольше, хуже и т.д. Нет, конечно, у многих коллег код получается ещё хуже, чем если бы их сгенерил больной разум LLM, но тут уж извините, не в LLM дело.
Вообще, "я бы два часа вникал в то, что происходит в тесте"... Ну как-то без комментариев. У меня не бывает такого, чтобы два часа - это было много. Ну вот вникал бы я два часа. И? Зато я бы не тратил полдня на то, чтобы "объясняться" с AI. Конечно, если это какая-то левая хрень, с которой мне потом не работать - то пожалуйста, на здоровье. А если я потратил эти 2 часа, или даже два дня, чтобы самому лучше разбираться в предметной области, с которой мне же потом и жить... Плохо что ли? Хорошо!
Для меня AI - это Гугл на стероидах + относительно вменяемый перевод с языка А на язык Б, где язык может быть как естественным, так и программирования. Ну и "отмывочная". Нельзя вставить кусок GPL-кода к себе, но можно попросить сгенерировать. Ну и что, что он примерно такой же. Интересно, кто-нибудь когда-нибудь что-то с этим сделает?
Да, AI изменил нашу жизнь. Но к сожалению, не потому что мы время от времени используем его в уместных ситуациях, а потому что другие ничего другого и не умеют. А может это и хорошо - кто-то же должен потом за этим всем убирать, а конкуренции будет только меньше.
А у меня противоположный опыт. Да, он может объяснить отдельные инструкции и даже некоторые их типичные сочетания, и это реально экономит время. Но найти проблему, а тем более с ней что-то сделать - это исключительно если угадал пальцем в небо.
Нормальный джавист знает, как работает "магическая херабора в спринге". И если не знает, как работает эта конкретная херабора, быстро поймет в крайнем случае на этапе возникновения проблемы, а в идеале - на этапе принятия решения, какую херабору использовать, а какую нет.
Нормальный джавист понимает хотя бы примерно, во что привращается его код после javac, а самые "нормальные", хотя бы примерно представляют, во что он превращается после JiT'а и может это проверить хотя бы с помощью профилирования.
Хотя бы зачаточные навыки работы без IDE (не знание всего подряд наизусть и не скорость набора букв) тоже большой плюс - это помогает писать код и в голове тоже, что в свою очередь, помогает его в голове же и отлаживать, что важно, когда у вас есть проблемы в продакшене, а не на локальной машине.
В общем, ваш комментарий дополняет сказанное в статье, а не противоречит ему. И даже если кто-то заблуждается, всё-таки лицемерие и заблуждение, мягко говоря, не одно и то же.
Чтобы не попадать в ситуацию, когда сравнивается тёплое с мягким, можно использовать любой вменяемый профайлер. Если мы говорим про JVM-based языки, то async-profiler. Посмотрите что именно у вас занимает время, и всё встанет на свои места. Окажется, что по понятным причинам, цикл, написанный корректно, абсолютно всегда быстрее лямбд (как минимум в указанных языках). Единственное возможное исключение: когда JIT смог соптимизировать лямбды до полностью эквивалентного состояния, но даже в этом случае, это зачастую хрупкое и шаткое состояние, любой чих (даже далеко от предполагаемого места) может его сломать.
Разве ж это ящик, так, ящичек...
Да и регуляторы в ЕС по головке не погладят. Даже если внедрят, будут обязаны (как мне думается) продавать и инструменты.
Лучше, чтобы это было, чем чтобы этого не было.
Лучше, чтобы кто-то подал в суд, чем чтобы все промолчали. Толку, конечно же не будет, но не всё измеряется толком. Что-то нужно делать и "ради искусства". Моё уважение инициативной группе.
У детей не умерли. У меня в доме 5 ноутбуков, телек, PS5, два планшета, 5 телефонов и это не считая всевозможного IoT-барахла.
Ну так всё верно, высокая константа, разница начинает идти "в плюс" на десятках тысяч. Поэтому стандартная сортировка нигде не radix sort. Предполагается, что если у вас специальные условия, например, прям очень много данных - вы сами напишите (или возьмёте) что-то идеально подходящее.
И у нее константа такова, что в реальности quick sort оказывается зачастую быстрее.
С этим полностью согласен. Я только к тому, что и люди тоже далеко от идеала. Другое дело, что у человека больше шансов научиться, в LLM судя по всему мы уже в асимптотических улучшениях, если не хуже.
Про дебагер никто не говорил. Это может быть (как было в ОК, когда я там работал) системой экстренной доставки критических правок. Она считалась наиболее безопасной как раз по причине локальности и верифицируемости изменений.
Ой, ну одна-две-три таких историй когда-нибудь обязательно появится. Думаю из них всё ещё будет странно делать хоть какие-то выводы.
Кажется мир в целом идёт (обратно?) к тому, что многие вещи проще сделать самому, чем заказывать у кого-то. Не только в софте, но и в быту. Инструменты становятся доступнее людей, информация тоже доступна как никогда.