Лучше, чтобы кто-то подал в суд, чем чтобы все промолчали. Толку, конечно же не будет, но не всё измеряется толком. Что-то нужно делать и "ради искусства". Моё уважение инициативной группе.
Ну так всё верно, высокая константа, разница начинает идти "в плюс" на десятках тысяч. Поэтому стандартная сортировка нигде не radix sort. Предполагается, что если у вас специальные условия, например, прям очень много данных - вы сами напишите (или возьмёте) что-то идеально подходящее.
С этим полностью согласен. Я только к тому, что и люди тоже далеко от идеала. Другое дело, что у человека больше шансов научиться, в LLM судя по всему мы уже в асимптотических улучшениях, если не хуже.
Про дебагер никто не говорил. Это может быть (как было в ОК, когда я там работал) системой экстренной доставки критических правок. Она считалась наиболее безопасной как раз по причине локальности и верифицируемости изменений.
Кажется мир в целом идёт (обратно?) к тому, что многие вещи проще сделать самому, чем заказывать у кого-то. Не только в софте, но и в быту. Инструменты становятся доступнее людей, информация тоже доступна как никогда.
При том что я полностью с вами согласен, я бы добавил таки бочку дегтя в бочку дегтя.
Црм написанная человеком тоже не всегда может быть нормально продана, нормально поддерживаться, держать нагрузку, проходить пентест, развиваться с обратной совместимостью и так далее.
Ну т.е. уж таких-то чудес я от живых человеков не всегда бы ожидал, не то что от тупой железяки. Если (в редких случаях) она мне хоть в чем-то помогает, я уже рад. Ну там, комментарий к коммиту сгенерировать (в половине случаев угадывает). Картинки для презентации сгенерить. Загуглить за меня какое-то часто встречающееся решение и слегка подпилить его под ограничение (справляется в 30% случаев, но в 80% выхлоп лучше, чем если сразу делать самому).
Короче, кажется, появление Гугла и StackOverflow были сильно более прорывными, чем LLM, но и для них тоже местечко найдется, пока ещё они дешёвые (что вряд ли продлится долго).
В OpenJDK Instrumentation API и JDI реализованы поверх JVMTI.
Для большинства практических сценариев этого оказывается достаточно: что-то по-быстрому подправить можно даже на проде, и указанные ограничения (отсутствие изменения структуры классов) - это скорее плюс, чем минус для таких случаев.
Плюс вы практически не получаете никаких неожиданных спец-эффектов (тех, что может найти среднестатистический разработчик - точно).
Процессор мягко говоря не только следует конвейеру команд. Да, если рассматривать исполнение только в рамках одного потока, то результат будет выглядеть так, будто бы это утверждение верно.
Тем не менее, с разбега можно назвать: аллокация/переименование регистров, спекулятивное исполнение, предсказание ветвлений, эвристики префетча памяти, кэширование чтения и буферизация записи. Многое из этого никак или почти никак не контролируется из кода напрямую и выполняется самим процессором, часто даже без спецификации. И это всё ещё не затрагивая протоколы когерентности, если мы начинаем мыслить в рамках нескольких потоков исполнения и/или ядер.
Я честно говоря не уверен, что верно распарсил направление вашей мысли и стараюсь угадать, что вы вообще могли иметь ввиду, но даже с учётом этого, в ваших утверждения точно достаточно много фактических ошибок. Возможно, они основаны на недостаточном понимании устройства реальных современных процессоров.
Я просто отмечу, что на моем опыте оверхед от Hibernate - это 20% CPU profile в среднем по больнице. И обычно в этих 20% происходит примерно ничего полезного с точки зрения бизнес-логики.
Я тоже согласен с @Plesserи тоже выберу при прочих равных человека с pet project'ами, горящими глазами и вот это вот всё. Но не согласен с тем, что сессия - это какой-то незначительный стресс. Для многих, в том числе для меня, любое "испытание", которое лишь косвенно связано с профессиональными навыками, такое как сессия, собеседование, публичное выступление и т.п. - это колоссальный стресс. Даже после десятков повторений процедур, даже если они сами по себе могут нравиться.
В современных чипах это ветвление занимает ноль тактов.
Ну я вполне втыкался в производительность branch-miss'ов, для этого есть даже хрестоматийный пример, который вы можете воспроизвести и у себя: наивное чтение var-int'ов с помощью цикла. В этом случае у предсказателя переходов слишком высокая доля ошибок. Тривиальное лечение - вручную развернуть цикл, чтобы у таблицы переходов были разные адреса, и тогда если у вас в горячем цикле var-int'ы примерно одного размера, то всё починится само. Если у вас совсем произвольные var-int'ы, тогда есть чуть более сложные техники.
Тем не менее, даже в случае, если у вас всё хорошо предсказывается, таблицы предсказания ветвлений в процессорах не бесконечные. Руками вы конечно вряд ли их забьёте, но если начнёте генерировать код с избыточным ветвлением, то статистика предсказаний вполне может начать вытесняться.
Мне это всегда казалось и продолжает казаться неплохим способом проверить замотивированность кандидата заниматься относительно длительной подготовкой к интервью. Примерно как диплом о ВО доказательство 4-6 лет "усидчивости". Поэтому с готовностью решаю алгоритмические секции, но со своей стороны при собеседованиях делаю скидку, что вообще говоря, человек не обязан знать трюк с prefix sum, будь он трижды тривиальным (когда его знаешь). Не обязан уметь вращать деревья в уме. Но если вдруг умеет и в структуры данных, и в методы работы с ними, то разговор точно пойдет и проще, и интереснее. По крайней мере, это точно интереснее, чем фреймворк А, который уже завтра будет заменён фреймворком Б.
Да и регуляторы в ЕС по головке не погладят. Даже если внедрят, будут обязаны (как мне думается) продавать и инструменты.
Лучше, чтобы это было, чем чтобы этого не было.
Лучше, чтобы кто-то подал в суд, чем чтобы все промолчали. Толку, конечно же не будет, но не всё измеряется толком. Что-то нужно делать и "ради искусства". Моё уважение инициативной группе.
У детей не умерли. У меня в доме 5 ноутбуков, телек, PS5, два планшета, 5 телефонов и это не считая всевозможного IoT-барахла.
Ну так всё верно, высокая константа, разница начинает идти "в плюс" на десятках тысяч. Поэтому стандартная сортировка нигде не radix sort. Предполагается, что если у вас специальные условия, например, прям очень много данных - вы сами напишите (или возьмёте) что-то идеально подходящее.
И у нее константа такова, что в реальности quick sort оказывается зачастую быстрее.
С этим полностью согласен. Я только к тому, что и люди тоже далеко от идеала. Другое дело, что у человека больше шансов научиться, в LLM судя по всему мы уже в асимптотических улучшениях, если не хуже.
Про дебагер никто не говорил. Это может быть (как было в ОК, когда я там работал) системой экстренной доставки критических правок. Она считалась наиболее безопасной как раз по причине локальности и верифицируемости изменений.
Ой, ну одна-две-три таких историй когда-нибудь обязательно появится. Думаю из них всё ещё будет странно делать хоть какие-то выводы.
Кажется мир в целом идёт (обратно?) к тому, что многие вещи проще сделать самому, чем заказывать у кого-то. Не только в софте, но и в быту. Инструменты становятся доступнее людей, информация тоже доступна как никогда.
При том что я полностью с вами согласен, я бы добавил таки бочку дегтя в бочку дегтя.
Црм написанная человеком тоже не всегда может быть нормально продана, нормально поддерживаться, держать нагрузку, проходить пентест, развиваться с обратной совместимостью и так далее.
Ну т.е. уж таких-то чудес я от живых человеков не всегда бы ожидал, не то что от тупой железяки. Если (в редких случаях) она мне хоть в чем-то помогает, я уже рад. Ну там, комментарий к коммиту сгенерировать (в половине случаев угадывает). Картинки для презентации сгенерить. Загуглить за меня какое-то часто встречающееся решение и слегка подпилить его под ограничение (справляется в 30% случаев, но в 80% выхлоп лучше, чем если сразу делать самому).
Короче, кажется, появление Гугла и StackOverflow были сильно более прорывными, чем LLM, но и для них тоже местечко найдется, пока ещё они дешёвые (что вряд ли продлится долго).
В OpenJDK Instrumentation API и JDI реализованы поверх JVMTI.
Для большинства практических сценариев этого оказывается достаточно: что-то по-быстрому подправить можно даже на проде, и указанные ограничения (отсутствие изменения структуры классов) - это скорее плюс, чем минус для таких случаев.
Плюс вы практически не получаете никаких неожиданных спец-эффектов (тех, что может найти среднестатистический разработчик - точно).
Процессор мягко говоря не только следует конвейеру команд. Да, если рассматривать исполнение только в рамках одного потока, то результат будет выглядеть так, будто бы это утверждение верно.
Тем не менее, с разбега можно назвать: аллокация/переименование регистров, спекулятивное исполнение, предсказание ветвлений, эвристики префетча памяти, кэширование чтения и буферизация записи. Многое из этого никак или почти никак не контролируется из кода напрямую и выполняется самим процессором, часто даже без спецификации. И это всё ещё не затрагивая протоколы когерентности, если мы начинаем мыслить в рамках нескольких потоков исполнения и/или ядер.
Я честно говоря не уверен, что верно распарсил направление вашей мысли и стараюсь угадать, что вы вообще могли иметь ввиду, но даже с учётом этого, в ваших утверждения точно достаточно много фактических ошибок. Возможно, они основаны на недостаточном понимании устройства реальных современных процессоров.
Ну известно же, что переписывания с языка А на язык В всегда улучшает почти все важные показатели. Остаётся верным при перемене мест А и В и при А=В.
Я просто отмечу, что на моем опыте оверхед от Hibernate - это 20% CPU profile в среднем по больнице. И обычно в этих 20% происходит примерно ничего полезного с точки зрения бизнес-логики.
У меня сейчас четвертая ипотека, причем уже в другой стране. Снится мне всё ещё школа.
Я тоже согласен с @Plesserи тоже выберу при прочих равных человека с pet project'ами, горящими глазами и вот это вот всё. Но не согласен с тем, что сессия - это какой-то незначительный стресс. Для многих, в том числе для меня, любое "испытание", которое лишь косвенно связано с профессиональными навыками, такое как сессия, собеседование, публичное выступление и т.п. - это колоссальный стресс. Даже после десятков повторений процедур, даже если они сами по себе могут нравиться.
По тону высказывания, я так понял, речь про стоимость.
Я не понимаю, почему все в пример приводят Java. Пожалуйста, на Java тоже прекратите писать интерфейсы где не надо.
Ну я вполне втыкался в производительность branch-miss'ов, для этого есть даже хрестоматийный пример, который вы можете воспроизвести и у себя: наивное чтение var-int'ов с помощью цикла. В этом случае у предсказателя переходов слишком высокая доля ошибок. Тривиальное лечение - вручную развернуть цикл, чтобы у таблицы переходов были разные адреса, и тогда если у вас в горячем цикле var-int'ы примерно одного размера, то всё починится само. Если у вас совсем произвольные var-int'ы, тогда есть чуть более сложные техники.
Тем не менее, даже в случае, если у вас всё хорошо предсказывается, таблицы предсказания ветвлений в процессорах не бесконечные. Руками вы конечно вряд ли их забьёте, но если начнёте генерировать код с избыточным ветвлением, то статистика предсказаний вполне может начать вытесняться.
Мне это всегда казалось и продолжает казаться неплохим способом проверить замотивированность кандидата заниматься относительно длительной подготовкой к интервью. Примерно как диплом о ВО доказательство 4-6 лет "усидчивости". Поэтому с готовностью решаю алгоритмические секции, но со своей стороны при собеседованиях делаю скидку, что вообще говоря, человек не обязан знать трюк с prefix sum, будь он трижды тривиальным (когда его знаешь). Не обязан уметь вращать деревья в уме. Но если вдруг умеет и в структуры данных, и в методы работы с ними, то разговор точно пойдет и проще, и интереснее. По крайней мере, это точно интереснее, чем фреймворк А, который уже завтра будет заменён фреймворком Б.