Если честно, мне сложно представить, чем еще можно ускорить простейший single publisher single subscriber случай. Но одно предположение у меня есть. Когда я гонял бенчмарки перед JavaOne, я пробовал заменять
AtomicLongFieldUpdater.lazySet() на Unsafe.putOrderedLong(). Это то же самое по смыслу, но отсутствуют различные проверки доступа и type-safety. Разница была довольно существенной. Правда, не вдвое, процентов на 20-25. Но, поскольку больше возможностей я не вижу, то я ставлю на то, что в третьей версии Disruptor появится магический класс sun.misc.Unsafe.Хотя будет гораздо интереснее, если я ошибусь, и будет что-то новенькое :)
В комментариях он сам говорит:
ОтветитьУдалитьNothing specific, mostly code clean up, refactoring and simplification, the performance boost was a surprise
Кроме того, многократное увеличение производительности было по throughput'у. Про latency, на которой, как я помню, ты (да и они) концентрировался, ничего не сказано. И мне как-то не очень верится, что просто порефакторив код можно добиться более чем 2-кратного улучшения throughput'a, не попортив при этом latency.
Хотя если посмотреть на бенчмарки, то можно заметить, что раньше после прогрева был скачок 22 MB/s => 32 MB/s, а теперь 22 MB/s => 88 MB/s. Логично предположить, что код стал чище, и JIT смог применить какую-то хитрую оптимизацию.
ОтветитьУдалитьЯ как раз фокусировался на пропускной способности -- ее измерять проще, да и в то время меня throughput интересовал больше.
ОтветитьУдалитьВообще, да, я об этом не подумал -- могли как-то затюнить бэтчинг. Бэтчинг потенциально очень много может дать.
>Логично предположить, что код стал чище, и JIT смог применить какую-то хитрую оптимизацию.
Я вот с трудом могу себе представить, что там могло такое получиться. Там и до того был очень чистый и простой код.