roboforum.ru

Grem писал(а):Итого 176/54=3,259, т.е. в 3 с четвертью раза медленнее эта "штатная штука", которой грех не воспользоваться. Вот и неэффективность вылезла.

Всегда радовало это "Ваша операция вызываемая раз в году и занимающая 1/1000 секунды в 3 раза медленней, чем моя!"

Michael_K писал(а):Хватит парня учить кодить - пусть учится программировать.
Такую функцию писать - десять минут.

Пожалуйста научите, с радостью послушаю. У меня вопрос по поводу функции itoa, её нет в библиотеке cvavr, если её скопировать из другой версии СИ она будет работать?

Вреальном железном мире "скопировать" часто не работает. Вы ее понять пробовали, прежде чем копировать?

loid писал(а):

Michael_K писал(а):Хватит парня учить кодить - пусть учится программировать.
Такую функцию писать - десять минут.

Пожалуйста научите, с радостью послушаю. У меня вопрос по поводу функции itoa, её нет в библиотеке cvavr, если её скопировать из другой версии СИ она будет работать?

попробуй ф-цию sprintf .... с параметром "%d"

хм и не одного предложения по разрядного вычитания...

Angel71 писал(а):компилятор, цикл (как сам в общем, так и в частностях), железо, софт, время

1, 2, 3, 4 - да, и в правду, пока первый цикл закончился - поменялась JVM, конфигурация ноута, но вот софт тут причем? Или если я WoW удалю, то разницы нифига не будет?
Время в каком смысле? Днем разницы уже не будет? Или утром наоборот, разница возрастет?
В общем бред, а не признаки. Всегда и все так замеряли время, а тут вы р-раз и всё - нельзя теперь так. Да, немного не точно, но опять же немного.

Всегда радовало это "Ваша операция вызываемая раз в году и занимающая 1/1000 секунды в 3 раза медленней, чем моя!

Если вы используете конкатенацию раз в году, то я искренне за вас рад, а вот когда будут формироваться SQL запросы по 5-10мс... в общем смеется тот, кто смеется последний с премией, а не в очереди на собеседование.
на этом мой флуд здесь заканчивается

Нет не пробовал. Я в СИ можно сказать начинающий. Многого не знаю.

ALHIMIK писал(а):хм и не одного предложения по разрядного вычитания...

зачем изобретать лисапед ?....хотя все зависит от возможностей

Romikgy писал(а):попробуй ф-цию sprintf .... с параметром "%d"

Во, нашелся разумный человек Я ручками переводил число в строку только когда писал для 2313, а для атмеги пользовался sprintf. Не знаю как в cvavr, а в arv-libc подключение sprintf отъедает пару килобайт флешки, но один раз, дальше можно пользоваться функцией сколько угодно.

Grem писал(а):Если вы используете конкатенацию раз в году, то я искренне за вас рад, а вот когда будут формироваться SQL запросы по 5-10мс...

Только сравнивать тогда надо будет "age="+xInt с "age="+Integer.toString(xInt), не так ли?
И это не избавляет от принципа "оптимизируй то, что работает часто, а не всё подряд"

А вообще напечатать uint забив на производительность можно алгоритмом а-ля:

Код: Выделить всё • Развернуть

uint val=548;
String res="";
if(val){
  while(val){
    res=(char)(val%10)+res;
    val=val/10;
  };
}else{
  res="0";
};

> когда будут формироваться SQL запросы
Конкатенация Int'ов с SQL? Вставка параметров напрямик?
У вас, там что, в джабе, нет шаблонов для SQL?

Решите другую задачу.
Дано число (125).
Выведите на экран цифры которые составляют это число в следующем формате:
'one', 'two', 'five'

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 в фоне что-то выполняется, ... если вы не заметили, в фоне всегда что-то проц грузит. и ничего, кроме внесения погрешностей в "миллисекундных" тестах это не приносит.
П.С. и ни немного неточно, а очень неточно и громадными такими "поправками на ветер".

itoa в Кодевижине есть.
прицепи stdlib.h к проекту.