Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 216
не обязательно UI. В Java любой экземпляр любого класса имеет hashCode, для вычисления которого используется и генератор случайных чисел.
Ну или взять карты гугла — они кешируются и для каждого скачанного куска используется случайное имя, например.
Если посмотреть что внутри, выяснится что генератор случайных чисел очень много где используется, как бы странно это не казалось непрограммистам.
Ну или взять карты гугла — они кешируются и для каждого скачанного куска используется случайное имя, например.
Если посмотреть что внутри, выяснится что генератор случайных чисел очень много где используется, как бы странно это не казалось непрограммистам.
он может использоваться в зависимости от реализации виртуальной машины, см. ссылку. Хотя может и не использоваться. Как я сказал, генератор случайных чисел используется много где, необязательно в одном месте проблема.
значит надо лучше искать:
и далее по ссылкам.
В любом случае это просто пример применения случайных чисел. Один пример из множества возможных внутри Андроида. Чтоб не удивлялись.
There's no requirement that hash values be consistent between different Java implementations, or even between different execution runs of the same program, and while two unequal objects having different hashes is very desirable, this is not mandatory (that is, the hash function implemented need not be a perfect и далее по ссылкам.
В любом случае это просто пример применения случайных чисел. Один пример из множества возможных внутри Андроида. Чтоб не удивлялись.
Вы путаете, во всех примерах просто говорится о том, что сериализовывать значения хеш-кодов — это «айяйяй». При этом случайные числа непосредственно при вычислении хеш-кодов использоваться не могут, иначе бы хеш коды не имели бы смысла.
хватит спорить не о чём. По ссылке ясно сказано что в ряде случаев для вычисления хеша используется случайное число (можно опротестовать статью в вики, если уж неймётся). Так это или не так конкретно в Андроиде неизвестно, наряду с этим есть ещё масса вариантов испоьзования случайных чисел и в UI, и в гугловых картах, и в других местах.
В вики ничего про случайные числа не написано. Даже сказано наоборот, что никаких случаных вариаций быть не может. Два одинаковых объекта обязаны иметь одинаковый хеш-код.
Тут момент принципиальный, потому что случайное число при вычислении хеша — это очень большая глупость и не дай случай кто-нибудь увидит ваш камент и решит что так можно делать.
Тут момент принципиальный, потому что случайное число при вычислении хеша — это очень большая глупость и не дай случай кто-нибудь увидит ваш камент и решит что так можно делать.
млять, носом тя тыкал, кусок вырезал со ссылкой
Тот же подсоленный хеш встречается часто и всегда различается для одинаковых экземпляров (обычно паролей)
нет, млять, одно и то же оффтопить будет.
Хватит. Это просто пример чтоб не удивлялись.
A perfect hash function for a specific set S that can be evaluated in constant time, and with values in a small range, can be found by a randomized algorithm in a number of operations that is proportional to the size of SТот же подсоленный хеш встречается часто и всегда различается для одинаковых экземпляров (обычно паролей)
нет, млять, одно и то же оффтопить будет.
Хватит. Это просто пример чтоб не удивлялись.
Во первых — кто вы такой, чтобы грубить тут?
Во вторых, подсоленный хеш, равно как и криптографический хеш — это мало относящиеся к get_hash_code() вещи. Хеши, используемые в описанном случае никто никогда не будет делать солеными или криптостойкими.
И более того, в цитате написано что идеальная хеш-функция может быть найдена путем рандомизированного алгоритма, а не само хеш-значение.
Во вторых, подсоленный хеш, равно как и криптографический хеш — это мало относящиеся к get_hash_code() вещи. Хеши, используемые в описанном случае никто никогда не будет делать солеными или криптостойкими.
И более того, в цитате написано что идеальная хеш-функция может быть найдена путем рандомизированного алгоритма, а не само хеш-значение.
Ну раз вы такой умный, киньте кусочек исходного кода из пакета java.lang, где используется Random в hashCode().
А вот второе соглашение функции hashCode()
И как вы себе представляете идентичный хэшкод у разных, но эквивалентных объектов, если предлагаете использовать Random в hashCode()?
А вот второе соглашение функции hashCode()
If two objects are equal according to the {code equals(Object)} method, then calling the {code hashCode} method on each of the two objects must produce the same integer result.
И как вы себе представляете идентичный хэшкод у разных, но эквивалентных объектов, если предлагаете использовать Random в hashCode()?
Ну раз вы такой умный, киньте кусочек исходного кода из пакета java.lang, где используется Random в hashCode().Отвечу в поддержку SSSurkv:
hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/runtime/synchronizer.cpp, стр. 537.
Этот код выполняется при вызове Object.hashCode() и System.identityHashCode() в HotSpot JVM.
Поправьте меня, пожалуйста, но я понял этот отрывок так: разумеется, при вычислении хеша никакая монетка не подбрасывается. Но в ходе инициализации виртуальной машины Java, например, или, что менее вероятно, при загрузке соответствующего стандартного класса в процессе конкретной программы, случайным образом выставляются некоторые из констант, использующиеся в хеш-функциях. В течение работы программы они, конечно, не меняются. Но от запуска к запуску могут различаться. «Могут» — значит, стандарты платформы не требуют обратного. Как на деле — who knows.
Именно ГСЧ и используется в HotSpot для вычисления hashCode в первый раз на объекте (см. synchronizer.cpp, стр. 537).
А какой бы вы предложили вариант для вычисления identityHashCode без ГСЧ?
Популярное заблуждение — использовать адрес объекта — не подходит по ряду причин: адрес объекта изменяется во время GC, кроме того, выделяемые подряд объекты будут иметь последовательные хеш-коды.
А какой бы вы предложили вариант для вычисления identityHashCode без ГСЧ?
Популярное заблуждение — использовать адрес объекта — не подходит по ряду причин: адрес объекта изменяется во время GC, кроме того, выделяемые подряд объекты будут иметь последовательные хеш-коды.
А зачем сохранять скачанные тайлы под случайными именами? Лучше использовать хэш от широты, долготы, зума и версии тайлсета.
Заминусовали очень правильный комментарий!
Если Dalvik VM в качестве Object.hashCode() использует адрес объекта, то всем известный HotSpot совершенно точно для первого вычисления hashCode объекта использует random (см. стр. 537). Далее полученное число сохраняется в заголовке объекта для последующих вызовов hashCode.
Если Dalvik VM в качестве Object.hashCode() использует адрес объекта, то всем известный HotSpot совершенно точно для первого вычисления hashCode объекта использует random (см. стр. 537). Далее полученное число сохраняется в заголовке объекта для последующих вызовов hashCode.
Видимо, имеется ввиду код, который выполняется в UI-потоке. А там уже что хочешь пишут. Правда никак не верится, что лаги интерфейса возникают из-за истощения пула случайных чисел, и этой проблемы не решили раньше. Проверил дату — не, не 1 апреля…
Как-то на первом курсе тестировал классический квиксорт (C++), быстрее всего работает, если в качестве граничного элемента выбирать середину, а вызов rand() все несколько замедлял. Это на нормально распределенных числах, на частично упорядоченных не тестировал. Так, к слову, явно не исследование.
template <class T> void QuickSort(T x[], long a, long b, bool (*f)(T,T))
{
long i = a, j = b;
T temp, p = x[b/2]; //выбираем граничный элемент - середину
//p = x[i]; //выбираем первый элемент (5000000 эл. за 1980 мс)
//p = x[i+rand()%N-i]; //выбираем случайный элемент (5000000 эл. за 2120 мс)
do {
while ( f(x[i],p) ) ++i;
while ( f(p,x[j]) ) --j;
if (i <= j) { temp = x[i]; x[i++] = x[j]; x[j--] = temp; }
} while (i <= j);
if( j > 0 ) QuickSort(x, a, j, f);
if( b > i ) QuickSort(x+i, a, b-i, f);
}
Network: FreeNode
Main IRC Server: irc.freenode.net
Port: 6667
Room: #Habra
UTF-8
irc://irc.freenode.net:6667/habra
Заходите в чатик, будем обсуждать!
Main IRC Server: irc.freenode.net
Port: 6667
Room: #Habra
UTF-8
irc://irc.freenode.net:6667/habra
Заходите в чатик, будем обсуждать!
такие фейлы Гугл не красят.
410 — Gone
Кто успел сказать, залейте, пожалуйста, куда-нибудь в другое место!
Кто успел сказать, залейте, пожалуйста, куда-нибудь в другое место!
Статья тянет на первое апреля))
Не верится что то. Неужели никто, включая гугл не прогоняли код через профайлер, где такие лаги были бы видны?! Да и выше сказали правильно, зачем UI генератор случайных чисел? Может быть там что то типа :)
if model_price<500: ui.makeLag(lag_time=random(1,1000)
if model_price<500: ui.makeLag(lag_time=random(1,1000)
Эм… они, фактически, заменили /dev/urandom на /dev/random?
Так тут и нет ничего удивительного, что псевдослучайный генератор быстрее «менее псевдо» случайного. Хотя, как это касалось графического интерфейса, вообще непонятно, разве что, при безопасном соединении.
И интересно, повлияло ли это на приложения, которые (u)random вообще не дёргают.
Так тут и нет ничего удивительного, что псевдослучайный генератор быстрее «менее псевдо» случайного. Хотя, как это касалось графического интерфейса, вообще непонятно, разве что, при безопасном соединении.
И интересно, повлияло ли это на приложения, которые (u)random вообще не дёргают.
См. ниже habrahabr.ru/post/164881/#comment_5678555 у меня на десктопе разница в 2-5 раз между ними (/dev/random выдает около 3мб в секунду), на телефоне все намного печальнее.
Как пишут в обзоре pocket now:
Они сделали этот вывод основываясь на словах:
В кратце: ощущение что всё работает «быстрее» создаётся от того, что телефон не переходит в режимы пониженной производительности (процессор работает на максимальной частоте). И рандом к этому отношения не имеет.
But does it work? Ironically, the answer is yes — but probably not for the reason that the developer intended to solve. In our tests Chrome was snappier and Google Maps was much quicker drawing tiles. Why? Probably not because the entropy pool was any quicker, but because the CPU and I/O processes were being “kept hot” by the app constantly updating the system with the new, “less random” bits. In short, the CPU wasn’t returning to a slower speed as frequently, resulting in a faster experience — and shorter battery life.
Они сделали этот вывод основываясь на словах:
CyanogenMod maintainer chimed in:
“IMNSHO the recent entropy pool fad is bull***. The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random.
“The only conceivable reason some devices may feel faster is because by constantly polling the PRNG, it keeps the device’s I/O in constant use (which in turn, depending on device, will make the CPU stick to higher clock frequencies to keep up and/or ramp up the IO scheduler).”
В кратце: ощущение что всё работает «быстрее» создаётся от того, что телефон не переходит в режимы пониженной производительности (процессор работает на максимальной частоте). И рандом к этому отношения не имеет.
Может скажу бред (на самом деле нет), но то, что смартфон не уходит в дипслип, работает на макс. частоте — бред. Ничего такого не наблюдаю. Установлен Seeder посредством раскидывания файлов апдейта для рекавери в папку /system/ с установкой соответствующих прав.
В терминале работа отображается.
Правда при попытке выключить через терминал все равно отображается статус работы: On. Глюк?
В терминале работа отображается.
Правда при попытке выключить через терминал все равно отображается статус работы: On. Глюк?
дело не в дипслипе, а в понижении частоты. Если стоит governor в режиме «conservative», то устройство стремиться каждый раз скинуть частоту CPU до минимума (66-133 мгц).
почитать можно например тут:
wiki.archlinux.org/index.php/CPU_Frequency_Scaling#Scaling_governors
почитать можно например тут:
wiki.archlinux.org/index.php/CPU_Frequency_Scaling#Scaling_governors
Первая мысль была именно такая же. Что просто процу не дает замедлиться, раз делает что-то каждую секунду.
hmm, у меня вот sony lww с cm10nightly и extended kernel (то, что с андервольтом всего и вся). Поставил в настройках частоту в 1ггц минимальную и максимальную (чтобы не понижалась, значит!) и проверил гугл мэпс с сидером и без сидера. С сидером работает объективно быстрее! Оо
На мойм андроиде заканчиваются случайные числа?!!! Надо срочно скачать про запас!
О, да.
lwn.net/Articles/525459/
Ждём новый CVE-2008-0166, теперь на андроиде.
lwn.net/Articles/525459/
One thing you should not do is the following:
rngd -r /dev/urandom
Ждём новый CVE-2008-0166, теперь на андроиде.
Попробовавшие, отзовитесь!
Надеюсь, вы не заняты оживлением брикнувшихся аппаратов :)
Надеюсь, вы не заняты оживлением брикнувшихся аппаратов :)
Попробовал на Galaxy SII, визуально ничего не изменилось. Вроде и до этого тормозов не было, чего я полез :) (прям как в анекдоте про медведя, который все равно читать не умел).
Пока оставлю, посмотрим еще.
Пока оставлю, посмотрим еще.
Попробовал. Работает заметно быстрее. Выше в комментариях, есть предположение, что совсем по другой причине. Теперь нужно тестировать время жизни батареи…
Motorola RAZR XT910 4.0 custom rom
Не заметил преимуществ. Как лагало, так и продолжает
Не заметил преимуществ. Как лагало, так и продолжает
Поставил на китайский планшет Ainol Novo 7 Aurora II, вроде все по прежнему, лагов у меня и до этого особых не было, после установки проги улучшений особых тоже не заметил…
Nexus S, CM 10.1 особых изменений не заметил. Действительно прога просто будит проц.
Аппарат: LG Optimus Hub (ARMv6), кастомная CM10.
Субъективно — не изменилось ничего.
Результаты квадрант-бенчмарка:
1. Контрольный (до установки Seeder): i.imgur.com/9Yx56.png
2. После установки при включенном Seeder: i.imgur.com/q3zJ6.png
3. После установки при отключенном Seeder: i.imgur.com/Q0sZK.png
Коротко: на моем телефоне Seeder приводит к понижению производительности.
P. S. Бенчмарк запускался после перезагрузки телефона init-скриптом с предварительным слипом в 120 секунд (дабы успели прогрузиться все приложения и виджеты), то есть влияние внешних факторов уменьшил, насколько было возможно.
Субъективно — не изменилось ничего.
Результаты квадрант-бенчмарка:
1. Контрольный (до установки Seeder): i.imgur.com/9Yx56.png
2. После установки при включенном Seeder: i.imgur.com/q3zJ6.png
3. После установки при отключенном Seeder: i.imgur.com/Q0sZK.png
Коротко: на моем телефоне Seeder приводит к понижению производительности.
P. S. Бенчмарк запускался после перезагрузки телефона init-скриптом с предварительным слипом в 120 секунд (дабы успели прогрузиться все приложения и виджеты), то есть влияние внешних факторов уменьшил, насколько было возможно.
Приятно удивлен, как мой почти умерший Motorolla XT-720 перестал по 10-15 сек. отрисовывать меню с приложениями. Безмерно рад, что моим кирпичом можно снова пользоваться, хотел было выкидывать.
Старенький Samsung Galaxy S. В последнее время просто измучили постоянные подвисания на 10-15 секунд. После установки подвисания пропали.
У меня тоже SGS, но никаких подвисаний нет, и установка программы не привела ни к каким видимым изменениям. Тестировал по-разному, в том числе ставил Check Random Entropy Available, но у меня значение никогда не падало до 0, всегда выше 100.
Версия Android 2.3.3, прошивка на основе стоковой, не перепрошивался более 1,5 лет. Правда, пару месяцев назад удалил весь софт, кроме того, которым регулярно пользуюсь, это привело к увеличению свободной оперативной памяти, что положительно сказалось на многозадачности.
Версия Android 2.3.3, прошивка на основе стоковой, не перепрошивался более 1,5 лет. Правда, пару месяцев назад удалил весь софт, кроме того, которым регулярно пользуюсь, это привело к увеличению свободной оперативной памяти, что положительно сказалось на многозадачности.
CM10 вливает новую жизнь в SGS.
Нет, правда, сегодня же не первое апреля… ЗАЧЕМ им случайные числа для UI??? Есть кто нибудь на Хабре, кто может внятно ответить на этот вопрос?
Ну может ГСЧ нужен для GC или самой Dalvik. Хотя звучит все это довольно странно, если не сказать смешно.
Боги, как тогда решать вопросы коллизий?
инкрементальный счетчик не подойдет для этого?
Вряд ли. Можно выйти за границы типов. Элементы создаются и уничтожаются постоянно, а количество одновременно существующих идентификаторов несравнимо меньше теоретически возможного количества.
Если использовать random, то 32 разрядами точно не обойтись, чтобы небыло коллизий, а 64 разряда хватит для любого автоинкремента.
Приложения, как и устройства, могут работать годами не выключаясь. Коллизии можно избежать простой проверкой занятости пида в текущий момент времени и освобождённые идентификаторы вполне могут использоваться вновь. Таким образом, даже теоретического предела по продолжительности работы не будет.
А смысл делать рандом, огребая проблем с перевыбором id в случае коллизии (а это еще какая проблема, когда пространство значений начнет заполняться) + надо отслеживать какие id живые, какие нет, вести эти таблицы. Это совершенно необоснованная сложность и performance hit, когда 64 битного счетчика хватит за глаза.
int128. Или int256. Его уж точно хватит на время существования Вселенной:)
А так?
i = (i + 1) % MAXI
Это очень плохой подход, при переполнении может вполне оказаться что один из самых старых айдишников еще жив, и тогда два объекта будут иметь одинаковый id. Отслеживать это и предотвращать — не так тривиально. Поэтому лучше 64bit счетчик.
Ой. Пошёл посыпать голову пеплом. Я не знаю, что происходит под Java при переполнении интегрального типа. На C такой код будет выглядеть, скорее, как попытка пояснить — переполнение вполне ожидаемое событие. Так-то оно само по модулю тикает, только unsigned ставь.
Может какие то проги используют random для генерации текстур на-лету? Вот вроде бы сейчас модно «шумок» добавлять на гладкие поверхности. Или, как в недавнем посте — бесконечный лабиринт с помощью бэйсика и рандома )
Ерунда правда, но что то другое в голову не приходит.
Ерунда правда, но что то другое в голову не приходит.
Я правильно понимаю, что все установившие эту чудо–приблуду теперь вместо «честного» генератора случайных чисел /dev/random получают ещё один быстрый алгоритмический генератор псевдослучайности (каковым является /dev/urandom).
И поскольку алгоритмические генераторы потенциально предсказуемы, с пропатченных таким образом андроидов гораздо менее секьюрно пользоваться тем же https?
И поскольку алгоритмические генераторы потенциально предсказуемы, с пропатченных таким образом андроидов гораздо менее секьюрно пользоваться тем же https?
получают ещё один быстрый алгоритмический генератор псевдослучайности
Не «ещё один быстрый», /dev/random начинает работать так же, как и /dev/urandom, поскольку его входной пул теперь никогда не исчерпается.
с пропатченных таким образом андроидов гораздо менее секьюрно пользоваться тем же https
Не «гораздо менее секьюрно», потому что использованные в ядре алгоритмические генераторы всё-таки криптостойкие (на случай сбоев/преднамеренной слабости аппаратных генераторов энтропии).
Шаманство в канун Рождества какое-то.
На HTC Desire команда dd if=/dev/random of=/dev/null bs=128 count=1 выдала 82000 байт в секунду, count=10 не дождался выполнения, сбросил через 25 секунд — к тому моменту выдало только 8 байт. Повторный запуск с count=1 тоже не дождался, срубил, опять 8 байт за 30 секунд.
С /dev/urandom постоянно over9000 байт, т.е. если что-то много юзает ГСЧ, то, по крайней мере на desire, прога может немного ускорить.
С /dev/urandom постоянно over9000 байт, т.е. если что-то много юзает ГСЧ, то, по крайней мере на desire, прога может немного ускорить.
Интересно было бы найти программу/патч, которая буфер увеличивает этих самых случайных чисел. А то 128 байт (или сколько там, надо курить, а мне скрипты ваять лень) — при генерации 8 байт в пол минуты — даже не смешно…
А как проверить? У меня Anroid Terminal говорит что не может писать в /dev/null (рутован 4.0.X)
Samsung Captivate команда
После небольшого перерыва запустил Оперу и Яндекс.Карты, после этого команда выдала больше 85 байт/секунду, значит запуск этих приложений буфер /dev/random не опустошил. На чём бы ещё проверить?
dd if=/dev/random of=/dev/null bs=128 count=11 при первом вызове выдала 85 байт в секунду, передала 481 байт за 5,628 секунд. Следующие вызовы уже показывали скорость 12 байт в секунду.После небольшого перерыва запустил Оперу и Яндекс.Карты, после этого команда выдала больше 85 байт/секунду, значит запуск этих приложений буфер /dev/random не опустошил. На чём бы ещё проверить?
Отличная идея с тестом, но о нём немного позже.
Опытным путём выяснил, что у меня размер буфера для /dev/random равен где-то 416 байтам. То есть, если буфер полный и из него считать 416 байт, то они возвращаются «мгновенно», всё что больше читается со скоростью примерно 12 байт/с.
Также заметил, что dd по видимому имеет таймаут на чтение блока, если запросить достаточно большой блок, например, размером в 26 байт, и он не будет считан за отведённое время, то возвращаются лишь считанные байты. Например, запрашиваю чтение 20 блоков по 26 байт, реально читается 451 байт вместо 20 * 26 = 520, при этом 16 блоков (416 байт) читаются полностью и 4 частично.
Благодаря этим особенностям можно отслеживать используют ли приложения /dev/random или нет. Если приложение использует /dev/random, то в течении 416 / 12 ~ 34 секунд после активного использования /dev/random его буфер заполнен не полностью, и попытка чтения 16 блоков по 26 байт в течении этого времени вернёт не 16 полных блоков, а меньше, остальные блоки будут прочитаны лишь частично.
Теперь тесты.
Тест 1
Запускаю в фоне чтение большого количества случайных чисел и смотрю как это сказывается на интерфейсе. Выполняю команду:
читается 2000 байт, это примерно на (2000 — 416) / 12 ~ 132 секунды.
Проверяю скорость скроллирования в TouchWiz, скорость запуска TitaniumBackup, Opera, Play Store, Evernote, EBookDroid.
Результаты (время считал сам, рассчитывая на сильные тормоза):
TouchWiz — скролл плавный, как и всегда.
Запуск TitaniumBackup ~ 6 секунд, переключаюсь на список приложений и быстро его прокручиваю, есть небольшие остановки во время прокрутки, те самые лаги.
Opera — 8 с.
Play Store — 3 с, при навигации по интерфейсу лагов нет, прокрутка плавная.
Evernote — быстро запустился, прокрутка списка из порядка 900 заметок без лагов.
EBookDroid — 4 с, при запуске сразу открывается небольшой PDF файл.
В терминале скорость копирования командой dd: 24 байта/секунду для первого запуска команды и 17 байт/секунду. Видно, что другие приложения активно случайные числа не использовали, иначе бы скорость копирования в dd была бы ниже 12 байт/с.
Тест 2
Повторяю те же тесты что и 1-м, но без запуска dd в фоне.
TitaniumBackup ~ 4 с, переключаюсь на список приложений и быстро его прокручиваю, есть совсем небольшие остановки во время прокрутки. Вроде бы менее длительные, чем в 1-й раз, но может быть мне так кажется.
Opera — 8 с.
Play Store — 5 с, при навигации по интерфейсу лагов нет, прокрутка плавная.
Evernote — даже не стал проверять, итак быстро работал.
EBookDroid — 5 с, при запуске сразу открывается небольшой PDF файл.
Вывод, особой разницы не видно, всё в рамках погрешностей измерений, также может влиять кэширование. Только вроде быть TitaniumBackup стал реже останавливаться при первоначальной прокрутке.
Зайдём с другой стороны, если TitaniumBackup активно использует /dev/random при чтении данных о приложениях при скроллировании, то это должно сказаться на количестве данных в буфере. Проверяем:
Тест 3
Проверяю сколько остаётся случайных чисел в буфере /dev/random после запуска приложений. Порядок такой: запускаю приложение, дожидаюсь его запуска, в течении максимум 5 с переключаюсь в терминал и выполняю:
По выводу оцениваю сколько случайных байт считало приложение.
TitaniumBackup
Повторил тест несколько раз, сразу после запуска именно такие показатели (5+11). 5+11 — значит что было скопировано 5 блоков по 26 байт и 11 неполных блоков. Так как было всего передано 238 байт, а 5 * 26 = 130, то остальные 238 — 130 = 108 байт пришлись на 11 неполных блоков, примерно по 9-10 байт в блоке. Полностью скопированные блоки (130 байт) — это те, которые находились в буфере.
В буфере осталось примерно 5 * 26 = 130 байт (+ 12-36 байт уже могло быть возвращено в него системой). Значит приложение при запуске использовало минимум 416 — 130 = 286 случайных байт. Но из-за того, что они были в буфере, на скорости запуска это не сказалось. Попробовал очистить буфер /dev/random, прочитав из него всё содержимое, но скорость запуска почему-то не изменилась.
Opera
То есть при запуске ГСЧ не использовался.
EBookDroid
То есть приложение использовало примерно 130 случайных байт. Загружаю при запуске большую PDF: 5+11 records in, то есть случайных чисел использовано ещё больше, но всё равно буфера хватило.
Play Store
Evernote
OI Shopping list
Это приложение после последних обновлений начало местами тупить, решил погонять его побольше: создал список покупок, добавил продукты, удалил список, проверил буфер ГСЧ. В результате оказалось, что буфер почти пуст, было менее 3-х свободных блоков, но точные данные не записал.
Root Explorer
То есть при запуске буфер был полностью опустошен.
Проверил запуск приложения с заполненным буфером /dev/random и опустошённым, в обоих случаях Root Explorer запускается за 3 секунды.
Выводы из теста (актуально для моего телефона, с буфером ~400 байт и скоростью его наполнения 12 байт/с): теоретически, эффект от Seeder будет на приложениях, активно использующих ГСЧ или читающих существенно больше размера буфера за короткий промежуток времени. У себя я таких приложений почти не выявил, большинство читало за раз менее 416 байт, только Root Explorer и OI Shopping List читали больше. Но опять же для Root Explorer не увидел никакой разницы в скорости запуска в случаях заполненного буфера ГСЧ и опустошённого. Значит для меня скорее всего приложение окажется бесполезно, но может оказаться полезным тем, у кого небольшой буфер /dev/random или низкая скорость его наполнения.
Тест 4
Установил Seeder, погонял все те же приложения, но какого-то ускорения не заметил. Единственное, вроде бы перестал сильно тупить OI Shopping List, но это может быть эффект плацебо, потестирую его в течении следующей недели.
Опытным путём выяснил, что у меня размер буфера для /dev/random равен где-то 416 байтам. То есть, если буфер полный и из него считать 416 байт, то они возвращаются «мгновенно», всё что больше читается со скоростью примерно 12 байт/с.
Также заметил, что dd по видимому имеет таймаут на чтение блока, если запросить достаточно большой блок, например, размером в 26 байт, и он не будет считан за отведённое время, то возвращаются лишь считанные байты. Например, запрашиваю чтение 20 блоков по 26 байт, реально читается 451 байт вместо 20 * 26 = 520, при этом 16 блоков (416 байт) читаются полностью и 4 частично.
Благодаря этим особенностям можно отслеживать используют ли приложения /dev/random или нет. Если приложение использует /dev/random, то в течении 416 / 12 ~ 34 секунд после активного использования /dev/random его буфер заполнен не полностью, и попытка чтения 16 блоков по 26 байт в течении этого времени вернёт не 16 полных блоков, а меньше, остальные блоки будут прочитаны лишь частично.
Теперь тесты.
Тест 1
Запускаю в фоне чтение большого количества случайных чисел и смотрю как это сказывается на интерфейсе. Выполняю команду:
dd if=/dev/random of=/dev/null bs=1 count=2000читается 2000 байт, это примерно на (2000 — 416) / 12 ~ 132 секунды.
Проверяю скорость скроллирования в TouchWiz, скорость запуска TitaniumBackup, Opera, Play Store, Evernote, EBookDroid.
Результаты (время считал сам, рассчитывая на сильные тормоза):
TouchWiz — скролл плавный, как и всегда.
Запуск TitaniumBackup ~ 6 секунд, переключаюсь на список приложений и быстро его прокручиваю, есть небольшие остановки во время прокрутки, те самые лаги.
Opera — 8 с.
Play Store — 3 с, при навигации по интерфейсу лагов нет, прокрутка плавная.
Evernote — быстро запустился, прокрутка списка из порядка 900 заметок без лагов.
EBookDroid — 4 с, при запуске сразу открывается небольшой PDF файл.
В терминале скорость копирования командой dd: 24 байта/секунду для первого запуска команды и 17 байт/секунду. Видно, что другие приложения активно случайные числа не использовали, иначе бы скорость копирования в dd была бы ниже 12 байт/с.
Тест 2
Повторяю те же тесты что и 1-м, но без запуска dd в фоне.
TitaniumBackup ~ 4 с, переключаюсь на список приложений и быстро его прокручиваю, есть совсем небольшие остановки во время прокрутки. Вроде бы менее длительные, чем в 1-й раз, но может быть мне так кажется.
Opera — 8 с.
Play Store — 5 с, при навигации по интерфейсу лагов нет, прокрутка плавная.
Evernote — даже не стал проверять, итак быстро работал.
EBookDroid — 5 с, при запуске сразу открывается небольшой PDF файл.
Вывод, особой разницы не видно, всё в рамках погрешностей измерений, также может влиять кэширование. Только вроде быть TitaniumBackup стал реже останавливаться при первоначальной прокрутке.
Зайдём с другой стороны, если TitaniumBackup активно использует /dev/random при чтении данных о приложениях при скроллировании, то это должно сказаться на количестве данных в буфере. Проверяем:
Тест 3
Проверяю сколько остаётся случайных чисел в буфере /dev/random после запуска приложений. Порядок такой: запускаю приложение, дожидаюсь его запуска, в течении максимум 5 с переключаюсь в терминал и выполняю:
dd if=/dev/random of=/dev/null bs=26 count=16По выводу оцениваю сколько случайных байт считало приложение.
TitaniumBackup
5+11 records in 5+11 records out 238 bytes transferred in 3.228 secs (73 bytes/sec)
Повторил тест несколько раз, сразу после запуска именно такие показатели (5+11). 5+11 — значит что было скопировано 5 блоков по 26 байт и 11 неполных блоков. Так как было всего передано 238 байт, а 5 * 26 = 130, то остальные 238 — 130 = 108 байт пришлись на 11 неполных блоков, примерно по 9-10 байт в блоке. Полностью скопированные блоки (130 байт) — это те, которые находились в буфере.
В буфере осталось примерно 5 * 26 = 130 байт (+ 12-36 байт уже могло быть возвращено в него системой). Значит приложение при запуске использовало минимум 416 — 130 = 286 случайных байт. Но из-за того, что они были в буфере, на скорости запуска это не сказалось. Попробовал очистить буфер /dev/random, прочитав из него всё содержимое, но скорость запуска почему-то не изменилась.
Opera
16+0 records in 416 bytes transferred
То есть при запуске ГСЧ не использовался.
EBookDroid
11+5 records in 326 bytes transferred in 3.469 secs (93 bytes/sec)
То есть приложение использовало примерно 130 случайных байт. Загружаю при запуске большую PDF: 5+11 records in, то есть случайных чисел использовано ещё больше, но всё равно буфера хватило.
Play Store
8+8 records in 284 bytes transferred in 4.495 secs (63 bytes/sec)
Evernote
5+11 records in 223 bytes transferred in 6.038 secs (36 bytes/sec)
OI Shopping list
Это приложение после последних обновлений начало местами тупить, решил погонять его побольше: создал список покупок, добавил продукты, удалил список, проверил буфер ГСЧ. В результате оказалось, что буфер почти пуст, было менее 3-х свободных блоков, но точные данные не записал.
Root Explorer
1+15 records in 163 bytes transferred in 9.562 secs (17 bytes/sec)
То есть при запуске буфер был полностью опустошен.
Проверил запуск приложения с заполненным буфером /dev/random и опустошённым, в обоих случаях Root Explorer запускается за 3 секунды.
Выводы из теста (актуально для моего телефона, с буфером ~400 байт и скоростью его наполнения 12 байт/с): теоретически, эффект от Seeder будет на приложениях, активно использующих ГСЧ или читающих существенно больше размера буфера за короткий промежуток времени. У себя я таких приложений почти не выявил, большинство читало за раз менее 416 байт, только Root Explorer и OI Shopping List читали больше. Но опять же для Root Explorer не увидел никакой разницы в скорости запуска в случаях заполненного буфера ГСЧ и опустошённого. Значит для меня скорее всего приложение окажется бесполезно, но может оказаться полезным тем, у кого небольшой буфер /dev/random или низкая скорость его наполнения.
Тест 4
Установил Seeder, погонял все те же приложения, но какого-то ускорения не заметил. Единственное, вроде бы перестал сильно тупить OI Shopping List, но это может быть эффект плацебо, потестирую его в течении следующей недели.
Блин, Вам надо было уже топик писать!
Но вообще я сильно удивлен, что так много приложений ГСЧ используют…
Но вообще я сильно удивлен, что так много приложений ГСЧ используют…
Очень странно. Если разработчики VM говорят, что /dev/random не используется, а у сторонних программ нет к нему доступа в обход VM, то как тогда они опустошают буфер? Или все эти программы требуют рута, и сами лезут куда хотят?
Наверное, приложение само или через VM пользуется системными сервисами, которые обращаются к ГСЧ. Например, приложение имеет права на включение/выключение Wi-Fi, при включении будет обращение к ГСЧ, но при этом ни само приложение, ни VM к ГСЧ обращаться не будут, это сделает драйвер Wi-Fi.
я вас возможно удивлю, но не только при включении, а и при работе — например шифровании WPA2, я уж не говорю про https и т.д.
Не удивите :), я лишь привёл пример, для которого проводил тест на обращение к /dev/random.
Попробуйте по wifi с wpa и по https что-нибудь, открывающее много соединений. ну и да, dd в фоне оставьте.
Что-то ничего в голову не приходит. Может быть подскажете юзкейс?
Выше ответил про отзывчивость приложений, обратите внимание на Root Explorer, хоть при его запуске активно используется ГСЧ, но dd в фоне на скорость запуска не влияет.
Выше ответил про отзывчивость приложений, обратите внимание на Root Explorer, хоть при его запуске активно используется ГСЧ, но dd в фоне на скорость запуска не влияет.
Выключил, включил Wi-Fi, сразу после этого выполнил:
То есть видно, что буфер /dev/random был исчёрпан.
Но в таком же тесте команда
При этом не вижу разницы в скорости установки Wi-Fi соединения при включённом и отключённом Seeder.
# dd if=/dev/random of=/dev/null bs=26 count=16 0+16 records in 0+16 records out 140 bytes transferred in 7.447 secs (18 bytes/sec)
То есть видно, что буфер /dev/random был исчёрпан.
Но в таком же тесте команда
watch -n 1 cat /proc/sys/kernel/random/entropy_avail стабильно показывала значения из диапазона 120-140.При этом не вижу разницы в скорости установки Wi-Fi соединения при включённом и отключённом Seeder.
Sony Xperia Pro (Android 4.0.4) субъективно стал заметно плавнее. Но самое забавное, что HTC Desire Z, прошитый на Ice Cream SENSEwich 2.0 (Android 4.0.4, HTC Sense 4.1), который неимоверно тупил, как думалось — из-за объема памяти, стал просто летать. Теперь Paranoic Mode = On, оказывается, не надо приобретать флагман, для того чтобы получить одну из последних версий ОС, т.к., оказывается, быстрый Android ≠ мощное железо.
Хм, неужели это позволило Desire Z наконец приемлемо работать на прошивках с ICS? Сколько раз ни ставил, постоянные тормоза заставляли с сожалением вернуться на 2.3.
Хм, сижу с ICS на desire (bravo) и пока на лаги не жаловался. Хотя вполне вероятно, что я просто терпеливый.
Странно, мне наоборот показалось что с с Sense 4 и ICS все просто летает.
Тут нечему удивляться!!!
Даю зуб на отсечение что 5~10 процентов от общего кода бажны.
Вот только это, сразу не увидят.
Чем быстрее система, тем больше в суме используется технологий, тем и сложнее ее код для анализа.
А уж про профилирования сложных систем я молчу.
GetTickCount ))
Размеры исходных кодов ядра Linux вместе с включёнными туда драйверами устройств можно посчитать точно:
Год
Версия
Cтрок кода
1991
Ядро Linux 0.1
10 239
1994
Ядро Linux 1.0.0
176 250
1995
Ядро Linux 1.2.0
310 950
1996
Ядро Linux 2.0.0
777 956
1999
Ядро Linux 2.2.0
1 800 847
2001
Ядро Linux 2.4.0
3 377 902
2003
Ядро Linux 2.6.0
5 929 913
2009
Ядро Linux 2.6.32
12 606 910[5]
Даю зуб на отсечение что 5~10 процентов от общего кода бажны.
Вот только это, сразу не увидят.
Чем быстрее система, тем больше в суме используется технологий, тем и сложнее ее код для анализа.
А уж про профилирования сложных систем я молчу.
GetTickCount ))
Размеры исходных кодов ядра Linux вместе с включёнными туда драйверами устройств можно посчитать точно:
Год
Версия
Cтрок кода
1991
Ядро Linux 0.1
10 239
1994
Ядро Linux 1.0.0
176 250
1995
Ядро Linux 1.2.0
310 950
1996
Ядро Linux 2.0.0
777 956
1999
Ядро Linux 2.2.0
1 800 847
2001
Ядро Linux 2.4.0
3 377 902
2003
Ядро Linux 2.6.0
5 929 913
2009
Ядро Linux 2.6.32
12 606 910[5]
Ап, неизвестно кто, под предлогом «ускорения android» предлагает тысячам людей поставить какой-то левый генератор случайности. Там, во-первых, черти что может быть само по себе напихано, трояны, вирусы etc, а во-вторых, генератор случайности может быть подтасован, чтобы автор мог расшифровать то, что шифруется на этом смартфоне. А главное — массовость.
Поставил на Samsung Galaxy GIO. будм тестировать. субъективно шустрее
Подтянулись разработчики Dalvik — все, как один утверждают, что в системах новее gingerbread (более ранние исходники не проверялись) все и так правильно работает — используется dev/urandom. Говорят, что в коде VM и библиотеках нет обращений к dev/random. Говорят, что это «очень плохая идея». А ускорение получается из-за периодического дёрганья I/O и часов, что мешает управлению частотой процессора.
Короче вот — читайте.
Всё это профанация и какая-то шутка. А может быть и злой умысел. (чёрт его знает, сколько уже заработал автор и что там в коде).
Короче вот — читайте.
Всё это профанация и какая-то шутка. А может быть и злой умысел. (чёрт его знает, сколько уже заработал автор и что там в коде).
Я именно на это и намекаю. И даже если сейчас все разумные люди перестанут это чудо ставить, то ещё пол года будут ходить легенды о «чудо программе» среди несколько менее продвинутых пользователей и, сдаётся мне, что автор свои $100k заработает.
Ради тестинга поставил сабж на HTC Hero с CM6 — субъективно интерфейс стал плавнее и шустрее работать.
Охрененная прога.
Мой андроид стал работать намного быстрее… фактически я теперь не успеваю за интерфейсом…
А еще улучшилось настроение, волосы стали более шелковистые, помирился с тещей.
Купил 2 штуки. Про запас. Мало ли…
Мой андроид стал работать намного быстрее… фактически я теперь не успеваю за интерфейсом…
А еще улучшилось настроение, волосы стали более шелковистые, помирился с тещей.
Купил 2 штуки. Про запас. Мало ли…
Не к месту Ваш сарказм, утилита правда помогает.
Блин! Вы с ней хотя бы неделю походите, а уже потом говорите. Такое чудо сотворить не сложно. Но оно же, судя по комментариям разработчиков, просто повышает расход батареи. Поставьте себе какой-нибудь SetCPU, задерите частоты и тоже все летать будет. Только батарея значительно быстрее разряжаться будет.
Оно не может «просто повышать расход батареи». Оно что-то делает, что дает уменьшение задержки и расход батареи. Я не говорю о том, что именно пополнение пула улучшает работу, но ведь что-то улучшает и отрицать это бессмысленно.
Что за чушь? Оно не даёт процессору снижать частоту и не даёт периферии отключаться (по словам разработчиков адроида, которым есть все основания верить). Ясен перец, что это повышает отзывчивость системы ценой большего расхода батареи. Того же эффекта можно добиться иным путём, без танцев с ГСЧ. Берите SetCPU, запрещается снижать частоту при включённом экране и радуйтесь
Ставьте SetCPU и делайте тюнинг системы, как душе угодно. Я себе понизил частоту при отключенном экране и уменьшение частоты при разряде батареи — могу похвастаться пятью-шестью днями жизни от одной зарядки. Кому-то важнее плавность и красота интерфейса неописуемая, кому-то — время работы батареи. Универсального решения быть не может. Если бы убрали «тормоза», то нашлись бы недовольные временем жизни батареи и об очередной чудо-программе писали бы «Чуваки! Она круто продлевает жизнь батареи за счёт почти незаметного замедления некоторых программ! Нас обманывают!».
В любом случае генераторы случайных чисел тут ни при чём, и всё это дурно пахнет — есть другие, корректные, способы добиться того же результата.
В любом случае генераторы случайных чисел тут ни при чём, и всё это дурно пахнет — есть другие, корректные, способы добиться того же результата.
Что за вздор! Дает она ему снижать частоту, точнее, про нее тут говорить не сосем корректно.
И я как-то больше доверяю своим наблюдениям, чем разработчикам андроида, которые не могут пофиксить множащийся kworker на ICS.
И я как-то больше доверяю своим наблюдениям, чем разработчикам андроида, которые не могут пофиксить множащийся kworker на ICS.
Как эта ересь набрала 47 плюсов?
Да, какое-то массовое помешательство. Все зачем-то бездумно ставят платную версию, какую-то хрень с форума. Массово брызжут кипятком. И также массово игнорируют заявления от автором андроида о том, что это. чушь, и что ни VM, ни GUI не используют dev/random, а пользовательский софт вообще не имеет доступа к этому пути. И вообще, всем плевать на исходники, в которых этот пусть ВООБЩЕ не встречается.
Какие-то удивительные люди, рассказывающие о чудесном приросте скорости, но даже не погонявшие программу пару суток, чтобы посмотреть на расход батареи.
Ей богу — вирусная реклама и кто-то обогатиться на сотню штук баксов. А что — десяток активных друзей и всё — волна пошла.
Какие-то удивительные люди, рассказывающие о чудесном приросте скорости, но даже не погонявшие программу пару суток, чтобы посмотреть на расход батареи.
Ей богу — вирусная реклама и кто-то обогатиться на сотню штук баксов. А что — десяток активных друзей и всё — волна пошла.
Ну почему помешательство. Какой русский не любит быстрой езды?
Проблема, видно, остра, вот и весь секрет.
Проблема, видно, остра, вот и весь секрет.
я не пойму почему Вы брызжите слюной?
Программа ускоряет работу интерфейса и некоторых программ, многие это репортят и я тоже. дрейна я не вижу, переключил говернор из режима ondemand на powersave, интерфейс не лагает (раньше в таком режиме умирал). Если бы Вы потрудились почитать ветки на XDA и на code.google Вы бы обнаружили что никто не понимает почему оно так работает, но оно работает. И люди ищут баг в кернеле или еще где-то.
Программа ускоряет работу интерфейса и некоторых программ, многие это репортят и я тоже. дрейна я не вижу, переключил говернор из режима ondemand на powersave, интерфейс не лагает (раньше в таком режиме умирал). Если бы Вы потрудились почитать ветки на XDA и на code.google Вы бы обнаружили что никто не понимает почему оно так работает, но оно работает. И люди ищут баг в кернеле или еще где-то.
А Вам не кажется, странным, что в режиме powersave интерфейс не лагает? Вообще-то это как раз и говорит и том, что управления потреблением не работает. А дрейна так сразу и не будет видно. Вы попользуйтесь неделю. И даже потом можете увидеть только +20..30%. Но потом запустите какой-нибудь навител и с удивлением обнаружите, что вместо трёх-шести часов, он час-два работает.
А брызжу по той причине, что некто что-то сам себе придумал. Это что-то даже на первый взгляд выглядит бредово. Оно не подтверждается ни разработчиками системы, ни тестами (даже здесь на хабре в обсуждении есть очевидные опjрвержения этой бредовой идее об использовании dev/random GUI). Более того, люди, которым однозначно стоило бы верить в этой ситуации — разработчики VM говорят, что данное приложение не стоит использовать. Но тем не менее люди покупают его (?!) и массово ставят, не смотря на то, что оно затрагивает базовую функционалность системы — ГСН и вообще не понятно, что делает). Это выше моего понимания.
А больше всго удивляет эта странная волна рекламы — «я поставил и у меня прошёл геморрой». Проснитесь! Во-первых, данного эффекта (ошибки с ГСН) не имеет места быть. Во-вторых, есть весьма авторитетные сведения о том, что это приложение не стоит использовать (от разработчиков VM). В-третьих, это вообще непонятно и оно требует рута — вы уверены, что оно завтра не сольёт все ваши данные или не начнёт рассылать платные СМС? В-четвёртых, кто-нибдуь вдумчиво читал отзывы? Из врождённой вредности и злорадства я даже не буду говорить в чём дело, но наводящий вопрос — почему автор судорожно клепает версии и с чем связаны негативные отзывы? И в-пятых, сугубо здравый смысл — оно работает совсем не так как заявляется, поставьте старый добрый SetCPU и радуйтесь, зачем ставить ЭТО?! И в-шестых, количество положительных отзывов пока как минимум меньше количества нейтральных или негативных, но тем не менее каждый верит в чудо.
Короче, несколько раздражает этот эффект толпы, когда люди поддаются какому-то, не побоюсь, психозу и ставит сырое непроверенное приложение, взывающее более чем здоровый скептицизм со стороны разбирающихся в этом вопросе людей.
А брызжу по той причине, что некто что-то сам себе придумал. Это что-то даже на первый взгляд выглядит бредово. Оно не подтверждается ни разработчиками системы, ни тестами (даже здесь на хабре в обсуждении есть очевидные опjрвержения этой бредовой идее об использовании dev/random GUI). Более того, люди, которым однозначно стоило бы верить в этой ситуации — разработчики VM говорят, что данное приложение не стоит использовать. Но тем не менее люди покупают его (?!) и массово ставят, не смотря на то, что оно затрагивает базовую функционалность системы — ГСН и вообще не понятно, что делает). Это выше моего понимания.
А больше всго удивляет эта странная волна рекламы — «я поставил и у меня прошёл геморрой». Проснитесь! Во-первых, данного эффекта (ошибки с ГСН) не имеет места быть. Во-вторых, есть весьма авторитетные сведения о том, что это приложение не стоит использовать (от разработчиков VM). В-третьих, это вообще непонятно и оно требует рута — вы уверены, что оно завтра не сольёт все ваши данные или не начнёт рассылать платные СМС? В-четвёртых, кто-нибдуь вдумчиво читал отзывы? Из врождённой вредности и злорадства я даже не буду говорить в чём дело, но наводящий вопрос — почему автор судорожно клепает версии и с чем связаны негативные отзывы? И в-пятых, сугубо здравый смысл — оно работает совсем не так как заявляется, поставьте старый добрый SetCPU и радуйтесь, зачем ставить ЭТО?! И в-шестых, количество положительных отзывов пока как минимум меньше количества нейтральных или негативных, но тем не менее каждый верит в чудо.
Короче, несколько раздражает этот эффект толпы, когда люди поддаются какому-то, не побоюсь, психозу и ставит сырое непроверенное приложение, взывающее более чем здоровый скептицизм со стороны разбирающихся в этом вопросе людей.
Милейший, мне вот интересно, как приложение будет рассылать платные СМС, если у него на это не прописаны разрешения?
Вот вы доказываете, а в Маркете разрешения прочитать не удосужились.
Или я чего-то не знаю и вся система разрешений идет крахом?
Вот вы доказываете, а в Маркете разрешения прочитать не удосужились.
Или я чего-то не знаю и вся система разрешений идет крахом?
Я почитал кучку форумов на тему поста и опечален количеством пустых комментов на хабре.
Потому что мое краткое исследование на тему говорит, что эффект ИМЕЕТ МЕСТО. Даже когда без указанной проги меняют /dev/random линком на /dev/urandom.
И вот тут уже непонятной программой и желанием обогатиться ее автора не объяснишь.
Да, непонятно при чем ГС(П)Ч. Но факты есть, судя по всему — пока необъяснимые. И весь этот скепсис и хиханьки в комментах резко становятся неуместными. Айтишный ресурс, блин.
Потому что мое краткое исследование на тему говорит, что эффект ИМЕЕТ МЕСТО. Даже когда без указанной проги меняют /dev/random линком на /dev/urandom.
И вот тут уже непонятной программой и желанием обогатиться ее автора не объяснишь.
Да, непонятно при чем ГС(П)Ч. Но факты есть, судя по всему — пока необъяснимые. И весь этот скепсис и хиханьки в комментах резко становятся неуместными. Айтишный ресурс, блин.
Эффект несомненно быть. Например., в программах использующих шифрование, или активно создающих https/wifi соединения. Эти вещи действительно могут использовать генератор случайных чисел. Но, блин, это не повод ставить под рутом непонятную программу, имеющую кучу побочных эффектов (глюки с частотой процессора и засыпанием устройства. Да ещё и покупать её.
Я вот тоже скептически отношусь к чудесным приростам производительности, но тесты показали, что обращения к /dev/random всё же есть. Тем не менее я не увидел, чтобы активное использование /dev/random как-то отрицательно влияло на другие приложения.
Люди! Окститесь! Вы офигетельно тестирует генераторы случайный чисел и спорите об их эффективности, но НИКТО ещё не показал, что обычный софт приводит к опустошению очереди генератора! И, что система вообще использует этот генератор! О чём вы спорите!
И время как удачно выбрано-то. Круче было бы только перед Рождеством, но тогда в суете новость могла и незамеченной пройти.
Ну отчего же, выше товарищ даже не поленился сделать эти самые тесты.
Офигеть! Первая в истории плацебо-программа для андроида.
Скоро на Радио России будут будущим бабушкам втирать не лекарства от боли суставов, а ускоряющие скорость их девайсов аппликухи.
Ну, сударь, далеко не первая.
Почему сразу так бескомпромиссно? На том же 4PDA результаты неоднозначные. И если это и плацебо, то действует оно за счет уверенности, что разработчики Android вполне могли налажать :)
По сути уже предлагают собрать похожее самим, да еще можно попросить кого-то из уважаемых разработчиков с большим парком андроид-устройств протестить на разных девайсах. Да хоть на видео снять.
По сути уже предлагают собрать похожее самим, да еще можно попросить кого-то из уважаемых разработчиков с большим парком андроид-устройств протестить на разных девайсах. Да хоть на видео снять.
Выдержка из man:
Всё дело в том, что /dev/random может и блокирует всё остальное. Для обхода этого был придуман urandom, который не блокирует.
Since reads from /dev/random may block, users will usu‐
ally want to open it in nonblocking mode (or perform a read with
timeout), and provide some sort of user notification if the
desired entropy is not immediately available.
Всё дело в том, что /dev/random может и блокирует всё остальное. Для обхода этого был придуман urandom, который не блокирует.
Ализар, такой ализарный!
Есть приложение для проверки текущего состояния рандома play.google.com/store/apps/details?id=com.promethylhosting.checkrandentropyavail После установки Seeder у меня например (LG Optimus Hub) значение редко проседает ниже 1000, без Seeder прыгает между 200-500 при работе тяжелых приложений. Уж не знаю, как оно работает, но это точно не плацебо и визуальный эффект заметен на моем далеко не самом быстром телефоне? как минимум разблокировка и отрисовка некоторых приложений ускорилась
Почти с тем же успехом можно выставить CPU governor в Performance — тоже UI «летает»
С тем же да не с тем же. Ваша фраза вида: «Почти с тем же успехом можно купить флагман этого года — тоже UI «летает»
Я предложил абсолютно бесплатное решение тормозов в стиле приложения из поста. Собственно этот «ускоряющий» софт как раз таки и делает UI быстрее из-за того что дёргает I/O что предположительно вызывает подъём частоты процессора(кстати собираюсь проверить так ли это)
Вы же предполагаете что это идентично покупке флагмана — где логика?
Вы же предполагаете что это идентично покупке флагмана — где логика?
Тут habrahabr.ru/post/164881/#comment_5682287 уже есть подтверждение того, что частота перестала снижаться после установки чудо Seeder'а.
Так что чтобы добиться повышения производительности достаточно, как ни странно, увеличить минимальную частоту процессора.
Так что чтобы добиться повышения производительности достаточно, как ни странно, увеличить минимальную частоту процессора.
Samsung galaxy nexus 4.1.1 в мапс никакой разницы не увидел
При установленном генераторе энтропии аккумулятора на SGS3 хватает теперь почти на неделю, даже если все время включен NFS или другое ресурсоемкое приложение! Из минусов — заметил, что зум на камере телефона стал где-то х430, видны бактерии, но нечетко. Как правильно настроить фокус при таком приближении?
Это баг не андроида а матрицы где мы все существуем — приблуда просто повышает в матрице энтропию и начинаются тормоза рендеринга бытия, но поскольку рендеринг мобил работает на фиксированной скорости, нам кажется что они работают быстрее.
Вот и баг есть — code.google.com/p/android/issues/detail?id=42265. Поскольку никто из девелоперов не сообразил что надобы на гуглодоках собрать версии ядер, прошивок, железяк\проца (в частности WiFi — а возможно и AP), запущенного софта — а некоторые так прямо говорят что раз на моем девайсе с фиг знает какой прошивкой все без изменений то бага нету — то это 100% матрица пытается защититься.
Вот и баг есть — code.google.com/p/android/issues/detail?id=42265. Поскольку никто из девелоперов не сообразил что надобы на гуглодоках собрать версии ядер, прошивок, железяк\проца (в частности WiFi — а возможно и AP), запущенного софта — а некоторые так прямо говорят что раз на моем девайсе с фиг знает какой прошивкой все без изменений то бага нету — то это 100% матрица пытается защититься.
А Вы обсуждение этого бага почитайте. Там и об этой программе вспоминают. И именно там разработчики VM высказывают своё мнение по поводу этой программы.
Читал конечно же. И исходники /dev/random — ниже отписался.
Только позиция девелоперов VM это аналог «к пуговицам претензии есть?».
Сам далвик не дергает но вот приложения дергают. Как в том же кейсе человек пишет про то что торрент клиент «кладет» все — а с «дурной» (потомучтно не безопасно) программой вдруг все «поднимается».
Там же есть камент что гугломапсы перестают работать у некоторых (некоторые пишут что начинает быстрее работать) если не настоящим генератором пользоваться (что, как правильно заметили, означает что гугломапс _зависим_ от случайных чисел).
Кстати — /proc/sys/kernel/random/entropy_avail показывает текущий размер пула но не учитывает сколько данных из пула будет вычитанно (грубо говоря не видно очереди на чтение — там может быть запрос на 256 байт).
Вообще, после ковыряния в сорцах /dev/random волосики немного дыбом стоят.
Только позиция девелоперов VM это аналог «к пуговицам претензии есть?».
Сам далвик не дергает но вот приложения дергают. Как в том же кейсе человек пишет про то что торрент клиент «кладет» все — а с «дурной» (потомучтно не безопасно) программой вдруг все «поднимается».
Там же есть камент что гугломапсы перестают работать у некоторых (некоторые пишут что начинает быстрее работать) если не настоящим генератором пользоваться (что, как правильно заметили, означает что гугломапс _зависим_ от случайных чисел).
Кстати — /proc/sys/kernel/random/entropy_avail показывает текущий размер пула но не учитывает сколько данных из пула будет вычитанно (грубо говоря не видно очереди на чтение — там может быть запрос на 256 байт).
Вообще, после ковыряния в сорцах /dev/random волосики немного дыбом стоят.
А по-моему, они очень верно указали на то, что программа работает совсем не так, как кажется и на то, что она обладает серьёзными побочными эффектами. А что они ещё должны были сделать? Они проверили, есть ли баг. Бага нет. Они посмотрели, что происходит — происходят побочные эффекты и нарушение работы управлением потреблением. Они высказали своё мнение — не нужно ставить программу, которая непонятно, как работает.
От чего зависим гугломапс — бабуля на две сказала. Там у программы масса эффектов и багов. (одни только грабли с режимом сна автор никак не разгребёт). Гугломапсы могут перестать работать по самым разным причинам.
Huawei U8110 — установил, програмка запросила рута, перезагрузился.
Визуально меньше тормозит, но тормоза в любом случае будут, так как в телефоне нет нормального GPU.
Визуально меньше тормозит, но тормоза в любом случае будут, так как в телефоне нет нормального GPU.
Решил попробовать генератор энтропии на других устройствах:
Телевизор GNUSMAS обнаружил три дополнительных ночных канала, все остальные стали показывать в HD помоему
Роутер KNIL-D DIR-320 раньше работал только на b/g скорости неожиданно заработал на n скорости
Ноутбук PH обновился до Win8
Думаю поставить на свой SII вдруг тоже в SIII превратиться, кто что скажет? Стоит попробовать? Хотя я слышал что SuperAMOLED не может увеличиваться сам.
Телевизор GNUSMAS обнаружил три дополнительных ночных канала, все остальные стали показывать в HD помоему
Роутер KNIL-D DIR-320 раньше работал только на b/g скорости неожиданно заработал на n скорости
Ноутбук PH обновился до Win8
Думаю поставить на свой SII вдруг тоже в SIII превратиться, кто что скажет? Стоит попробовать? Хотя я слышал что SuperAMOLED не может увеличиваться сам.
В /dev/random счас пул энтропии набивается синхронно с событиями ввода (еще прерывания и диска) — и если ктото ожидает чтения из /dev/random то в общем его пнут когда данные наполнятся.
Тоесть у кого никакая прога особо /dev/random не читается — у тех чуть впустую проц работает и визуально ничего не видно, а у кого читает — у того I/O «проснется» слишком рано.
Посколько никто не читает из /dev/random по несколько бит — вот вам и лаги а не равномерное подтормаживание.
Тоесть у кого никакая прога особо /dev/random не читается — у тех чуть впустую проц работает и визуально ничего не видно, а у кого читает — у того I/O «проснется» слишком рано.
Посколько никто не читает из /dev/random по несколько бит — вот вам и лаги а не равномерное подтормаживание.
Motorola Droid 4, отличий пока не вижу.
UPD
Отличий совсем не вижу. В общем нафиг.
UPD
Отличий совсем не вижу. В общем нафиг.
Вот читаю некоторые комментарии и удивляюсь — читают не внимательно, передергивают…
И в статье и в оригинале написано:
— WiFi, https, (ре)сортировка Hash, таких классов как Map или List (для того же Cache) и т.д. активно используют ГСЧ;
— Гуй использует системные компоненты… дальше понятно;
— Рута оно требует кстати, потому что подругому писать в /dev/random из /dev/urandom не получится;
— Зачем ставить Seeder на android 4.0, где все это уже пофиксено, к тому же ясно же сказано «в старых версиях»?
Теперь факты:
— Мой старый рутованый G1, Cyanogen 7.0 (SetCPU performance/maximum) — после установки Seeder просто летает, там где раньше просто ползал. Но не везде…
— На другие свои андроид устройства ставить не буду — за ненадобностью.
— Упомянутые многими комментирующими разработчики андроида могут идти лесом, т.к. к труппе xda-developers у меня гораздо больше доверия — они по крайней мере используют и поддерживают старые устройства. В отличии от Гугла и производителей, которыезабили на пользователей используют и развивают только флагманы.
И в статье и в оригинале написано:
В старых версиях Android некоторые системные компоненты и JVM активно...Теперь некоторые моменты:
— WiFi, https, (ре)сортировка Hash, таких классов как Map или List (для того же Cache) и т.д. активно используют ГСЧ;
— Гуй использует системные компоненты… дальше понятно;
— Рута оно требует кстати, потому что подругому писать в /dev/random из /dev/urandom не получится;
— Зачем ставить Seeder на android 4.0, где все это уже пофиксено, к тому же ясно же сказано «в старых версиях»?
Теперь факты:
— Мой старый рутованый G1, Cyanogen 7.0 (SetCPU performance/maximum) — после установки Seeder просто летает, там где раньше просто ползал. Но не везде…
— На другие свои андроид устройства ставить не буду — за ненадобностью.
— Упомянутые многими комментирующими разработчики андроида могут идти лесом, т.к. к труппе xda-developers у меня гораздо больше доверия — они по крайней мере используют и поддерживают старые устройства. В отличии от Гугла и производителей, которые
— Упомянутые многими комментирующими разработчики андроида могут идти лесом, т.к. к труппе xda-developers у меня гораздо больше доверия — они по крайней мере используют и поддерживают старые устройства.
О да, к гаражному сервису намного больше доверия, чем к инженеру с завода BMW — в гаражном сервисе не только новейшие BMW, но и «шестёрки» с «девятками» ремонтировать умеют.
На XDA много авторов ROM-ов для любых телефонов, на Хабре не видно ни одного.
Про передергивать — это вы видимо пропустили. :)
И таки да — я таких «инженеров» с заводов повидал (в том числе кстати и с BMW — как вы угадали?), что иногда «гаражный сервис» как вы выразились много много лучше.
Вообще, словосочетание «гаражный сервис» как то не совсем укладывается в одно предложение с open source, вам не кажется? Тот же линукс возьмите…
Open source комюнити — это сила!
Кстати, CyanogenMod не только Стивом разрабатывалась — XDA тоже внесли свой довольно большой вклад. А Гугль, вместо благодарности, в сентябре 2009 направил Стиву, как главному разработчику, предупредительное письмо «прекратить и воздержаться». С тех пор они для меня идут лесом.
Хотя правды для нужно заметить, что все-таки некоторые инженеры Гугля были этим возмущены.
Компании в первую очередь заинтересованы в получении прибыли, комюнити же развивает проект для себя (и для вас в том числе) и часто кстати совсем безкорыстно.
Потому мы и имеем то что имеем.
И таки да — я таких «инженеров» с заводов повидал (в том числе кстати и с BMW — как вы угадали?), что иногда «гаражный сервис» как вы выразились много много лучше.
Вообще, словосочетание «гаражный сервис» как то не совсем укладывается в одно предложение с open source, вам не кажется? Тот же линукс возьмите…
Open source комюнити — это сила!
Кстати, CyanogenMod не только Стивом разрабатывалась — XDA тоже внесли свой довольно большой вклад. А Гугль, вместо благодарности, в сентябре 2009 направил Стиву, как главному разработчику, предупредительное письмо «прекратить и воздержаться». С тех пор они для меня идут лесом.
Хотя правды для нужно заметить, что все-таки некоторые инженеры Гугля были этим возмущены.
Компании в первую очередь заинтересованы в получении прибыли, комюнити же развивает проект для себя (и для вас в том числе) и часто кстати совсем безкорыстно.
Потому мы и имеем то что имеем.
Вообще, словосочетание «гаражный сервис» как то не совсем укладывается в одно предложение с open source, вам не кажется? Тот же линукс возьмите…
Нет, не кажется. Opensource — это модель разработки, «гаражный сервис» — это форма вклада. В некотором роде, они ортогональны.
В описанном примере, «гаражный сервис» — это что-то на уровне сторонних багрепортов/патчей. «Подшлифовать напильником» да «прикрутить тюнерский бампер». Основная работа в том же опенсорсе, тем не менее, происходит вполне себе «на заводе», и «спроектировать новый двигатель» в гараже никто нормально не сможет.
Так что при выборе между комментариями людей, которые проектируют двигатели и людей, которые растачивают поршни, я бы посоветовал прислушиваться к первым. Без первых, нечего бы было растачивать вторым.
Может вы отчасти правы, только это с какой стороны посмотреть — на XDA довольно много разрабов линукс. Двух я знаю лично.
Применительно к обсуждаемой проблеме (т.е. что касается /dev/random), я вижу это как-то так:
Линукс разработали в том числе XDA — разработали двигатель.
Андроид надстроил («навесил»бампер на линукс) Гугл — тюнинг двигателя (подшлифовали напильником, расточили поршни).
Надеюсь теперь моя точка зрения понятней.
Применительно к обсуждаемой проблеме (т.е. что касается /dev/random), я вижу это как-то так:
Линукс разработали в том числе XDA — разработали двигатель.
Андроид надстроил («навесил»
Надеюсь теперь моя точка зрения понятней.
Разработчики VM, вообщето, больше времени работают с исходниками системы, и лучше представляют структуру кода.
Вот если бы на xda сказали, что в исходниках не встречается использование dev/random, я бы мог сомневаться, так кто его знает какие исходники и как они смотрели. А когда говорят люди, поддерживающие код и активно в него комитящие, да ещё и в ветке обсуждения баг-репорта, то я даже и не знаю, кто может быть авторитетнее.
И в open-source, тоже не все равно — кто имеет право комитить в репозиорий, а кто-то нет. И у всех разные права и полномочия.
Вот если бы на xda сказали, что в исходниках не встречается использование dev/random, я бы мог сомневаться, так кто его знает какие исходники и как они смотрели. А когда говорят люди, поддерживающие код и активно в него комитящие, да ещё и в ветке обсуждения баг-репорта, то я даже и не знаю, кто может быть авторитетнее.
И в open-source, тоже не все равно — кто имеет право комитить в репозиорий, а кто-то нет. И у всех разные права и полномочия.
Dalvik использует линуксовую HorseradishKnowsNS::HorseradishKnowsProc, она в свою очередь использует /dev/random (может не напрямую, через какую-то рутину, через весь источник линукса). Каким образом можно сказать, поискав в источниках Dalvik'а по /dev/random — мы его не используем? При чем здесь встречаются не встречаются?
Это тож самое, что если я использую SomeDBEngine::BeginTransaction, говорить о том, что у меня нет mutex::lock, поискав по исходникам…
Это тож самое, что если я использую SomeDBEngine::BeginTransaction, говорить о том, что у меня нет mutex::lock, поискав по исходникам…
" — WiFi, https, (ре)сортировка Hash, таких классов как Map или List (для того же Cache) и т.д. активно используют ГСЧ;"
Вопрос какой из ГСЧ они используют. По уверениям разработчиков, на современных версиях JVM и библиотеки (Map, List и т.п.) используют dev/urandom. Что использует WiFi и https никто особо не заморачивался, так как во-первых, там положено нормальный ГСЧ использовать, при корректной работе никаких тормозов быть не должно.
Кто и зачем ставит не понятно. Тем более для систем с версией >=4.0 Так есть же масса отзывов о том, как оно там офигительно всё ускоряет!
Вопрос какой из ГСЧ они используют. По уверениям разработчиков, на современных версиях JVM и библиотеки (Map, List и т.п.) используют dev/urandom. Что использует WiFi и https никто особо не заморачивался, так как во-первых, там положено нормальный ГСЧ использовать, при корректной работе никаких тормозов быть не должно.
Кто и зачем ставит не понятно. Тем более для систем с версией >=4.0 Так есть же масса отзывов о том, как оно там офигительно всё ускоряет!
Я выше не зря написал что надо инфу от пользоватей систематизировать.
На телефоне может спокойто стоять и от оператора трэкер и от производителя и куча всяких приложений — которые, к примеру, шифруют данные. Малоли чего еще пользователь поставил?
Это все может оч радостно генерировать те самые тормоза (если аппаратный генератор не работает) ибо софтовый не сильно много бит в секунду может сгенерировать.
time dd if=/dev/random of=/tmp/rnd.txt bs=1 count=128
под вмварой за NAT — real 7m6.553s (!!!) (это у меня терпение лопнуло и я начал пробел нажимать)
на арм 200mhz (много чего сетевого на нем) — real 0m 42.37s
на dual xeon — real 2m3.688s (дофига пользователей)
Кто сделает /dev/random benchmark app?
На телефоне может спокойто стоять и от оператора трэкер и от производителя и куча всяких приложений — которые, к примеру, шифруют данные. Малоли чего еще пользователь поставил?
Это все может оч радостно генерировать те самые тормоза (если аппаратный генератор не работает) ибо софтовый не сильно много бит в секунду может сгенерировать.
time dd if=/dev/random of=/tmp/rnd.txt bs=1 count=128
под вмварой за NAT — real 7m6.553s (!!!) (это у меня терпение лопнуло и я начал пробел нажимать)
на арм 200mhz (много чего сетевого на нем) — real 0m 42.37s
на dual xeon — real 2m3.688s (дофига пользователей)
Кто сделает /dev/random benchmark app?
Про сторонние приложения согласен, но это же кривость разработчиков приложений. Там и не такие глюки могут быть. В этом треде уже вроде давали ссылки на бенчмарки для ГСЧ. И скрипты приводили. И опыты ставили.
Вы считаете что позициию «к пуговицам претензии есть?» правильной?
Получается что те кто критиковал андроид за фрагментацию таки правы.
С текущий /dev/random — даже если _все_ приложения будут вести себя «корректно» можно набрать критическую массу когда /dev/random не будет справляться (не считая того что сервер который начнет корректно дробать https может неожиданно усугубить ситуацию на стороне клиента).
Счас, если тормозит — ждать не надо — надо пальцем водить по экрану или громкость тапать )))
Получается что те кто критиковал андроид за фрагментацию таки правы.
С текущий /dev/random — даже если _все_ приложения будут вести себя «корректно» можно набрать критическую массу когда /dev/random не будет справляться (не считая того что сервер который начнет корректно дробать https может неожиданно усугубить ситуацию на стороне клиента).
Счас, если тормозит — ждать не надо — надо пальцем водить по экрану или громкость тапать )))
Не понял, что Вы пытаетесь сказать. какую именно проблему нужно решать?
Софтовый ГСЧ не должен быть бутылочным горлышком.
?! Так можно сказать про что угодно — «процессор не должен быть бутылочным горлышком».
ГСЧ им и не является. Для системы и системных приложений. А если кто его не там и не так использует, то он ССЗБ. Там несколько генераторов и нужно думать, где, что и зачем используешь.
ГСЧ им и не является. Для системы и системных приложений. А если кто его не там и не так использует, то он ССЗБ. Там несколько генераторов и нужно думать, где, что и зачем используешь.
Ну тоесть это нормально, что текущий софтовый генератор на 4х десктопных ядрах, при минимизации внешних событий 128 случайных байт «считает» более 7 минут?
Вам шашечки или ехать? В смысле непредсказуемость или скорость?
Хотите быстро — использует псевдослучайные генераторы, коих море (начиная с urandom).
Откуда система должна брать исходные данные? Там даже жёсткого диска нет со сколько-либо случайным временем доступа. Суровая объективная реальность.
Хотите быстро — использует псевдослучайные генераторы, коих море (начиная с urandom).
Откуда система должна брать исходные данные? Там даже жёсткого диска нет со сколько-либо случайным временем доступа. Суровая объективная реальность.
В цивилизованных странах принято ездить на такси, с шашечками и счетчиком.
Чисто дискретных систем нету чтобы так защищать генерацию из таймера по случайным событиям.
В андроид девайсах есть несколько источников аналогового шума.
Lavarnd говорит что она очень крута.
Посмотрите как печально работает qrngd — все потому что /dev/random такой какой он есть.
Чисто дискретных систем нету чтобы так защищать генерацию из таймера по случайным событиям.
В андроид девайсах есть несколько источников аналогового шума.
Lavarnd говорит что она очень крута.
Посмотрите как печально работает qrngd — все потому что /dev/random такой какой он есть.
Он же их не «считает», он их именно что собирает, из внешних источников. Ваши ядра здесь никак не помогают, и не мешают. В общем, пора в Андроид аппараты ставить хардварные ГСЧ. Что там было в моде раньше? Шумные низкокачественные резисторы?
Попробовал. Я чуть в шоке, реально телефон стал работать ощутимо быстрее.
Sense, который не доходят руки снести и поставить голый Android, прям забегал.
Sense, который не доходят руки снести и поставить голый Android, прям забегал.
Прочитал статью с опозданием. Столько комментариев! Все не перечитаешь. Так что решили-то? Стоящая вещь или нет? :)
Разжевать и в рот положить?.. сколько комментаторов — столько мнений.
Один скажет — да, другой — нет, я скажу — да, но...
Один скажет — да, другой — нет, я скажу — да, но...
не хочет она работать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Генератор энтропии Seeder 1.1 существенно уменьшает лаги на Android-устройствах