Вычислительная мощность - мобильные устройства и настольные компьютеры - разница в 100 раз?

Кто-нибудь сравнивал вычислительную мощность мобильных устройств с ПК? У меня очень простая матричная работа. При кодировании на Java моему старому ПК требуется ~ 115 мсек, чтобы завершить работу. ОЧЕНЬ ОЧЕНЬ ЖЕ ФУНКЦИЯ занимает 17000 мс. Я был очень шокирован. Я не ожидал, что планшет будет близко к ПК - но и не ожидал, что он будет примерно в 150 раз медленнее !!

У кого-нибудь был подобный опыт? Любое предложение? Помогает ли, если я пишу код на C и использую Android NDK?

Код теста на Java:

package mainpackage;

import java.util.Date;



public class mainclass {

    public static void main(String[] args){

        Date startD  = new Date();
        double[][] testOut;
        double[] v = {1,0,0};
        double t;
        for (int i = 0; i < 100000; i++) {
            t=Math.random();
            testOut=rot_mat(v, t);
        }
        Date endD  = new Date();
        System.out.println("Time Taken ms: "+(-startD.getTime()+endD.getTime()));


    }

    public static double[][] rot_mat(double v[], double t)
    {
           double absolute;
           double x[] = new double[3];
           double temp[][] =  new double[3][3];
           double temp_2[][] =  new double[3][3];
           double sum;
           int i;
           int k;
           int j;

           // Normalize the v matrix into k
           absolute = abs_val_vec(v);
           for (i = 0; i < 3; i++)
           {
               x[i] = v[i] / absolute;
           }


           // Create 3x3 matrix kx
           double kx[][] = {{0, -x[2], x[1]}, 
                              {x[2], 0, -x[0]},
                              {-x[1], x[0], 0}};
           // Calculate output
           // Calculate third term in output
           for (i = 0; i < 3; i++)
           {
               for (j = 0; j < 3; j++)
               {
                   sum = 0;
                   for (k = 0; k < 3; k++)
                   {
                       sum = sum + kx[i][k] * kx[k][j];
                   }
                   temp[i][j] = (1-Math.cos(t))*sum;
               }
           }
           // Calculate second term in output
           for (i = 0; i < 3; i++)
           {
               for (k = 0; k < 3; k++)
               {
                   temp_2[i][k] = Math.sin(t)*kx[i][k];
               }
           }


           // Calculate output
           double[][] resOut = new double[3][3];
           for (i = 0; i < 3; i++)
           {
               for (k = 0; k < 3; k++)
               {
                   resOut[i][k] = temp_2[i][k] + temp[i][k] + ((i==k)?1:0);
               }
           }
        return resOut;

    }



    private static double abs_val_vec (double v[])
    {
           double output;

           output = Math.sqrt(v[0]*v[0] + v[1]*v[1] + v[2]*v[2]);

           return output;
    }


}

person Kasra    schedule 09.02.2014    source источник
comment
Во-первых, я бы не стал использовать Date для каких-либо тестов ...   -  person Tyler MacDonell    schedule 10.02.2014
comment
Фактор, который требует библиотека. Вы не хотите тестировать random или триггерные функции.   -  person Michael Petrotta    schedule 10.02.2014
comment
@Tyler и Майкл, я удалил функцию триггера и random, я также изменил дату на System.currentTimeMillis (). Но он все равно в 45 раз медленнее. Сказав это, я не уверен, понимаю ли я, почему вы сказали, что я не могу использовать триггерные функции? Разве Android и Java не используют один и тот же алгоритм для Math.sin?   -  person Kasra    schedule 10.02.2014
comment
Если вы делаете это с подключенным отладчиком, отсоедините его - вы увидите значительное увеличение скорости.   -  person Adam S    schedule 10.02.2014


Ответы (3)


Любое предложение?

Микро-тесты измеряют только производительность микро-теста. И единственный достойный способ интерпретировать микротесты - это микроизмерения. Следовательно, опытные программисты будут использовать такие инструменты, как Traceview, чтобы лучше понимать, на что они тратят время.

Я подозреваю, что если вы прогоните это через Traceview и посмотрите на LogCat, вы обнаружите, что ваше время тратится на две области:

  1. Выделение памяти и сборка мусора. Ваш микротест занимает ~ 3 МБ места в куче. В производственном коде вы бы никогда этого не сделали, по крайней мере, если бы вы хотели сохранить свою работу.

  2. Операции с плавающей запятой. В зависимости от вашего планшета, у вас может не быть сопроцессора с плавающей запятой, и выполнение математических вычислений с плавающей запятой на ЦП без сопроцессора с плавающей запятой происходит очень-очень медленно.

Помогает ли, если я пишу код на C и использую Android NDK?

Что ж, пока вы не профилируете код в Traceview, на это будет сложно ответить. Например, если время в основном тратится на sqrt(), cos() и sin(), это уже является собственным кодом, и вы не станете намного быстрее.

Что еще более важно, даже если этот микро-тест может быть улучшен с помощью нативного кода, все, что он делает, это демонстрирует, что этот микро-тест может быть улучшен с помощью нативного кода. Например, перевод этого текста на C может быть быстрее из-за ручного управления кучей (malloc() и free()), а не сборки мусора. Но это скорее обвинение в том, насколько плохо был написан микротест, чем утверждение о том, насколько быстрее будет C, поскольку производственный код Java будет оптимизирован лучше, чем этот.

Помимо изучения того, как использовать Traceview, я предлагаю:

  • Чтение документации NDK, поскольку она включает информацию о том, когда собственный код может создавать смысл.

  • Чтение по Renderscript Compute. На некоторых устройствах использование Renderscript Compute может выгружать целочисленные вычисления на графический процессор для значительного повышения производительности. Это не поможет вашему микробенчмарку с плавающей запятой, но для других матричных вычислений (например, обработки изображений) Renderscript Compute, возможно, стоит изучить.

person CommonsWare    schedule 09.02.2014
comment
Спасибо за заметку. Просто небольшое примечание: после профилирования я получил ~ 20% в триггерных функциях, 60% на себя, что, как я считаю, означает простые умножения, которые у меня есть ... - person Kasra; 10.02.2014
comment
@Kasra: Если я правильно интерпретирую вашу ссылку на себя, то это будут выделения памяти и встроенные операции, такие как умножение с плавающей запятой. Время, украденное из микротеста для сборки мусора, должно отображаться в виде пауз в Traceview, где кажется, что ничего не происходит. Это предполагает одноядерный процессор; если вы используете несколько ядер, сборщик мусора может работать на другом ядре, и это окажет ограниченное влияние на производительность. - person CommonsWare; 10.02.2014
comment
@Kasra: Обратите внимание, что теоретически JIT-компилятор должен преобразовывать ваш микротест в собственные инструкции. Я не знаю, как это подтвердить. Возможно, вы захотите узнать, какой процессор в вашем планшете. Если это ARMv7, у него будет сопроцессор с плавающей запятой. Если это ARMv5, то не будет. - person CommonsWare; 10.02.2014

Одна только вычислительная мощность - это еще не все, когда вы сравниваете очень разные архитектуры. Фактически, вы, скорее всего, будете тестировать не только вычислительные архитектуры.

Ключевой фактор в сравнительном анализе. Когда вы имеете дело с чем-то, что учитывает множество переменных, выделите тот, который вы хотите протестировать, и оставьте другие постоянными и желательно равными.

В вашей ситуации несколько примеров переменных, которые влияют на ваш результат:

  • фактическая вычислительная архитектура, которая сама по себе представляет собой сложный набор переменных (дизайн и реализация процессора, иерархия памяти и т. д.)
  • ОС
  • другая реализация виртуальной машины Java для различных переменных, указанных выше
  • дополнительные слои, которые Dalvik предполагает
person webuster    schedule 09.02.2014

Ниже приводится по крайней мере восемь наборов сравнений ПК и устройств Android для моих многочисленных тестов Android. Ниже приведены результаты моего теста Linpack (включая Java), которые показывают Android в лучшем свете, чем ваши результаты. Другие результаты (например, Dhrystone) показывают, что в расчете на тактовую частоту процессоры ARM могут соответствовать процессорам Intel.

http://www.roylongbottom.org.uk/android%20benchmarks.htm

 Linpack Benchmark Results

 System   ARM    MHz   Android  Linpackv5  Linpackv7  LinpackSP NEONLinpack LinpackJava
 See                              MFLOPS     MFLOPS     MFLOPS     MFLOPS     MFLOPS

  T1    926EJ    800       2.2      5.63       5.67       9.61       N/A        2.33
  P4    v7-A8    800     2.3.5                80.18                            28.34 @G
  T2    v7-A9    800     2.3.4     10.56     101.39     129.05     255.77      33.36
  P5    v7-A9   1500     4.0.3               171.39                            50.87 @G
  T4    v7-A9   1500a    4.0.3     16.86     155.52     204.61     382.46      56.89
  T6    v7-A9   1600     4.0.3               196.47
  T7    v7-A9   1300a    4.1.2     17.08     151.05     201.30     376.00      56.44
  T9    926EJ    800       2.2      5.66
  T11   v7-A15  2000b    4.2.2     28.82     459.17     803.04    1334.90     143.06
  T12   v7-A9   1600     4.1.2               147.07
  T14   v7-A9   1500     4.0.4               180.95

  P11   v7-A9   1400     4.0.4     19.89     184.44     235.54     454.21      56.99
  P10   QU-S4   1500     4.0.3               254.90

 Measured MHz a=1200, b=1700 


         Atom   1666     Linux               204.09     215.73                117.81
         Atom   1666   Windows               183.22                           118.70
         Atom   1666   And x86                                                 15.65
        Core 2  2400     Linux              1288.00                           901.00
        Core 2  2400   Windows              1315.29                           551.00
        Core 2  2400   And x86                                                 53.27

 System - T = Tablet, P = Phone, @G = GreenComputing, QU = Qualcomm CPU
 And 86 = Android x86
person Roy Longbottom    schedule 10.02.2014
comment
Может быть, это глупый вопрос, но могу ли я спросить, каковы единицы измерения чисел, перечисленных в Linpack? Означает ли это, что чем меньше число, тем быстрее будут вычисления? Или наоборот? - person Kasra; 10.02.2014
comment
MFLOPS - это миллионы операций с плавающей запятой в секунду - стандартный показатель производительности для вычислений с плавающей запятой - конечно, лучше всего. - person Roy Longbottom; 11.02.2014