Производительность выделения памяти Java (SunOS против Windows)

Процессор действительно медленнее на SPARC (1,2 ГГц), и, как ответил один из инженеров Sun, T2 обычно в 3 раза медленнее для однопоточного приложения, чем современные процессоры Intel. Хотя он также заявил, что в многопоточной среде SPARC должен работать быстрее.

Я сделал многопоточный тест с использованием библиотеки GroboUtils и протестировал как выделение (через конкатенацию), так и простые вычисления ( a += j*j ) для тестирования процессора. И у меня есть следующие результаты:

1 thread : Intel : Calculations test : 43ms
100 threads : Intel : Calculations test : 225ms

1 thread : Intel : Allocations test : 35ms
100 threads : Intel : Allocations test : 1754ms

1 thread : SPARC : Calculations test : 197ms
100 threads : SPARC : Calculations test : 261ms

1 thread : SPARC : Allocations test : 236ms
100 threads : SPARC : Allocations test : 1517ms

SPARC демонстрирует здесь свою мощь, опережая Intel на 100 потоках.

Вот тест многопоточного расчета:

import java.util.ArrayList;
import java.util.List;

import net.sourceforge.groboutils.junit.v1.MultiThreadedTestRunner;
import net.sourceforge.groboutils.junit.v1.TestRunnable;
import junit.framework.TestCase;

public class TM1_CalculationSpeedTest extends TestCase {

    public void testCalculation() throws Throwable {

        List threads = new ArrayList();
        for (int i = 0; i < 100; i++) {
            threads.add(new Requester());
        }
        MultiThreadedTestRunner mttr = new MultiThreadedTestRunner((TestRunnable[]) threads.toArray(new TestRunnable[threads.size()]));
        mttr.runTestRunnables(2 * 60 * 1000);

    }

    public class Requester extends TestRunnable {

        public void runTest() throws Exception {
            long startTime = System.currentTimeMillis();
            long a = 0;
            for (int j = 0; j < 10000000; j++) {
                a += j * j;
            }
            long endTime = System.currentTimeMillis();
            System.out.println(this + ": " + (endTime - startTime) + "ms " + a);
        }

    }

}

Вот тест многопоточного распределения:

import java.util.ArrayList;
import java.util.List;

import junit.framework.TestCase;
import net.sourceforge.groboutils.junit.v1.MultiThreadedTestRunner;
import net.sourceforge.groboutils.junit.v1.TestRunnable;

public class TM2_AllocationSpeedTest extends TestCase {

    public void testAllocation() throws Throwable {

        List threads = new ArrayList();
        for (int i = 0; i < 100; i++) {
            threads.add(new Requester());   
        }
        MultiThreadedTestRunner mttr = new MultiThreadedTestRunner((TestRunnable[]) threads.toArray(new TestRunnable[threads.size()]));
        mttr.runTestRunnables(2 * 60 * 1000);

    }

    public class Requester extends TestRunnable {

        public void runTest() throws Exception {
            long startTime = System.currentTimeMillis();
            String a = "dummy";
            for (int j = 0; j < 1000; j++) {
                a += "allocation driven";
            }
            long endTime = System.currentTimeMillis();
            System.out.println(this + ": " + (endTime - startTime) + "ms " + a.length());
        }

    }

}

Насколько я понимаю, машины на базе UltraSPARC T2 нацелены на производительность на ватт, а не на чистую производительность. Вы можете попробовать разделить время выделения на энергопотребление и посмотреть, какие числа вы получите. :)

Есть ли причина, по которой вы используете 1.4.2 вместо 1.6?

Аппаратное обеспечение SunOS медленнее, и виртуальная машина также может быть несколько медленнее.

Я не думаю, что это измерение распределения памяти. Во-первых, в a += "allocation driven"; происходит очень много копирования персонажей. Но я подозреваю, что реальное узкое место заключается в получении вывода от System.out.println(...) через сетевые уровни из приложения на сервере Sun на вашу удаленную рабочую станцию.

В качестве эксперимента попробуйте умножить число внутренних циклов на 10 и 100 и посмотрите, «ускорит» ли это работу сервера Sun по сравнению с вашей рабочей станцией.

Еще одна вещь, которую вы можете попробовать, это переместить внутренний цикл в отдельную процедуру. Возможно, поскольку вы выполняете всю работу за один вызов main, JIT-компилятор никогда не сможет ее скомпилировать.

(Такие искусственные «микротесты» всегда подвержены подобным эффектам. Я склонен им не доверять.)