Re[24]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 17:12
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Если какая-то библиотечная функция становится бутылочным горлышком по производительности, то я элементарно могу её не использовать (написав свою или взяв из какой-то другой библиотеки).


Если бы эта проблема была единичной.

_>При этом создание большого массива экземпляров некоторого класса работает в Firefox эффективнее, чем в .Net. Что важнее, думаю ты можешь оценить сам. )))


На самом деле нет. Единственное, что тормозило в предыдущем примере — это ToString.

_>Ну у меня он исполняется 1900 мс (вместо 1600 мс с PadLeft).


У меня — 1667. Похоже, твой "топовый Xeon" неслабо тормозит?

_>Я говорил про свой изначальный тест с вычислениями в двухмерных массивах. Там точно не использовались никакие встроенные функции, так что этот тест демонстрировал именно способности языка/компилятора/оптимизатора.


А так же не использовались объекты и динамическое выделение/освобождение памяти.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Отредактировано 17.09.2017 21:16 CodeMonkey . Предыдущая версия .
Re[7]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.09.17 17:15
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

_>>Чем что, чем C/C++? Так с этим как бы никто и не спорит... Только вот C# тут как бы не сильно далеко ушёл. )))


CM>А давай ка посмотрим на более близкий к реальности код?

CM>Как это будет на JS?

CM>                while (compare(vals[i], midVal) < 0)
CM>                {
CM>                    i++;
CM>                }

CM>                while (compare(vals[j], midVal) > 0)
CM>                {
CM>                    j--;
CM>                }


К слову про идиотов. Ты эту "сортировку" запускал ? Может взял где не глядя ?
Re[22]: Реальная производительность WebAssembly?
От: Ночной Смотрящий Россия  
Дата: 17.09.17 17:18
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ты бы в начале хотя бы ознакомился с проблемой... ))) Автор как раз форматирует не к системной (русской там или какой-то ещё), а к американской локали, указывая её явно.


Какая разница к какой именно? На перформансе это не отражается.

_> Это в JS коде (то, что подобное форматирование там вообще не нужно — это другой вопрос, который здесь уже обсудили). А C# аналога данного кода вообще в темке не было.


В C# аналог как раз обычный ToString без параметров. А вот ordinal конверсии, которая в JS по дефолту, в FW, емнип, вообще нет, только invariant culture.
Re[8]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 17:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>К слову про идиотов. Ты эту "сортировку" запускал ? Может взял где не глядя ?


Взял где, но проверял. Работает. А что не так?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[9]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.09.17 17:48
Оценка: -2 :)
Здравствуйте, CoderMonkey, Вы писали:

I>>К слову про идиотов. Ты эту "сортировку" запускал ? Может взял где не глядя ?


CM>Взял где, но проверял. Работает. А что не так?


Ога, ога, ну да, ну да
Re[7]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.09.17 18:35
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>А давай ка посмотрим на более близкий к реальности код?

CM>Как это будет на JS?

CM>

// нерабочий говнокод скипнут

CM>


К слову о реальности. В твоей, похоже, твой квиксорт вполне работает. гы-гы.

Вот порт 1-к-1 твоего кода с сохранением структуры и прочих вещей, кроме нескольких мелочей + необходимый фиксы

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

'use strict';

const N = 1000*1000;
const re = /-/g;

function Main(number) {
    let watch = Date.now();
    let vals = ToArray(Select(Range(0, number), x => new TestClass()));
    let compare = (x, y) =>{
        if(x === y)
            return 0;
        if(x > y)
            return 1;
        return -1;
    };
    console.warn(`Init, miliseconds: ${Date.now() - watch}`);
    watch = Date.now();
    QuickSort(vals, (x,y)=>compare(x.Id, y.Id));
    console.warn(`Sort miliseconds: ${Date.now() - watch}`);
}

function QuickSort(vals, compare){
    QuickSortImpl(vals, compare, 0, vals.length - 1);
}

function QuickSortImpl (vals, compare, left, right) {
    if (right <= left)
        return;

    let i = left;
    let j = right;
    const mid = Math.floor((left + right) / 2);
    const midVal = vals[mid];

    while (i <= j) {
        while (compare(vals[i], midVal) > 0) {
            i++;
        }

        while (compare(vals[j], midVal) < 0) {
            j--;
        }

        if (i <= j) {
            const tmp = vals[i];
            vals[i] = vals[j];
            vals[j] = tmp;

            i++;
            j--;
        }
    }

    if(left < i - 1) {
        QuickSortImpl(vals, compare, left, i - 1);
    }

    if(right > i) {
        QuickSortImpl(vals, compare, i, right);
    }
}

class TestClass {
    constructor() {
        this.Id = CreateGuid();
        this.Value = CreateGuid();
    }

    toString() {
        return this.Id;
    }
}

function ToArray(iterator) {
    return [...iterator];
}

function* Range(start, end) {
    for(let i = start; i<end; i++) {
        yield i;
    }
}

function* Select(iterator, projector) {
    for(let x of iterator) {
        yield projector(x);
    }
}

function CreateGuid() {
    return NewGuid().toString().replace(re, "");
}

function NewGuid() {
    function s4() {
        return (Math.floor((1 + Math.random()) * 0x10000) & 0xFFFF)
            .toString(16);
    }
    return s4() + s4() + '-' + s4() + '-' + s4() + '-' +
        s4() + '-' + s4() + s4() + s4();
}

function delay(time) {
    return new Promise((resolve)=>{
        setTimeout(resolve, time);
    });
}

for(let i = 0, promise = Promise.resolve(); i<100;i++) {
    promise = promise.then(()=>Main(N)).then(()=>delay(1000));
}
Отредактировано 19.09.2017 10:42 Pauel . Предыдущая версия . Еще …
Отредактировано 19.09.2017 10:39 Pauel . Предыдущая версия .
Отредактировано 17.09.2017 18:42 Pauel . Предыдущая версия .
Отредактировано 17.09.2017 18:36 Pauel . Предыдущая версия .
Re[10]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 19:03
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Ога, ога, ну да, ну да


Если есть конкретный пример, когда тот код не работает корректно — давай его сюда. Хватит балаболить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[8]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 19:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>не выйдет, тк в js отсутствует guid.


Это типа должно считаться достоинством JS?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[9]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.09.17 19:13
Оценка: -1 :)
Здравствуйте, CoderMonkey, Вы писали:

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


I>>не выйдет, тк в js отсутствует guid.


CM>Это типа должно считаться достоинством JS?


Именно. JS это только язык, с библиотекой минимально покрывающей языковые фичи. Благодаря этому его легко протащить куда угодно.
Он и есть практически везде.
Re[10]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 17.09.17 20:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Именно. JS это только язык, с библиотекой минимально покрывающей языковые фичи. Благодаря этому его легко протащить куда угодно.

I>Он и есть практически везде.

А потом начинается "веселье" с разнокалиберными фреймворками для сепулькации сепулькаторов и фичами, "которые невозможно полностью повторить". Зато у разработчиков рантайма голова не болит. Пусть болит у тех, кто его использует.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[25]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 18.09.17 04:55
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

_>>При этом создание большого массива экземпляров некоторого класса работает в Firefox эффективнее, чем в .Net. Что важнее, думаю ты можешь оценить сам. )))

CM>На самом деле нет. Единственное, что тормозило в предыдущем примере — это ToString.

Ну так и что, это совсем редко используемая в работе функция? )))

_>>Ну у меня он исполняется 1900 мс (вместо 1600 мс с PadLeft).

CM>У меня — 1667. Похоже, твой "топовый Xeon" неслабо тормозит?

Я же уже говорил, что у нас наверняка разные .net рантаймы (у меня 4.6.0081.0). Только вот у большинства пользователей (т.к. сейчас доминирующей десктопной ОС является Win7) стоит ещё даже более старая, чем у меня. )))

_>>Я говорил про свой изначальный тест с вычислениями в двухмерных массивах. Там точно не использовались никакие встроенные функции, так что этот тест демонстрировал именно способности языка/компилятора/оптимизатора.

CM>А так же не использовались объекты и динамическое выделение/освобождение памяти.

Так это оказывается было ещё в пользу .net сравнение. Потому как взяв твой пример теста (с объектами и динамическим выделением памяти), я бы получил проигрыш .net'а в разы...
Re[23]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 18.09.17 04:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Ты бы в начале хотя бы ознакомился с проблемой... ))) Автор как раз форматирует не к системной (русской там или какой-то ещё), а к американской локали, указывая её явно.

НС>Какая разница к какой именно? На перформансе это не отражается.
_>> Это в JS коде (то, что подобное форматирование там вообще не нужно — это другой вопрос, который здесь уже обсудили). А C# аналога данного кода вообще в темке не было.
НС>В C# аналог как раз обычный ToString без параметров. А вот ordinal конверсии, которая в JS по дефолту, в FW, емнип, вообще нет, только invariant culture.

Ну давай, расскажи, как бы ты сделал форматирование числа с фиксированной шириной с помощью функции "ToString без параметров".

P.S. Похоже что ты реально стал отвечать в темках, даже минимально не разобравшись — это уже какая-то деградация... (
Re[24]: Реальная производительность WebAssembly?
От: Ночной Смотрящий Россия  
Дата: 18.09.17 05:39
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Ну давай, расскажи, как бы ты сделал форматирование числа с фиксированной шириной с помощью функции "ToString без параметров".


Лучше сравнивать с ordinal конверсией, да?

_>P.S. Похоже что ты реально стал отвечать в темках, даже минимально не разобравшись — это уже какая-то деградация... (


Перешел на личности — слил.
Re[25]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 18.09.17 06:21
Оценка: :)
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Ну давай, расскажи, как бы ты сделал форматирование числа с фиксированной шириной с помощью функции "ToString без параметров".

НС>Лучше сравнивать с ordinal конверсией, да?

Так, давай разберёмся с начала, хотя уже даже не знаю зачем я трачу на подобную чушь минуту своего времени. Автор темки написал некий код на JS, который производил форматирование числа в строку фиксированной ширины с помощью функции национального форматирования. Так вот даже подобный глупый и неуместный в тестах код (его бредовость мы тут обсудили отдельно) надо сравнивать с эквивалентным ему кодом на другом языке (в данном случае C#). А эквивалентного примера на C# автором представлено не было — именно его я и добивался (и кстати в итоге он его без проблем представил), когда ты влез в дискуссию с "очень ценным" замечанием, что ToString без параметров использует системную локаль.

В общем лучше в начале читай всю темку, в которой что-то отвечаешь, а не одно последнее сообщение.
Re[26]: Реальная производительность WebAssembly?
От: Ночной Смотрящий Россия  
Дата: 18.09.17 07:08
Оценка: +3
Здравствуйте, alex_public, Вы писали:

_>Так, давай разберёмся с начала, хотя уже даже не знаю зачем я трачу на подобную чушь минуту своего времени. Автор темки написал некий код на JS, который производил форматирование числа в строку фиксированной ширины с помощью функции национального форматирования. Так вот даже подобный глупый и неуместный в тестах код (его бредовость мы тут обсудили отдельно) надо сравнивать с эквивалентным ему кодом на другом языке (в данном случае C#).


Автор, очевидно, в отличие от тебя в курсе, что по умолчанию в C# конверсия использует культуру, что сильно замедляет код. А то что JS код недостаточно эквивалентен объясняется недостаточным знанием JS у автора (что он и не скрывает).
Стоило просто поправить его код. Но ты предпочел полить помоями автора, а затем и меня.
Re[27]: Реальная производительность WebAssembly?
От: alex_public  
Дата: 18.09.17 07:29
Оценка: -1 :))
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Так, давай разберёмся с начала, хотя уже даже не знаю зачем я трачу на подобную чушь минуту своего времени. Автор темки написал некий код на JS, который производил форматирование числа в строку фиксированной ширины с помощью функции национального форматирования. Так вот даже подобный глупый и неуместный в тестах код (его бредовость мы тут обсудили отдельно) надо сравнивать с эквивалентным ему кодом на другом языке (в данном случае C#).

НС>Автор, очевидно, в отличие от тебя в курсе, что по умолчанию в C# конверсия использует культуру, что сильно замедляет код. А то что JS код недостаточно эквивалентен объясняется недостаточным знанием JS у автора (что он и не скрывает).
НС>Стоило просто поправить его код. Но ты предпочел полить помоями автора, а затем и меня.

Вообще то я как раз именно так и сделал: http://rsdn.org/forum/flame.comp/6904643.1
Автор: alex_public
Дата: 15.09.17
. Т.е. ты сейчас идеально подтвердил моё предположение о том, что ты стал писать на форуме вообще не читая предыдущие обсуждения и даже не понимая о чём реально речь.
Re[11]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.09.17 11:34
Оценка: -1 :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Именно. JS это только язык, с библиотекой минимально покрывающей языковые фичи. Благодаря этому его легко протащить куда угодно.

I>>Он и есть практически везде.

CM>А потом начинается "веселье" с разнокалиберными фреймворками для сепулькации сепулькаторов и фичами, "которые невозможно полностью повторить". Зато у разработчиков рантайма голова не болит. Пусть болит у тех, кто его использует.


Ничего не болит, это я тебе как JavaScript разработчик говорю. Я больше 10 лет на дотнете писал. Из за тяжелых фремворков геморроя гораздо больше.
Когда фремворк не делает того что надо, или делает не так как надо, часто вообще никаких способов обойти нет

А вот в JavaScript такие вещи гораздо реже встречаются. Это первое, что я заметил, когда пересел на JavaScript.
Re[11]: Реальная производительность WebAssembly?
От: alexzzzz  
Дата: 18.09.17 12:27
Оценка: +4
Здравствуйте, CoderMonkey, Вы писали:

CM>Какой идиот сравнивает разные реализации?


Протестую!

Безотносительно того, что пытаются сравнивать в этой теме (даже не вникал в код), сравнивать имеет смысл только время выполнения кода, который решает поставленную задачу. На вход подаются реальные данные, потом что-то происходит и получается результат. Как результат был получен, какие конкретные средства языка использовались — вообще неинтересно. Языки разные, возможности у них разные, особенности разные, библиотеки разные. Нет смысла сравнивать время работы кода на языке А со временем работы его дословного перевода на язык Б, потому что никто в реале не будет писать код на языке Б так, как если бы это был язык А.

Неоптимизированные по скорости реализации тоже нет смысла сравнивать. Если ты пишешь на языке А, и какой-то код работает медленнее чем хочется, то ты естественно сначала будешь оптимизировать его в рамках языка А, а в сторону языка Б начнёшь смотреть, только если все доступные оптимизации не дадут желаемого результата.

Таким образом, берём решение задачи, оптимизированное по скорости средствами языка А, берём решение задачи, оптимизированное по скорости средствами языка Б, и сравниваем их между собой. Любые другие сравнения лишены практического смысла.
Отредактировано 18.09.2017 12:29 alexzzzz . Предыдущая версия .
Re[13]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.09.17 12:32
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

_>>Я собственно уже всё показал, со всеми измерениями и т.п. Ссылка имеется выше. Теперь твоя очередь, раз тебе не очень нравится мой вариант теста — покажи свой. )


CM>Начнем с чего-нибудь простого.

CM>Сколько времени выполняется код и сколько отжирается памяти?

К слову о тестах — 1 твой тест не работает 2 если пофиксить, то он не замеряет память

Итак, после фиксов, результаты

С#
инициализация       1.8 секунды
сортировка          4.7 секунды

JS 
инициализация       5.5 секунды
сортировка          1.5 секунды


Как видишь, JS уже вполне себе на уровне C# работает, и даже может его обставлять. Ровно то, о чем я тебе и говорил
Re[28]: Реальная производительность WebAssembly?
От: Ночной Смотрящий Россия  
Дата: 18.09.17 12:34
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вообще то я как раз именно так и сделал: http://rsdn.org/forum/flame.comp/6904643.1
Автор: alex_public
Дата: 15.09.17
.


Заменив на toString, работающую по самому примитивному алгоритму? Ну так я тебе уже сказал, что это намного хуже, чем исходный вариант.

_> Т.е. ты сейчас идеально подтвердил моё предположение о том, что ты стал писать на форуме вообще не читая предыдущие обсуждения и даже не понимая о чём реально речь.


Не, это ты в очередной раз слил.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.