2014-02-09 3 views
4

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

Имеет ли кто-либо подобный опыт? Любое предложение? Помогает ли мне писать код на 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; 
    } 


} 
+2

Во-первых, я бы не использовать 'date' сделать любой вид бенчмаркинга ... –

+0

фактор библиотека взывает. Вы не хотите сравнивать «случайные» или триггерные функции. –

+0

@ Тайлер и Майкл, я удалил функцию триггера и случайный, я также изменил дату на System.currentTimeMillis(). Но он по-прежнему в 45 раз медленнее. Сказав это, я не уверен, понимаю ли я, почему вы сказали, что я не могу использовать триггерные функции? Разве Android и Java не используют тот же алгоритм для Math.sin? – Kasra

ответ

0

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

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

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

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

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

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

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

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

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

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

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

+0

Спасибо за примечание. Просто короткая заметка, после профилирования я получил ~ 20% в триггерных функциях, 60% «я», что, я считаю, означает простые умножения, которые у меня есть ... – Kasra

+0

@ Kasra: Если я правильно интерпретирую вашу «я» ссылку , то это будут распределения памяти и встроенные операции, такие как умножения с плавающей запятой. Время, которое «украдено» у микро-бенчмарка для сбора мусора, должно появиться как пауза в Traceview, где ничего не происходит. Это предполагает одноядерный процессор; если вы используете несколько ядер, GC может работать на другом ядре, и это будет иметь ограниченное влияние на производительность. – CommonsWare

+0

@ Kasra: Обратите внимание, что теоретически JIT-компилятор должен преобразовывать ваш микро-тест в собственные инструкции. Я не знаю, как это подтвердить. Возможно, вы захотите провести некоторое исследование того, какой процессор находится в вашем планшете. Если это ARMv7, у него будет копроцессор с плавающей запятой. Если это ARMv5, это не будет. – CommonsWare

0

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

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

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

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

Существует, по меньшей мере, восемь наборов сравнений между ПК и устройствами Android для моих многочисленных тестов Android в следующем. Ниже приведены результаты теста Linpack (включая Java), которые показывают андроиды в лучшем свете, чем ваши результаты. Другие результаты (например, 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 
+0

Возможно, это глупый вопрос, но могу ли я спросить вас, что такое единица чисел, перечисленных в Linpack? Означает ли это, что чем меньше число, тем быстрее будет вычисление? Или наоборот? – Kasra

+1

MFLOPS - это миллионы операций с плавающей точкой в ​​секунду - стандартная производительность для вычислений с плавающей запятой - высокая, конечно, лучшая. –