Производителност на Node.js / coffeescript на интензивен алгоритъм с математика

Както посочиха други отговорили, масивите на JavaScript са основно затруднение в производителността за типа операции, които извършвате. Тъй като те са динамични, достъпът до елементи естествено е много по-бавен, отколкото при статичните масиви на Java.

Добрата новина е, че има нововъзникващ стандарт за статично въведени масиви в JavaScript, който вече се поддържа в някои браузъри. Въпреки че все още не се поддържат в самия възел, можете лесно да ги добавите с библиотека: https://github.com/tlrobinson/v8-typed-array

След като инсталирах typed-array чрез npm, ето моята модифицирана версия на вашия код:

{Float32Array} = require 'typed-array'

genHeightField = (sz) ->
    timeStart = new Date()
    DATA_SIZE = sz
    SEED = 1000.0
    iters = 0

    # Initialize 2D array of floats
    data = new Array(DATA_SIZE)
    for rows in [0...DATA_SIZE]
      data[rows] = new Float32Array(DATA_SIZE)
      for cols in [0...DATA_SIZE]
          data[rows][cols] = 0

    # The rest is the same...

Ключовият ред там е декларацията на data[rows].

С ред data[rows] = new Array(DATA_SIZE) (по същество еквивалентен на оригинала) получавам референтните числа:

17
75
417
1376
5461

И с реда data[rows] = new Float32Array(DATA_SIZE) получавам

19
47
215
855
3452

Така че една малка промяна намалява времето за работа с около 1/3, т.е. 50% увеличение на скоростта!

Все още не е Java, но е доста съществено подобрение. Очаквайте бъдещите версии на Node/V8 да намалят допълнително разликата в производителността.

Предупреждение: Трябва да се спомене, че нормалните JS числа са с двойна точност, т.е. 64-битови плаващи числа. По този начин използването на Float32Array ще намали прецизността, правейки това малко сравнение на ябълки и портокали — не знам каква част от подобрението на производителността е от използването на 32-битова математика и каква е от по-бърз достъп до масив. Float64Array е част от спецификацията на V8, но все още не е внедрено в v8-typed-array библиотека.)

Ако търсите производителност в алгоритми като този, и кафе/js, и Java са грешните езици, които да използвате. Javascript е особено лош за проблеми като този, защото няма тип масив - масивите са просто хеш карти, където ключовете трябва да са цели числа, което очевидно няма да бъде толкова бързо, колкото истински масив. Това, което искате, е да напишете този алгоритъм на C и да го извикате от възел (вижте http://nodejs.org/docs/v0.4.10/api/addons.html). Освен ако не сте наистина добри в ръчното оптимизиране на машинния код, добрият C лесно ще изпревари всеки друг език.

Забравете за Coffeescript за минута, защото това не е коренът на проблема. Този код така или иначе просто се записва в обикновен стар javascript, когато node го изпълнява.

Точно като всяка друга javascript среда, възелът е еднонишков. Двигателят V8 е адски бърз, но за определени видове приложения може да не успеете да надвишите скоростта на jvm.

Първо бих препоръчал да се опитате да коригирате алгоритъма си с диамант директно в js, преди да преминете към CS. Вижте какви видове оптимизации на скоростта можете да направите.

Всъщност и аз се интересувам от този проблем сега и ще разгледам как да направя това.

Редактиране #2 Това е второто ми презаписване с някои оптимизации, като например предварително попълване на масива от данни. Не е значително по-бърз, но кодът е малко по-чист.

var makegrid = function(size){
    size++; //increment by 1

    var grid = [];
        grid.length = size,
        gsize = size-1; //frequently used value in later calculations.

    //setup grid array
    var len = size;
    while(len--){
        grid[len] = (new Array(size+1).join(0).split('')); //creates an array of length "size" where each index === 0
    }

    //populate four corners of the grid
    grid[0][0] = grid[gsize][0] = grid[0][gsize] = grid[gsize][gsize] = corner_vals;

    var side_length = gsize;

    while(side_length >= 2){
        var half_side = Math.floor(side_length / 2);

        //generate new square values
        for(var x=0; x<gsize; x += side_length){
            for(var y=0; y<gsize; y += side_length){

                //calculate average of existing corners            
                var avg = ((grid[x][y] + grid[x+side_length][y] + grid[x][y+side_length] + grid[x+side_length][y+side_length]) / 4) + (Math.random() * (2*height_range - height_range));

                //calculate random value for avg for center point
                grid[x+half_side][y+half_side] = Math.floor(avg);

            }
        }

        //generate diamond values
        for(var x=0; x<gsize; x+= half_side){
            for(var y=(x+half_side)%side_length; y<gsize; y+= side_length){

                var avg = Math.floor( ((grid[(x-half_side+gsize)%gsize][y] + grid[(x+half_side)%gsize][y] + grid[x][(y+half_side)%gsize] + grid[x][(y-half_side+gsize)%gsize]) / 4) + (Math.random() * (2*height_range - height_range)) );

                grid[x][y] = avg;

                if( x === 0) grid[gsize][y] = avg;
                if( y === 0) grid[x][gsize] = avg;
            }
        }

        side_length /= 2;
        height_range /= 2;
    }

    return grid;
}

makegrid(256)
makegrid(512)
makegrid(1024)
makegrid(2048)
makegrid(4096)

Винаги съм предполагал, че когато хората описват времето за изпълнение на javascript като „бързо“, те имат предвид спрямо други интерпретирани, динамични езици. Сравнение с ruby, python или smalltalk би било интересно. Сравняването на JavaScript с Java не е честно сравнение.

За да отговоря на въпроса ви, смятам, че резултатите, които виждате, са показателни за това какво можете да очаквате, сравнявайки тези два изключително различни езика.