2Grem
признаки/факторы/пункты/... называйте как хотите. вам намек был на самостоятельно изучение направлений, по которым у вас почти нулевые познания в ключе данного вопроса. спешил хотяб полтора часика поспать перед отъездом, похоже слишком лаконично ответил. лады, исправляюсь.
самая большая проблема в вашем тесте - время. т.е. длительность теста (не забывая, что ява вообще не самая идеальная штука для микротестов, по крайней мере до того, как будет изучен сгенерированный компилятором код), а не сарказм в виде времени суток. его явно недостаточно чтоб вообще о чём либо утверждать. увеличив время теста на порядки, можно почти до максимума увеличить точность и спокойно "забить" на всё остальное. а абсолютно точные данные имхо вообще нереально получить (да и глупо это делать для таких вещей). а все, не все... от того, что я быстренько и не понимая нюансов слабаю скрипку, не поможет избежать того, что первый попавшийся музыкант явно захочет разбить это недоразумение об чью-то голову. так и у вас - цикл есть, понимания нет.
Grem писал(а):
1, 2, 3, 4 - да, и в правду, пока первый цикл закончился - поменялась JVM, конфигурация ноута
сами взялись утверждать, что "в 3 раза" это "вообще, всегда и везде".
вполне реально, что в других условиях данные будут прямо противоположные и/или на порядки отличаться. в общем случае, один только выбор jit`а, между c1 и c2 может переворачивать всё с ног на голову. это не забывая о том, что сами данные иногда могут влиять на скорость работы алгоритма и чтоб понять, влияет ли в данном случае, нужно разбираться в коде этих 2х реализаций. самих алгоритмов преобразования числа в строку тоже немало, кто сказал, что в другой версии jvm алгоритм будет такой-же?
следующий момент, эт железо. нюанс с точностью и разрешающей способностью таймеров/счётчиков (системного таймера, часы реального времени, регистр счётчик-время,...) на конкретной железке имхо можно забыть, не настолько маленькие интервалы. даже можно забыть, что точность таймера и точность получаемых данных это далеко не одно и тоже. а вот архитектура процессора в виде всяких предсказаний ветвлений, предвыборки данных и инструкций, блоков организации внеочередного и повторного исполнения, кеша, ... кто вам сказал, что jit способен всегда и из любого куска кода создавать машинный код, который будет эффективно выполняться на конкретно взятом проце? современные jit`ы генерируют в общем очень эффективный код, но это в общем, в частностях бывает всё очень печально.
в случае с профилем c1 (очень похоже, что в данном случае именно c1) много требовать явно не стоит - очень поверхностная оптимизация. а так, у другого чел-ка, с другими настройками или другой версией явы легко и непринуждённо может быть произведена и более агрессивная оптимизация кода. очень сложно гарантировать, что цикл не будет преобразован во что-то на подобии
Код:
int i = 999999;
String xStr = "" + xInt;
или в
Код:
int i = 999999;
String xStr = Integer.toString(xInt);
или в
Код:
int i = 999999;
String xStr = "126";
я не за конкретно этот кусок кода, а в общем. ваш код с циклами врядли в подобное преобразует, более вероятно, что при агрессивной оптимизации просто выкинет эти циклы. но гарантировать, что на различных версиях и с различными настройками, всегда всё будет именно так как вы себе понапридумывали и понатестили... анриал. как говориться, небольшой тюнинг настроек и тест легко может начать выдавать диаметрально противоположные данные.
ещё есть момент с различными типами компиляции - синхронный и параллельный. последний в свою очередь, в купе со всякими сборщиками мусора и некоторыми особенностями многозадачности в операционках, тем более на слабом проце (или на ноутовских процах со всевозможными приколами, предназначенных для снижения энергопотребления) вполне может объяснить даже такие тайминги и при выкинутом куске кода с циклами. есть еще такая не всегда приятная штука, как семплирование. и т.д. и т.п. читайте тематическую доку и вникайте. очень доходчиво многие вещи описаны у касперского. по яве полезно заглядывать в jls. так же предостаточно талмутов по оптимизации программ на яве, в некоторых очень подробно рассматриваются вопросы оптимизации, производимые компилятором и проблемы микротестирования. ...
а wow можете смело удалить, он похоже реально кому-то мешает. вам даже в голову не пришло (или пришло, но решили сарказмом пострадать?), что софт в данном контексте это в первую очередь ОС, с её многочисленными тонкостями (потоки, квантование, планировщики, приоритеты, переключение контекста, ...) и всеми исполняемыми во время теста процессами (счёт идёт как минимум на десятки, а иногда и на сотни. и хз, какой, когда и насколько повлияет на тест). масенькое обращение к диску, мышкой дёрнули, в jre в фоне что-то выполняется, ... если вы не заметили, в фоне всегда что-то проц грузит. и ничего, кроме внесения погрешностей в "миллисекундных" тестах это не приносит.
П.С. и ни немного неточно, а очень неточно и громадными такими "поправками на ветер".
Вход
Регистрация
FAQ
Поиск
Я ручками переводил число в строку только когда писал для 2313, а для атмеги пользовался sprintf. Не знаю как в cvavr, а в arv-libc подключение sprintf отъедает пару килобайт флешки, но один раз, дальше можно пользоваться функцией сколько угодно.
