Базовые классы Java (rt.jar) загружаются при старте приложения. Классы расширений ($JAVA_HOME/lib/ext), также загружаются при старте.
Это неправда. Не думаете же Вы в самом деле, что все 6800+ классов из rt.jar загружаются сразу же при старте?
Системные классы также загружаются по мере необходимости. В случаях, когда используется Class Data Sharing (-Xshare:on), некоторые классы (перечисленные в jre/lib/classlist) могут быть предзагружены путем отображения (mmap) файла classes.jsa в виртуальную память.
На 100 правильных ответах устал тыкать на кнопку…
За это время некоторые слова успели показаться раз по пять.
И ооочень долго из-за баннеров грузится такая простая страница.
Как разработчик JVM, уверяю: то, о чем Вы сейчас сказали, к вопросу не относится, и вообще это работает не так. Можно сколь угодно долго работать со строками, и ни в какое «хранилище» они попадать не будут, пока не будет вызван метод intern(). А выделение памяти в JVM — очень дешевая операция, даже быстрее, чем malloc() в C++.
Увеличение производительности со временем — результат именно сбора статистики и рекомпиляции методов.
Поскольку затраты на электроэнергию являются заметной составляющей расходов датацентров, такой шаг, очевидно, имеет смысл, ибо у современных ARM'ов показатель performance-per-watt в среднем лучше, чем у x86.
А теперь поменяйте местами строчки
measureArray(new SimpleArray());
measureArray(new ArrayListArray());
и померите заново. Ну как? :-)
Забавно, что результат на самом деле зависит не от реализации, а от порядка строк.
Тем не менее, это вполне ожидаемо, если понимать, как работает HotSpot.
Вы только что написали бенчмарку, про которую в свое время Dr. Cliff Click рассказывал в своей презентации «How NOT to write a Microbenchmark».
Все верно: str += word работает в точности как
StringBuilder tmp = new StringBuilder();
tmp.append(str);
tmp.append(word);
str = tmp.toString();
а каждый append() — это вызов System.arraycopy(), вдобавок toString() — еще один arraycopy() на всю длину буфера.
Соответственно, если строка str длиной 100000 символов, а word длиной 5 символов, то str += word должен будет выполнить копирование как минимум 200010 символов, в то время как builder.append(word) скопирует, как правило, только 5 символов. Почувствуйте разницу :) Хороший эксперимент, наглядный результат.
Зачем самому вбивать и переписывать? Пусть компьютер это тоже делает :)
А что, неплохое соревнование по программированию получается — кто быстрей и лучше бота напишет :)
Делить языки программирования на компиляторы и интерпретаторы — все равно, что человеческие языки делить на те, на которых говорят и те, на которых пишут. Бред. Компиляторы и интерпретаторы — это виды трансляторов. С одного языка может быть много разных трансляторов. С той же Java: gcj умеет компилировать Java-программу сразу в нативный код.
Поэтому очевидно, что слухи о Java, которая работает быстрее C++, заметно преувеличены.
Очевидно лишь то, что Вы плохо разбираетесь в том, о чем пишете. Известно, что DAC (dynamic adaptive compiler, разновидность JIT), коим обладает JVM, способен порождать более оптимальный нативный код, нежели чем статический ahead-of-time компилятор для C++ или любого другого языка. Дело в том, что во время исполнения программы компилятору известно гораздо больше о платформе и о runtime окружении. Вот лишь некоторые из оптимизаций, недоступных C++ компиляторам, которые делает JVM в runtime: девиртуализация (замена виртуальных вызовов на статические), динамическая профиляция (ипользования информации о том, какие ветки исполняются чаще), использование архитектурных особенностей процессора, на котором в данный момент исполняется программа (SSE, NUMA и т.п.)
Короче говоря, прежде чем писать об интерпретаторах, изучите предмет. Говорить об интерпретации Javascript, PHP, Perl, Python, Java и даже не упомянуть о понятии виртуальной машины… На кого бы ни была рассчитана статья, она по меньшей мере просто бесполезна, и, более того, не соответствует действительности.
Причисление современных x86 и ARM процессоров к CISC и RISC архитектуре становится весьма условным. Могу привести и ряд обратных примеров, когда то, что делает одна ARM инструкция, кодируется как минимум тремя x86. Регистров общего назначения и у x86-64, и у ARM одинаково по 16. Длина инструкций варьируется что у x86, что у ARM (Thumb2). SIMD есть и там, и там (SSE и NEON). Насчет проще оптимизировать — тоже не сказал бы: i/d caches, pipelines, out-of-order execution и хитрые правила вычисления timings and latencies — все это есть и у нынешних ARM'ов.
Тем временем, понятия производительности, энергопотребления и стоимости остаются архитектуро-независимыми и имеют право быть сравниваемыми. Так что можно абстрагироваться от архитектурных отличий, возложив все заботы по аппаратно-зависимой оптимизации на компилятор (допустим, i686-linux-gcc vs. arm-linux-gcc из одного codebase) и мерить, мерить, мерить… Мне, например, было бы очень интересно сравнить графики различных отношений MHz/MIPS/FLOPS/watt/$ и т.п. для процессоров обеих архитектур.
Да, но далеко не всегда это делается оптимальным образом. Например, если есть пропуски/повторения индексов, генерируется вспомогательная таблица и дополнительная инструкция
movzx eax, BYTE PTR $indextable[eax]
Если же используются, скажем, 30 опкодов из 32 возможных, появляется лишний условный переход
cmp eax, 29
ja $loopstart
На самом деле так сейчас все и работает. Ваш CPU, на самом деле, внутри является некой RISC машиной, а привычные x86 инструкции он эмулирует, точнее, транслирует в более простые внутренние микрокоманды. Запускаете, скажем, VirtualBox, чтоб загрузить Windows из Linux — еще один уровень эмуляции. Стартуете Java программу — JVM на лету транслирует байткод в инструкции процессора. А сама программа, вероятно, тоже что-то эмулирует :)
Это неправда. Не думаете же Вы в самом деле, что все 6800+ классов из rt.jar загружаются сразу же при старте?
Системные классы также загружаются по мере необходимости. В случаях, когда используется Class Data Sharing (-Xshare:on), некоторые классы (перечисленные в jre/lib/classlist) могут быть предзагружены путем отображения (mmap) файла classes.jsa в виртуальную память.
Кстати, 400Kb многовато для такой программки. Тут, вот, народ недавно в 10K игрушки прикольные умещал!
За это время некоторые слова успели показаться раз по пять.
И ооочень долго из-за баннеров грузится такая простая страница.
s = new String(s.substring(1, 2));
Увеличение производительности со временем — результат именно сбора статистики и рекомпиляции методов.
measureArray(new SimpleArray());
measureArray(new ArrayListArray());
и померите заново. Ну как? :-)
Забавно, что результат на самом деле зависит не от реализации, а от порядка строк.
Тем не менее, это вполне ожидаемо, если понимать, как работает HotSpot.
Вы только что написали бенчмарку, про которую в свое время Dr. Cliff Click рассказывал в своей презентации «How NOT to write a Microbenchmark».
StringBuilder tmp = new StringBuilder();
tmp.append(str);
tmp.append(word);
str = tmp.toString();
а каждый append() — это вызов System.arraycopy(), вдобавок toString() — еще один arraycopy() на всю длину буфера.
Соответственно, если строка str длиной 100000 символов, а word длиной 5 символов, то str += word должен будет выполнить копирование как минимум 200010 символов, в то время как builder.append(word) скопирует, как правило, только 5 символов. Почувствуйте разницу :) Хороший эксперимент, наглядный результат.
Описка, я так понимаю. StringBuffer — для многопоточности, StringBuilder — для скорости.
А что, неплохое соревнование по программированию получается — кто быстрей и лучше бота напишет :)
Делить языки программирования на компиляторы и интерпретаторы — все равно, что человеческие языки делить на те, на которых говорят и те, на которых пишут. Бред. Компиляторы и интерпретаторы — это виды трансляторов. С одного языка может быть много разных трансляторов. С той же Java: gcj умеет компилировать Java-программу сразу в нативный код.
Очевидно лишь то, что Вы плохо разбираетесь в том, о чем пишете. Известно, что DAC (dynamic adaptive compiler, разновидность JIT), коим обладает JVM, способен порождать более оптимальный нативный код, нежели чем статический ahead-of-time компилятор для C++ или любого другого языка. Дело в том, что во время исполнения программы компилятору известно гораздо больше о платформе и о runtime окружении. Вот лишь некоторые из оптимизаций, недоступных C++ компиляторам, которые делает JVM в runtime: девиртуализация (замена виртуальных вызовов на статические), динамическая профиляция (ипользования информации о том, какие ветки исполняются чаще), использование архитектурных особенностей процессора, на котором в данный момент исполняется программа (SSE, NUMA и т.п.)
Короче говоря, прежде чем писать об интерпретаторах, изучите предмет. Говорить об интерпретации Javascript, PHP, Perl, Python, Java и даже не упомянуть о понятии виртуальной машины… На кого бы ни была рассчитана статья, она по меньшей мере просто бесполезна, и, более того, не соответствует действительности.
Пусть и не consumer device, но продается же! :)
> Только что-то не припомню, есть ли сейчас хоть одно устройство с ним
Есть. Использую на работе девайс такой :) Процессор — NVIDIA Tegra 2.
Тем временем, понятия производительности, энергопотребления и стоимости остаются архитектуро-независимыми и имеют право быть сравниваемыми. Так что можно абстрагироваться от архитектурных отличий, возложив все заботы по аппаратно-зависимой оптимизации на компилятор (допустим, i686-linux-gcc vs. arm-linux-gcc из одного codebase) и мерить, мерить, мерить… Мне, например, было бы очень интересно сравнить графики различных отношений MHz/MIPS/FLOPS/watt/$ и т.п. для процессоров обеих архитектур.
movzx eax, BYTE PTR $indextable[eax]
Если же используются, скажем, 30 опкодов из 32 возможных, появляется лишний условный переход
cmp eax, 29
ja $loopstart