Не хватает опции 80-90% руками, AI только для рутины, которую можно "читать по диагонали" - вроде "рыбы" для тестов и в качестве источника условно-"альтернативного" взгляда на код.
Ведь всё это "fine and dandy" ровно до тех пор, пока вам не надо подписываться чем-то серьёзным под результатом. А значит вдумчиво разбирать, что же там "ИИ"-агент нафантазировал, нет ли там затейливых "student-style приколов" в реализации, элементарных ошибок на уровне "детский сад" или же gross-overengineering-трэша в ущерб базе, о котором никто "ИИ"-агента не просил.
Хороший обзор и полезное напоминание про вопросы экономии хипа в новых JVM, спасибо.
Интересно, в дополнение к расходу памяти для обычных/сжатых заголовков, кто-то уже делал с помощью JMH сравнение производительности чтения/записи в каких ни будь типовых структурах вроде HashMap/TreeSet/CHM/CSLM на относительно больших количествах - десятках/сотнях миллионов объектов? Очень любопытно, как сжатые заголовки влияют на производительность.
Любопытно, в каком конкретном месте статьи и в каких именно речевых оборотах вы углядели ваше "и Ты этим хвалишься?"?
Что касается упомянутой вами "копееечной ардулинки": связь по Wi-Fi и предоставление текущих значений на веб-странице для просмотра из нескольких браузеров были исходными требованиями. Вспомните, что было доступно весной 2013-го года и можете придумывать своё решение на "ардулинки".
Задача никогда не подразумевала тиражирование, на котором можно было бы вести речь о хоть какой-то "экономике процесса". Подозреваю, что одно только изучение темы "устройств попроще", не говоря уже про разный tooling, написание и отладку, прямо в самом начале потребовали бы времени в разы больше, чем всё время, потраченное мной на все стадии этого "проекта".
Да потоки выполняются параллельно, но если мы берем допустим самый простой вывод в консоль, то какой результат выведется вперед мы никак не сможем узнать.
И именно на этой основе я создал свой алгоритм генерации случайного числа.
Лихо.
Дональд Э. Кнут предметно и по делу, абсолютно без лишней "воды", посвятил существенную часть второго тома своего фундаментального труда разным вопросам случайных чисел в контексте программирования. Разработчики операционных и криптографических систем тратят усилия на драйверы специальной аппаратуры и разнообразные ухищрения с наблюдениями за событиями в системе для получения энтропии. А оказывается (нет) что всё это можно было заменить, используя (якобы) случайный порядок доступа потоков к разделяемому ресурсу - консоли блокировке объекта lObj...
Недавно читал по диагонали про то, что при сравнении разных видов спорта, выборка по занимающимся теннисом якобы показала хорошие (наилучшие?) результаты по показателю (увеличения) продолжительности жизни. Интересно, как подобные работы учитывают социокультурные особенности быта групп, связанные с уровнем и стилем жизни, ведь до недавнего времени занятие теннисом было доступно (а местами и по сей день) по большей степени обеспеченным людям, как в финансовом так и в социальном плане. Со всеми вытекающими поправками на стиль жизни, сон, питание, уровень стресса и так далее.
Согласен, там есть очевидные пути уменьшения размера результирующего .jar или повышения производительности эндпоинта метрик путём отделения предметных метрик от системных. Но это пойдёт вразрез с сутью образовавшегося эксперимента - нагружать "Малинку" java-bloat'ом от максимально просто/прямолинейно сделанного приложения на текущем технологическом уровне.
Второй "вид" паролей в классификации выглядит как чрезмерное упрощение. Потеря будет действительно "необратимой" не во всех случаях. Например: "взломы"/подборы паролей к разным алгоритмам спустя десятилетия за счёт увеличения доступных вычислительных мощностей или обнаружения уязвимостей алгоритмов и/или ключей; разные алгоритмические и хардверные ошибки/бэкдоры в аппаратных механизмах шифрования. Даже без пресловутых "квантовых алгоритов", что отдельная большая тема...
Не хватает опции 80-90% руками, AI только для рутины, которую можно "читать по диагонали" - вроде "рыбы" для тестов и в качестве источника условно-"альтернативного" взгляда на код.
Ведь всё это "fine and dandy" ровно до тех пор, пока вам не надо подписываться чем-то серьёзным под результатом. А значит вдумчиво разбирать, что же там "ИИ"-агент нафантазировал, нет ли там затейливых "student-style приколов" в реализации, элементарных ошибок на уровне "детский сад" или же gross-overengineering-трэша в ущерб базе, о котором никто "ИИ"-агента не просил.
Хороший обзор и полезное напоминание про вопросы экономии хипа в новых JVM, спасибо.
Интересно, в дополнение к расходу памяти для обычных/сжатых заголовков, кто-то уже делал с помощью JMH сравнение производительности чтения/записи в каких ни будь типовых структурах вроде HashMap/TreeSet/CHM/CSLM на относительно больших количествах - десятках/сотнях миллионов объектов? Очень любопытно, как сжатые заголовки влияют на производительность.
Любопытно, в каком конкретном месте статьи и в каких именно речевых оборотах вы углядели ваше "и Ты этим хвалишься?"?
Что касается упомянутой вами "копееечной ардулинки": связь по Wi-Fi и предоставление текущих значений на веб-странице для просмотра из нескольких браузеров были исходными требованиями. Вспомните, что было доступно весной 2013-го года и можете придумывать своё решение на "ардулинки".
Задача никогда не подразумевала тиражирование, на котором можно было бы вести речь о хоть какой-то "экономике процесса". Подозреваю, что одно только изучение темы "устройств попроще", не говоря уже про разный tooling, написание и отладку, прямо в самом начале потребовали бы времени в разы больше, чем всё время, потраченное мной на все стадии этого "проекта".
Лихо.
Дональд Э. Кнут предметно и по делу, абсолютно без лишней "воды", посвятил существенную часть второго тома своего фундаментального труда разным вопросам случайных чисел в контексте программирования. Разработчики операционных и криптографических систем тратят усилия на драйверы специальной аппаратуры и разнообразные ухищрения с наблюдениями за событиями в системе для получения энтропии. А оказывается (нет) что всё это можно было заменить, используя (якобы) случайный порядок доступа потоков к разделяемому ресурсу -
консолиблокировке объекта lObj...Недавно читал по диагонали про то, что при сравнении разных видов спорта, выборка по занимающимся теннисом якобы показала хорошие (наилучшие?) результаты по показателю (увеличения) продолжительности жизни. Интересно, как подобные работы учитывают социокультурные особенности быта групп, связанные с уровнем и стилем жизни, ведь до недавнего времени занятие теннисом было доступно (а местами и по сей день) по большей степени обеспеченным людям, как в финансовом так и в социальном плане. Со всеми вытекающими поправками на стиль жизни, сон, питание, уровень стресса и так далее.
Correlation does not imply causation.
Согласен, там есть очевидные пути уменьшения размера результирующего .jar или повышения производительности эндпоинта метрик путём отделения предметных метрик от системных. Но это пойдёт вразрез с сутью образовавшегося эксперимента - нагружать "Малинку" java-bloat'ом от максимально просто/прямолинейно сделанного приложения на текущем технологическом уровне.
Второй "вид" паролей в классификации выглядит как чрезмерное упрощение. Потеря будет действительно "необратимой" не во всех случаях. Например: "взломы"/подборы паролей к разным алгоритмам спустя десятилетия за счёт увеличения доступных вычислительных мощностей или обнаружения уязвимостей алгоритмов и/или ключей; разные алгоритмические и хардверные ошибки/бэкдоры в аппаратных механизмах шифрования. Даже без пресловутых "квантовых алгоритов", что отдельная большая тема...