5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
Вы переоцениваете мои знания. Замеров или какого-то понимания нет, но плюс всех бенчмарков в том, что в большинстве их можно воссоздать руками и запустить за пятнадцать минут, просто дропнув сорцы в новый класс, починив реплейсом смену имени или пакета, и написав два метода в бенче. Что до процентов, то там надо смотреть, это непосредственно рандом занимал, или что-то ещё. Может там вообще все расходы на обслуживание сисколла.
Читать полностью…
скажи, если я чего-то не понимаю по мат. части, тут изи могу обосраться) просто пока не вижу
Читать полностью…
А при чём тут настройка Java Security и генерация UUID? Насколько я помню, то UUID генерируется с помощью ThreadLocalRandom, который не имеет никакого отношения к SecureRandom из Java Security.
Читать полностью…
https://github.com/openjdk/jmh/blob/master/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_36_BranchPrediction.java
я сейчас смотрю на собственный бенч из 2020, где простой int a > b ? a : b умножился на три при подаче на вход несортированных значений, но там кажется стоит всю статью перепроверить и переписать
Тут больше нужно сравнение реализации алгоритма и его теоретической модели. Можно всегда написать асимптотику без точной константы, но тогда придётся страдать, чтобы понять, какая реальная асимптотика реализации, что не так просто, если на, например, малых значениях происходит одна история, а на больших — другая. Но если я могу дать конкретную оценку, то можно просто проверять, правда ли, что один график всегда ниже другого. DCE тут, кончено, — страшный враг, да. А абсолютных оценок пока не хочется. То есть два (или три) порядка точности, думаю, переживу.
Можно подготовить набор семплов
https://habr.com/ru/companies/kingston_technology/articles/408843/
Вот например, пишут про 19 стадий в конвейере ryzen
Интересно, насколько большая эта "куча тактов". Константу где-нибудь порядка 10 я готов попытаться учесть. Иначе придётся менять стратегию сверки теории и практики.
Читать полностью…
Меня всегда радовало быть одноврменно и админом, разбирающимся в том, что там нового выпустили, и анонимом, которые какие-то примусы паяет, и ещё устраивать перепалки между этими двумя личностями
Читать полностью…
Потому что:
1. Не готов к такому языку ни морально, ни профессионально.
2. Kotlin сильно проще, и его можно применить сразу на JVM и (при необходимости, которая не часто, но и не редко возникает) на других платформах как JS/WASM. (На последнем производительность мерить пока желания никакого нет, но есть возможность быстро портировать код.)
3. Насколько знаю, разница между JVM и C++ константная (сборщик мусора почти не влияет на время работы, а в остальном нет асимптотической просадки типа "на С++ алгоритм работает за O(n^2), а на JVM — за O(e^n)"). Мне совершенно не страшны большие константы. Мне страшны большие асимптотики, потому что с экспоненциальными асимптотиками и хуже я встречаюсь всё время.
В реальности всё сложно.
Если ты делаешь просто сравнение типа boolean a = b > c,
то оно занимает один такт (вот эти самые 0.2-0.3 нс)
Если по этому значению есть ветвление и там будут промахи предсказаний куда пойдёт выполнение, то можно потерять кучу тактов.
И ещё процессор умеет выполнять независимые операции за один такт, например сразу две:
A0 = b0 > с0
А1 = б1 > с1
1. Необходимо отключить кортану хром всё, что может требовать себе ресурсы и отнимать внимание шедулера операционки. Можно посмотреть вот сюда, например:
Benchmarks.empty 1 avgt 3 0,550 ± 1,451 ns/op
Есть несколько алгоритмов в вычислительной геометрии (конкретно, вычисление выпуклой оболочки; некоторые уже реализованы). На них есть красивые и короткие формулы асимптотик вида O(nh). Мне были нужны эти алгоритмы для математических экспериментов. Но потом задался вопросом, верны ли эти асимптотики. Оказалось, что если учитывать другие банальные параметры (например, размерность пространства), то формула становится совсем не такой короткой и красивой. Захотелось сделать две вещи: перевычислить асимптотику с самого начала, но теперь честно, и (коли таковая имеется) проверить, правда ли она выполняется (чтобы не было "ай, я забыл очередной параметр"). Для этого нужно осознать, какие базовые операции и сколько они стоят.
Читать полностью…
Привет! Извините, пришёл из чата по Kotlin, поэтому не готов настроить окружение под Java, но вопрос про бенчмарки на JVM и JMH.
Хочется замерить, сколько выполняются базовые операции как, например, сравнение двух Int-ов. Чтобы понимать порядок затрачиваемого времени и сделать осмысленные теоретические расчёты для алгоритмов и сравнить с реальными данными. (Понятно, что 100 нс — это много, а 0,001 нс — мало. Но сколько тогда на деле?) Есть ли смысл пытаться сделать это с помощью JMH?
Пока напарываюсь на проблему, что, например, blackhole.consume(57) работает примерно 3,6—3,7 нс и blackhole.consume(a > b) работает в среднем на примерно 0,2 нс больше (но это значение нельзя брать как время выполнения сравнения, так как разброс у обоих бенчмарков заметно больше). Код бенчмарка:
@OutputTimeUnit(BenchmarkTimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
class Benchmarks {
@Param("1", "10", "100", "1000")
@JvmField
final var integer: Int = 0
@JvmField
final val otherInteger = 179
@Benchmark
fun empty() {}
@Benchmark
fun benchmark1(blackhole: Blackhole) {
blackhole.consume(integer)
}
@Benchmark
fun benchmark2(blackhole: Blackhole) {
blackhole.consume(integer > otherInteger)
}
}
Benchmark (integer) Mode Cnt Score Error UnitsЧитать полностью…
Benchmarks.benchmark1 1 avgt 3 3,634 ± 0,296 ns/op
Benchmarks.benchmark1 10 avgt 3 3,717 ± 1,200 ns/op
Benchmarks.benchmark1 100 avgt 3 3,659 ± 0,396 ns/op
Benchmarks.benchmark1 1000 avgt 3 3,668 ± 0,433 ns/op
Benchmarks.benchmark2 1 avgt 3 3,891 ± 0,388 ns/op
Benchmarks.benchmark2 10 avgt 3 3,942 ± 0,323 ns/op
Benchmarks.benchmark2 100 avgt 3 3,940 ± 0,750 ns/op
Benchmarks.benchmark2 1000 avgt 3 3,934 ± 0,576 ns/op
Benchmarks.empty 1 avgt 3 0,550 ± 1,451 ns/op
Benchmarks.empty 10 avgt 3 0,492 ± 0,083 ns/op
Benchmarks.empty 100 avgt 3 0,503 ± 0,089 ns/op
Benchmarks.empty 1000 avgt 3 0,503 ± 0,134 ns/op
Пруфы прилагаются:
https://en.m.wikipedia.org/wiki/Ultrawide_formats
Хм, значит я ошибаюсь, всегда казалось там используется именно ThreadLocalRandom
Читать полностью…
https://github.com/openjdk/jdk/blob/jdk-25%2B20/src/java.base/share/classes/java/util/UUID.java#L149
public static UUID randomUUID() {
SecureRandom ng = Holder.numberGenerator;
}
@microkite а случайно нет замеров на актуальных версиях Java /dev/random vs /dev/urandom ?
Да и в принципе есть ли смысл с этим морочиться.
Postgresql использует /dev/urandom, насколько я понимаю (https://security.stackexchange.com/questions/93902/is-postgress-uuid-generate-v4-securely-random)
а вот в конфиге JAVA_HOME/conf/security/java.security - /dev/random
вообще, вопрос ещё насколько актуальна информация в сети про эти 2 метода, читаю это
https://www.thomas-huehn.com/myths-about-urandom/
где написано в том числе, что /dev/random несколько раз переписывался. может сейчас вообще между ними нет разницы ?
изначально вопрос возник в процессе аналитики flamegraph от профиля async profile, где UUID.randomUUID() занимал достаточно значительную долю (около 4.5%)
в proc/sys/kernel/random/entropy_avail - 256
private static final Random GENERATOR = new Random(0);
private static final int[][] INPUTS = Stream.generate(() -> new int[] { GENERATOR.nextInt(), GENERATOR.nextInt() }).limit(1 << 16).toArray(int[][]::new);
Там скорее всего выполняется запрошенное сравнение - насколько понимаю, джит там видит обращение к мутабельному полю, это больше ворчание. Настоящий ответ даст hsdis, разбирать мелкие примеры как правило довольно просто, на каждый десяток-другой инструкций будет комментарий о том, чему он реально соответствует. Для операций с одним возвращаемым значением можно вообще не использовать blackhole и возвращать это значение из метода, но на результаты это влиять не должно.
Попробую создать более нормальные условия и позапускать его подольше.
Поэтому и было интересно, как всё-таки правильно.
Да, порядка 10-30 если предсказание процессора подумало что ветвление пойдёт не туда.
Если предсказание было правильным, то всё быстро
Спасибо за ключевые идеи! Сходу не всё понятно, но теперь понятно, куда двигаться.
Да, бенчмарк проведён быстро на коленке, чтобы хотя бы понимать, что получается, а что нет. Попробую создать более нормальные условия и позапускать его подольше.
Про JIT оптимизации знаю, поэтому был вопрос, как правильно померить такие вещи. В тупую написать blackhole.consume(integer < otherInteger), как видно, — неправильная стратегия. Поэтому и было интересно, как всё-таки правильно. Попробую утилиты, которые Вы посоветовали.
Ещё раз спасибо!
Да просто делать нечего, отвечаю своему же второму аккаунту
Читать полностью…
Ахуеть у тебя там чё возле монитора всегда блокнотик лежит с ответами на подобные незадаваемые никогда вопросы?
Читать полностью…
глянул в гугле, да, 32х9 называют суперультра... Тогда бери его, его стетхем не поносит)
Читать полностью…
тип на своем языке говорит, а этот за какие-то принципы квакает, iq -4
Читать полностью…