EnumSet. Первое, что мне про него было интересно — это, конечно, скаляризация итератора. Ну, потому что по любой коллекции очень удобно ходить циклом foreach, но не всегда хочется за это удобство платить, пусть даже и не дорого: public static enum Enum3 {
FIRST,
SECOND,
THIRD
}
...
final EnumSet set = EnumSet.allOf( Enum3.class );
...
//benchmark start
long sum = 0;
for( final Enum e : set ) {
sum += e.ordinal();
}
return sum;
//benchmark end
private double allocateConditionally( final ThreadLocalRandom rnd ) {
final Vector2D v;
if( rnd.nextBoolean() ) {
v = new Vector2D( 1, rnd.nextDouble() );
} else {
v = new Vector2D( rnd.nextDouble(), 1 );
}
return v.length();
}не скаляризуется — хотя интуитивно кажется, что скаляризация здесь должна быть тривиальной. private double allocateConditionally2( final ThreadLocalRandom rnd ) {
final Vector2D result = new Vector2D();
if( rnd.nextBoolean() ) {
final Vector2D v = new Vector2D( 1, rnd.nextDouble() );
result.copyFrom(v);
} else {
final Vector2D v = new Vector2D( rnd.nextDouble(), 1 );
result.copyFrom(v);
}
return result.length();
}В этом коде на одну точку аллокации больше — но все эти аллокации успешно скаляризуются. В общем-то, ничего особо удивительного: здесь каждая ссылочная переменная в любых сценариях исполнения всегда адресует один-единственный объект, поэтому никаких сложностей у скаляризации не возникает :)
Vector2D, типа такого:public static final class Vector2D {
private double x;
private double y;
public Vector2D( final double x,
final double y ) {
this.x = x;
this.y = y;
}
public Vector2D add( final Vector2D other ) {
return new Vector2D(
x + other.x,
y + other.y
);
}
public void addAccumulate( final Vector2D other ) {
x = x + other.x;
y = y + other.y;
}
public double dot( final Vector2D other ) {
return x * other.x + y * other.y;
}
public double length() {
return Math.sqrt( this.dot( this ) );
}
}
(Конкретные детали не важны, нужен класс без сложной логики и коллекций внутри)intcementAndGet (==lock xadd) показывает лучшие результаты на процессорах архитектуры Nehalem, нежели на процессорах более свежей (и, вообще говоря, почти везде более производительной) архитектуры Sandy Bridge. Бенчмарк был совершенно тривиальный — сколько-то потоков, тупо делающих __sync_add_and_fetch() одному счетчику — поэтому результаты, конечно, выглядели странно. И вот, больше чем через год, наконец-то странность объяснилась, и объяснение очень интересное — я не могу удержаться, и не разобрать его.