Информация об изменениях

Сообщение Re[20]: C# - from indians by indians от 02.06.2015 16:53

Изменено 02.06.2015 17:09 Evgeny.Panasyuk

Здравствуйте, mik1, Вы писали:

M>Давай пока что так, требует JMH, которому я доверяю тестировать производительность:

M>
M>        public double re( int i )
M>        {
M>            return ar[ i *2 ];
M>        }
M>        public double im( int i )
M>        {
M>            return ar[ i * 2 + 1 ];
M>        }
M>    ...
M>    private static final int N = 1 << 24;

M>    private double[] u_ar = new double[ N * 2 ];
M>    private double[] v_ar = new double[ N * 2 ];
M>    private ComplexFlyweight u = new ComplexFlyweight( u_ar );
M>    private ComplexFlyweight v = new ComplexFlyweight( v_ar );

M>    ...
M>    @Benchmark
M>    public double testVectorMult()
M>    {

M>        for ( int i = 0; i < u_ar.length / 2; ++i ) {
M>            v.re(i, u.re(i) * v.re(i) - u.im(i) * v.im(i) );
M>            v.im(i, u.re(i)*v.im(i) + u.im(i)*v.re(i));
M>        }
M>        return u.re( 0 );
M>    }
M>


Здесь используется не класс типа Complex, а класс типа ComplexArray.
Собственно об этом и была речь — простейшая абстракция Complex не совместима с производительностью. То есть нельзя просто отдельно создать класс Complex и положить его в отдельный стандартный массив, в стандартную deque, в стандартную priority_queue и т.п. — их приходится вручную скрещивать.
Причём если взять структуру чуть-чуть посложнее, типа {double, float, int} — то всё, приплыли капитально.
Re[20]: C# - from indians by indians
Здравствуйте, mik1, Вы писали:

M>Давай пока что так, требует JMH, которому я доверяю тестировать производительность:

M>
M>        public double re( int i )
M>        {
M>            return ar[ i *2 ];
M>        }
M>        public double im( int i )
M>        {
M>            return ar[ i * 2 + 1 ];
M>        }
M>    ...
M>    private static final int N = 1 << 24;

M>    private double[] u_ar = new double[ N * 2 ];
M>    private double[] v_ar = new double[ N * 2 ];
M>    private ComplexFlyweight u = new ComplexFlyweight( u_ar );
M>    private ComplexFlyweight v = new ComplexFlyweight( v_ar );

M>    ...
M>    @Benchmark
M>    public double testVectorMult()
M>    {

M>        for ( int i = 0; i < u_ar.length / 2; ++i ) {
M>            v.re(i, u.re(i) * v.re(i) - u.im(i) * v.im(i) );
M>            v.im(i, u.re(i)*v.im(i) + u.im(i)*v.re(i));
M>        }
M>        return u.re( 0 );
M>    }
M>


Здесь используется не класс типа Complex, а класс типа ComplexArray.
Собственно об этом и была речь — простейшая абстракция Complex не совместима с производительностью. То есть нельзя просто отдельно создать класс Complex и положить его в отдельный стандартный массив, в стандартную deque, в стандартную priority_queue и т.п. — их приходится вручную скрещивать.
Причём если взять структуру чуть-чуть посложнее, типа {double, float, int} — то всё, приплыли капитально.

M>Конкретно здесь классов нужно избегать из-за ненужной нагрузки на GC.


В этом примере (перемножение массивов объектов Complex) — тормоза на Java будут даже без учёта GC.