Re[74]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 30.10.17 20:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А что, по твоему, мы замерили в инициализации в JS ? Как раз то, что тормозит.


А надо было измерять только то, что в JS не тормозит?
Проблемы индейцев шерифа не волнуют.

I>Минимальное, потому что в JS, в отличие от C#, GC слишком сильно вмешивается в работу основного потока. И много других фокусов происходит, которых в C# нет.


Проблемы индейцев...

I>Итого — по существу возражений нет ?


По существу, экспериментальные технологии — в жопу. Когда будет релиз, тогда и будет замерять.

I>До кучи — .Net Jit более качественный, чем JS. А это значит, что разница в железе на JS видна слабее. Что вобщем очевидно. Кроме того, JS сам по себе дает больше промахов по кешу, т.е. влияние проца и кеша будет меньше.

I>Есть еще один нюанс — версии рантаймов .Net у нас разные. Здесь тоже есть отличия. А это значит, что железо, возможно, отличается не в двое, а меньше. Это тоже нужно учитывать.

Ты так и не объяснил, почему самый быстрый результат у меня соответствует твоему, при твоем намного более слабом железе.

I>Напоследок — я то пофиксил и сортировку в C#, а ты замеряешь свой "алгоритм" у которого всего лишь асимптотика такая же, а абсолютно число компараций отличается. Хы-хы.


То есть ты ее "пофиксил" так, что она стала больше тормозить?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[75]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.10.17 10:54
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>А что, по твоему, мы замерили в инициализации в JS ? Как раз то, что тормозит.


CM>А надо было измерять только то, что в JS не тормозит?


В JS мы замеряем ровно то, что и нужно было замерить.

I>>Итого — по существу возражений нет ?

CM>По существу, экспериментальные технологии — в жопу. Когда будет релиз, тогда и будет замерять.

По существу — ты понимаешь, что рантаймы разные, но не понимаешь, что в разных рантаймах разная производительность

I>>До кучи — .Net Jit более качественный, чем JS. А это значит, что разница в железе на JS видна слабее. Что вобщем очевидно. Кроме того, JS сам по себе дает больше промахов по кешу, т.е. влияние проца и кеша будет меньше.

I>>Есть еще один нюанс — версии рантаймов .Net у нас разные. Здесь тоже есть отличия. А это значит, что железо, возможно, отличается не в двое, а меньше. Это тоже нужно учитывать.

CM>Ты так и не объяснил, почему самый быстрый результат у меня соответствует твоему, при твоем намного более слабом железе.


Снова краткий пересказ последних серий:
1. запуск на ___разных___ рантаймах даёт разную производительность. Ты снова забыл что мои замеры приведены для экспериментального рантайма. На другом рантайме они другие, о чем я тебе много раз сообщал.
2. В сортировке узкое место — частота памяти и шина, т.к. кеш постоянно инвалидируется, а вычислений внутри проца очень мало. У тебя ведь DDR3, не так ли ? Или ты думаешь проц магически перетасовывает значения в памяти мимо шины ?
3. разброс никто не отменял, ты сам это видишь
4. Более слабое железо — это __предположение__. Какая именно разница — вывод сделан по замерам C#. Но здесь не всё гладко (код, фремворк и тд).

Вот скажем п.1 и п.2 тебе хорошо понятны ?

I>>Напоследок — я то пофиксил и сортировку в C#, а ты замеряешь свой "алгоритм" у которого всего лишь асимптотика такая же, а абсолютно число компараций отличается. Хы-хы.


CM>То есть ты ее "пофиксил" так, что она стала больше тормозить?


Наоборот, мой вариант C# работает быстрее, а твой не факт что сортировкой является, только асимптотика похожая.
Хочешь сравнить яблоки с яблоками — надо запустить один и тот же рантайм и у меня, и у тебя. Какая была версия твоего хрома на момент замеров я не знаю, а ты понять не можешь, почему это важно.
Re[76]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 31.10.17 16:46
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>В JS мы замеряем ровно то, что и нужно было замерить.


А то, что в JS тормозит, естественно, замерять не нужно

I>Наоборот, мой вариант C# работает быстрее


Если твой работает быстрее, то почему у тебя получается настолько медленнее? Чувак, ты просто совсем заврался.

I>а твой не факт что сортировкой является, только асимптотика похожая.


Тесткейс или хватит балаболить.

I>Хочешь сравнить яблоки с яблоками — надо запустить один и тот же рантайм и у меня, и у тебя. Какая была версия твоего хрома на момент замеров я не знаю, а ты понять не можешь, почему это важно.


Последний релиз, естественно. Я вижу, тебе никак не надоест юлить?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[77]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.11.17 10:45
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>В JS мы замеряем ровно то, что и нужно было замерить.

CM>А то, что в JS тормозит, естественно, замерять не нужно

. Полагаю, ты думаешь, что замер инициализации появился сам собой ? Если ты перепишешь yield на энергичный цикл, то инициализация в JS ускоряется в три раза. Это означет, что мы замерили ровно то, что нужно — и ту часть, что быстро работает(сортировка), и ту часть, что медленно(yield).
Более того — именно когда я заметил этот факт, я решил поделить тест на две части, что бы медленное сравнивать с медленным, быстрое — с быстрым.

I>>Наоборот, мой вариант C# работает быстрее

CM>Если твой работает быстрее, то почему у тебя получается настолько медленнее? Чувак, ты просто совсем заврался.

Ты еще раз приведи, что тебя смущает, с указанием точных версий тестов и рантаймов. А то опять окажется, что всё дело в CompareOrdinal и в том, что ты сравниваешь разные версии алгоритмов/рантаймов/железа между собой.
Пока что ты только орёшь, без аргументов, что я де наврал Меня это забавляет. Не заметно ?

Мне в очередной раз стало интересно:
— если сравнить версии нода от 6й до 9й, то внезапно окажется, что где то посередине перформанс _падает_ на сортировке, при чем значительно, около 15%.
— на имеющемся железе(разные компы) сортировка работает в районе 1600+-200мс. А вот инициализация от 2500 до 6500мс. node 8.8.1 64

Подозреваю тебя смущает именно такие аномалии. Они все объяснимы. Более того — я уже объяснил каждую по отдельности Есть сомнения, что ты понимаешь, о чем речь.

I>>а твой не факт что сортировкой является, только асимптотика похожая.

CM>Тесткейс или хватит балаболить.

Как раз тебе надо доказать, что твоя модификация 1 сортирует и 2 не хуже стандартной. С тем, что она отличается, ты не возражаешь, так ? То есть, ты придумал _какойто_ алгоритм. Гы-гы.

I>>Хочешь сравнить яблоки с яблоками — надо запустить один и тот же рантайм и у меня, и у тебя. Какая была версия твоего хрома на момент замеров я не знаю, а ты понять не можешь, почему это важно.

CM>Последний релиз, естественно. Я вижу, тебе никак не надоест юлить?

В node.JS есть минимум два "последних" релиза — standart(lts) и current. В сентябре это были 6 и 8, а сейчас 8 и 9. Релизы идут _постоянно_.
Потому надо привязываться к точной версии а не к постоянно меняющейся "последней". Скоро будут другие версии и ты снова прибежишь ко мне, что де я всё наврал ? И так каждые пару месяцев? Правильно я тебя понял ?
Отредактировано 01.11.2017 17:38 Pauel . Предыдущая версия .
Re[78]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 01.11.17 20:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>. Полагаю, ты думаешь, что замер инициализации появился сам собой ?


Нет, не думаю. Я сам сделал его отдельно для JS — напоминаю, если у тебя снова память отказала

I>Ты еще раз приведи, что тебя смущает, с указанием точных версий тестов и рантаймов.


Меня смущает твой замер для JS, который выглядит очень странно. Вот ты и приводи точную версию тестов и рантаймов. И если у тебя где-то что-то не то сравнивается — это, опять же, твоя проблема, а не моя.

I>- если сравнить версии нода от 6й до 9й, то внезапно окажется, что где то посередине перформанс _падает_ на сортировке, при чем значительно, около 15%.


15% разницы — легко поверю. 100% — не верю.

I>Как раз тебе надо доказать, что твоя модификация 1 сортирует и 2 не хуже стандартной.


То, что она сортирует — достаточно запустить и посмотреть на результат. Слишком сложно, не успеваешь за ходом мысли?
И она, напоминаю, не моя.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[79]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.11.17 09:57
Оценка: -1 :)
Здравствуйте, CoderMonkey, Вы писали:

I>>. Полагаю, ты думаешь, что замер инициализации появился сам собой ?

CM>Нет, не думаю.

Возможно таки стоит начать.

>Я сам сделал его отдельно для JS — напоминаю, если у тебя снова память отказала


Давай посмотрим вместе кто чего сделал ? Вот мой код от 19-го сентября, тот самый, твоя попа-боль:
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}`);
}


>...если у тебя снова память отказала


Странно, что в моём коде замер инициализации был изначально... Так что да, кое у кого память отказала

I>>Ты еще раз приведи, что тебя смущает, с указанием точных версий тестов и рантаймов.


CM>Меня смущает твой замер для JS, который выглядит очень странно.


Вот твоя претензия

По твоему заявлению, JS работает у тебя намного быстрее, чем у меня (даже если взять твой любимый Хром и проигнорировать все остальные барузеры), зато C# — более чем в 2 раза медленнее. Совершенно поразительная избирательность у твоего железа.


Смотрим результаты.
Init, miliseconds: 4353
Total miliseconds: 1578


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

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


"JS работает у тебя намного быстрее, чем у меня " — как видим, ты здесь просто наврал.
У тебя инициализация быстрее моей больше чем на секунду. А какая версия рантайма — ты не указал.
Сортировка работает как и уменя, за 1.5 секунды. И это вполне объяснимо.

Теперь, к интересному
>Вот ты и приводи точную версию тестов и рантаймов.

Ты так не удосужился выяснить, какие же версии у тебя были, но утверждаешь, что всё должно быть не так.

Цитирую себя:
— на имеющемся железе(разные компы) сортировка работает в районе 1600+-200мс. А вот инициализация от 2500 до 6500мс. node 8.8.1 64

Версия здесь та самая — с которой у тебя столько попа-боли, от 19-го сентября.
Как видишь, результат запуска на экспериментальном рантайме полностью вписывается в эту тенденцию.
Более того — твои результаты тоже вписываются в эту тенденцию.

Собственно результат аномальный, но объяснимый. Ты ни одно из объяснений ни понять, ни опровергнуть не смог, только орёшь что де "гранаты не той системы"

>И если у тебя где-то что-то не то сравнивается — это, опять же, твоя проблема, а не моя.


Это ты ведь претензии предъявляешь, не так ли ? Это ведь тебе результаты кажутся странными

Сначала, ты утверждал, что цифры не те, но запускал на фаерфоксе
Потом ты утверждал, что цифры не те, и игнорировал CompareOrdinal
Далее ты утверждал, что цифры не те, но игнорировал железо
После этого ты утверждал, что соотношение числе не той системы, не соответствует твоим ожиданиям (нигде не озвученым)
Позже ты утверждал, что цифры не те, ничем не аргументируя
И сейчас продолжаешь ровно то, с чего и начал — голословные обвинения

I>>- если сравнить версии нода от 6й до 9й, то внезапно окажется, что где то посередине перформанс _падает_ на сортировке, при чем значительно, около 15%.


CM>15% разницы — легко поверю. 100% — не верю.


100% и не нужно. Смотри выше. Все объяснения были даны, ты ни одно не смог даже прочесть

I>>Как раз тебе надо доказать, что твоя модификация 1 сортирует и 2 не хуже стандартной.

CM>То, что она сортирует — достаточно запустить и посмотреть на результат. Слишком сложно, не успеваешь за ходом мысли?

Недостаточно. 1млн результатов 'посмотреть' невозможно. Нужны доказательства.

CM>И она, напоминаю, не моя.


Скорее всего какая нибудь лабораторная из твоих "шедевров" Ну, может и курсовая
Отредактировано 02.11.2017 11:17 Pauel . Предыдущая версия . Еще …
Отредактировано 02.11.2017 10:04 Pauel . Предыдущая версия .
Re[80]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 02.11.17 17:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Давай посмотрим вместе кто чего сделал ? Вот мой код от 19-го сентября, тот самый, твоя попа-боль:



Это вообще не тот код, о котором шла речь.

I>Мои :

I>JS
I>инициализация 5.5 секунды
I>сортировка 1.5 секунды
I>[/code]

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

I>Скорее всего какая нибудь лабораторная из твоих "шедевров" Ну, может и курсовая


Сортировка — это вообще не мой код. Но, как я уже писал, я его проверял. И ты можешь сделать то же самое, если немного наморщишь свои извилины. Так что, может быть, ты удосужишься привести тесткейс его "некорректности" или наконец заткнешь свой фонтан пустого "красноречия"?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[81]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.11.17 10:59
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Давай посмотрим вместе кто чего сделал ? Вот

мой код от 19-го сентября, тот самый, твоя попа-боль

:

CM>

CM>Это вообще не тот код, о котором шла речь.

Странно, http://rsdn.org/forum/flame.comp/6907242.1
Автор: Ikemefula
Дата: 18.09.17
Смотрим дату — 18го сентября. На этот момент была только одна версия — самая первая, где const вместо let (что порвало тебе одно место).
19го сентября я этот косяк пофиксил — т.е. сделал let вместо const. На замеры это никак не повлияло.
Смотрим — http://rsdn.org/forum/flame.comp/6906649.1
Автор: Ikemefula
Дата: 17.09.17
.Опубликовано — 17го сентября. Отредактивано — 19го сентября.

Ты хоть эту часть понял ?

I>>Мои :

I>>JS
I>>инициализация 5.5 секунды
CM>I>сортировка 1.5 секунды
I>>[/code]

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


Поиском по тексту глянь — чуть не в каждом сообщении "19 сентября", а ты никак не можешь это увидеть. Похоже, что попа-боль до сих пор тебя не отпускает
Вот, кстати, предыдущее сообщение

мой код от 19-го сентября, тот самый, твоя попа-боль


>и какой магический рантайм позволяет получить такое замечательное число на твоем тормозном железе Вопрос этот я задавал уже не один раз, и ты каждый раз уклонялся от ответа тем или иным способом


Какой рантайм — экспериментальный, ближе всего к нему будет наверное node 8.8.1 64, точнее не могу сказать. На самом деле уже не важно. И вот почему — я позапускал эту версию от 19го сентября на разных компах с разной производительностью и сортировка везде укладывается в 1600+- 200 мс. Более того — даже разные рантаймы дают очень похожее число, колебания в пределах 15%.

Вот это и есть аномалия, которая тебя колбасит — вроде железо тормозное, а на сортировке всё равно полторы секунды.
Собтсвенно я её объяснил тебе ажно несколько раз. И другие аномалии, они тоже есть, их я тоже объяснил.

Вобщем, от тебя только "бред", "враньё", "так не бывает", "ты всех обманул". Ты программист или сантехник ?

I>>Скорее всего какая нибудь лабораторная из твоих "шедевров" Ну, может и курсовая

CM>Сортировка — это вообще не мой код. Но, как я уже писал, я его проверял.
"Проверял" это не доказательство. Так все студенты, джуниоры и джуниористые мидлы говорят — "я проверял", "у меня работает", "там багов нет".
Если мы про алгоритмы, то их принято доказывать, что они являются тем, что надо
Re[82]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 03.11.17 20:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Странно, http://rsdn.org/forum/flame.comp/6907242.1
Автор: Ikemefula
Дата: 18.09.17
Смотрим дату — 18го сентября. На этот момент была только одна версия — самая первая, где const вместо let (что порвало тебе одно место).


Облажался ты, а виноват почему-то я.

I>Какой рантайм — экспериментальный, ближе всего к нему будет наверное node 8.8.1 64, точнее не могу сказать. На самом деле уже не важно. И вот почему — я позапускал эту версию от 19го сентября на разных компах с разной производительностью и сортировка везде укладывается в 1600+- 200 мс.


Надо же, какой магический рантайм. Скорость от железа вообще не зависит.
Хотя нет, я в магию не верю. Так что вся магия наверняка заключается в каком-то очень особом способе измерения.

I>Более того — даже разные рантаймы дают очень похожее число, колебания в пределах 15%.


Разброс даже на том же самом железе и той же версии рантайма +-25%.

I>Если мы про алгоритмы, то их принято доказывать, что они являются тем, что надо


Элементарно, если тебе яйца танцевать мешают или еще какие проблемы подобного характера.
Из 300 случайных тестовых наборов по миллиону записей, ноль ошибок. А теперь, вероятно, ты опять начнешь юлить и выкручиваться?

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Globalization;
using System.Linq;
using System.Text;

namespace QuickSort
{
    public static class SortingCheck
    {
        public static void Test()
        {
            var itemsCount = 1000_000;

            int Compare(TestClass x, TestClass y) => string.CompareOrdinal(x.Id, y.Id);

            for (var i = 0; ; i++)
            {
                var vals = Enumerable.Range(0, itemsCount).Select(x => new TestClass()).ToArray();
                QuickSort(vals, Compare);
                Check(vals, Compare);
                Console.WriteLine($"Run finished: {i}");
            }
        }

        public static void Check<T>(IList<T> vals, Func<T, T, int> compare)
        {
            for (var i = 1; i < vals.Count; i++)
            {
                if (compare(vals[i - 1], vals[i]) > 0)
                    throw new ApplicationException();
            }
        }

        public static void QuickSort<T>(T[] vals, Func<T, T, int> compare)
        {
            QuickSort(vals, compare, 0, vals.Length - 1);
        }

        public static void QuickSort<T>(T[] vals, Func<T, T, int> compare, int left, int right)
        {
            if (right <= left)
                return;

            var i = left;
            var j = right;
            var mid = (int)(((long)left + right) / 2);
            var midVal = vals[mid];

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

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

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

                    i++;
                    j--;
                }
            }

            QuickSort(vals, compare, left, j);
            QuickSort(vals, compare, i, right);
        }

        class TestClass
        {
            public readonly string Id;
            public readonly string Value;

            public TestClass()
            {
                Id = CreateId();
                Value = CreateId();
            }

            static readonly Random RandomGen = new Random();

            static string CreateId()
            {
                var num = (long)Math.Floor(RandomGen.NextDouble() * Math.Pow(10, 16));
                var res = num.ToString(Format, CultureInfo.InvariantCulture);
                return res;
            }

            static readonly string Format = new string('0', 8);

            public override string ToString()
            {
                return Id;
            }
        }
    }
}
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[83]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.11.17 09:53
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Какой рантайм — экспериментальный, ближе всего к нему будет наверное node 8.8.1 64, точнее не могу сказать. На самом деле уже не важно. И вот почему — я позапускал эту версию от 19го сентября на разных компах с разной производительностью и сортировка везде укладывается в 1600+- 200 мс.


CM>Надо же, какой магический рантайм. Скорость от железа вообще не зависит.


Правильно так — зависит не от абстрактного "железа", а от пропускной способности шины/памяти, о чем уже много раз говорилось. Ты наверняка сам собирал себе комп, раз "сэкономил" для такого процессора на хилой памяти. Ну может такой же "умелец" собирал конфигурацию.

Будешь смеяться, у тебя DDR3 и именно это объясняет эти полторы секунды. Почему в C# меньше — потому что C# не забивает шину лишними обращениями, в ём тупо косвенность раза в полтора-два ниже.
Именно отсюда получается результат 1600+- 200. Проц и кеш и определяют эти +-200мс тупо потому, что они намного быстрее узкого места — шины/памяти.

CM>Хотя нет, я в магию не верю. Так что вся магия наверняка заключается в каком-то очень особом способе измерения.


Смотри внимательно подчеркнутую часть:

— если сравнить версии нода от 6й до 9й, то внезапно окажется, что где то посередине перформанс _падает_ на сортировке, при чем значительно, около 15%.
— на имеющемся железе(разные компы) сортировка работает в районе 1600+-200мс. А вот инициализация от 2500 до 6500мс. node 8.8.1 64

Подчеркнутое говорит, что инициализация, в отличие от сортировки, очень сильно зависит от процессора, а они у нас тобой сильно разные.

Теперь очередная попа-боль для тебя: http://rsdn.org/forum/flame.comp/6947971.1
Автор: Ikemefula
Дата: 28.10.17

Замеры видишь ? Я их сюда скопирую, на всякий, если у тебя со зрением проблемы:
Init, miliseconds: 1598
Sort miliseconds: 1573


  Энергичная версия JS, длинные числа вместо GUID
'use strict';

const N = 1000*1000;
const re = /-/g;
const arr = Array(N);

function Main(number) {
    let watch = Date.now();
    let vals = arr; 
    
    for(let i = 0; i<arr.length; i++) {
        arr[i] = 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() {
    let num = 0|Math.random() * Math.pow(10, 16);

    return num.toString(16);
    //return NewGuid().toString().replace(re, "");
}

function NewGuid() {
    function s4() {
        return (((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));
}


Здесь наблюдаем ровно ту же магию — сортировка каким то чудом держится в районе той же магической границы 1600+-200.

Вот еще два замера на том же хилом железе:
Init, miliseconds: 1163
Sort miliseconds: 1654

Init, miliseconds: 1306
Sort miliseconds: 1836


I>>Более того — даже разные рантаймы дают очень похожее число, колебания в пределах 15%.

CM>Разброс даже на том же самом железе и той же версии рантайма +-25%.

Если ты про разброс внутри серии, то это GC и потому я вывожу всю серию. Мне лень было считать среднее отклонение, дисперсию, матожидание и тд.

I>>Если мы про алгоритмы, то их принято доказывать, что они являются тем, что надо

CM>Элементарно, если тебе яйца танцевать мешают или еще какие проблемы подобного характера.
CM>Из 300 случайных тестовых наборов по миллиону записей, ноль ошибок. А теперь, вероятно, ты опять начнешь юлить и выкручиваться?

Хоть миллиард тестов по миллиону. Нужно доказать общий случай, а миллион — это ровно один. Студенты часто делают сорировку, которая работает, скажем, для четных или для тех, что делятся на 4 и тд.
Re[84]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 04.11.17 17:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Правильно так — зависит не от абстрактного "железа", а от пропускной способности шины/памяти, о чем уже много раз говорилось. Ты наверняка сам собирал себе комп, раз "сэкономил" для такого процессора на хилой памяти.


Пальцем в небо Для такого процессора, более быстрой памяти не существует в природе.

I>Будешь смеяться, у тебя DDR3 и именно это объясняет эти полторы секунды.


И опять пальцем в небо.
По результатам бенчмарков, реальная разница между DDR3 и DDR4 составляет около 5-10% (и далеко не всегда в пользу DDR4).

I>Именно отсюда получается результат 1600+- 200. Проц и кеш и определяют эти +-200мс тупо потому, что они намного быстрее узкого места — шины/памяти.


На самом деле, время сортировки получается около 1500 +- 400.

I>Подчеркнутое говорит, что инициализация, в отличие от сортировки, очень сильно зависит от процессора, а они у нас тобой сильно разные.


Напоминаю еще раз, для самых-самых сообразительных. Я писал именно про сортировку. Ikemefula, я писал про сортировку. Про сортировку, Ikemefula. Сортировку. Сортировку, а не инициализацию.
Так до тебя лучше дошло?

I>Если ты про разброс внутри серии, то это GC и потому я вывожу всю серию.


Вот именно, что GC. Похоже, разработчики рантайма тоже любят мухлевать и отложили GC максимально — так, чтобы он выполнялся после первого прогона. Бенчмарки выглядят намного красивее, а что проги в целом тормозят так же — это уже неважно.

I>Хоть миллиард тестов по миллиону. Нужно доказать общий случай, а миллион — это ровно один.


Ну докажи ка мне корректность твоего кода сортировки в общем случае. Хочу посмотреть, как это делается.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re: Реальная производительность WebAssembly?
От: Mystic Artifact  
Дата: 04.11.17 23:28
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

CM>Кто-нибудь уже щупал его на предмет производительности? Насколько сильно сливает по сравнению с C — на десятки процентов, в разы или в десятки раз, как JS?

Мы тысячу копий сломали тут уже. Тем не менее.
Вот смотри: JS транслируется в байт-код движков (V8, манки, херянки). И исполняется. Ну ессно между ними даже JIT всовывается и получается отлично.
WebAssembly — это такая вещь которая "почти байт-код". Он байт код и есть, только он всё равно будет транслироваться в байт-код реального движка из которого будет джитится реальный код (или интерпретироваться — есть ограничения спецификацией?). Так что, реальные кодогенераторы у всех от движков JS. Вот эти кодогенераторы — вполне сносные. Но у них заточка под "нативные вызовы". Т.е. промассировать массив байт — на wasm будет норм. Промассировать ещё что — будет норм. А как только появится интероп за пределами спецификации и/или стандартных вызовов JS — тут и приплывают все.

Что это означает?
То что абстракции не позволят сделать то, что делает C++. Но это будет лучше JS на числодробилках (это сколько процентов реальных задач?). Ну и всё. Для 3Д что-то довернут. Для остального — оно и голого JS более чем достаточно уже 10 лет как. Откровенно слабому железу — wasm не поможет. А середнячку как бы давно всё по плечу.

Технология, имхо, крайне перспективная не сколько потому, что она хороша сама по себе — а сколько потому, что всё остальное как бы отменяют или двигаются в этом направлении.

Но, опять же. Есть задача балального бесконечного "list view" — её можно сделать либо рисуя полностью самим, или классикой "виртуального скролла". В сумме — имхо, первое даже сделать проще — но явных выигрей здесь нет ни у кого. По работе с DOM пока лидирует только JS — банально — он на это заточен. Вообще весь "Web API" заточен на JS. Со временем, это возможно поменяется. Но точить под C++ — тоже идиотов нет — оно никому не нужно.
Re[85]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.11.17 17:57
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Будешь смеяться, у тебя DDR3 и именно это объясняет эти полторы секунды.


CM>И опять пальцем в небо.

CM>По результатам бенчмарков, реальная разница между DDR3 и DDR4 составляет около 5-10% (и далеко не всегда в пользу DDR4).

Бенчмарки показывают влияние шины на _общую_ производительность системы в конкретной задаче. И здесь 5-10% это очень много.
В нашем случае у нас микробенчмарк — перетасовка одной лишь памяти. Фактически, здесь всё время даёт именно шина.

I>>Именно отсюда получается результат 1600+- 200. Проц и кеш и определяют эти +-200мс тупо потому, что они намного быстрее узкого места — шины/памяти.

CM>На самом деле, время сортировки получается около 1500 +- 400.

Опаньки! А как бодро начиналось "сортировка в JS у тебя сработала намного быстрее". А щас выходит у тебя среднее меньше, а нижняя граница вовсе на 20% меньше моей
Похоже, два месяца врал именно ты Ты что, не видишь, что лучший результат у тебя 1100 (1500-400) чего у меня и близко не было даже на самом быстром железе ? Хотя может под +-400 ты чтото другое подразумеваешь, от тебя всего можно ожидать.

I>>Подчеркнутое говорит, что инициализация, в отличие от сортировки, очень сильно зависит от процессора, а они у нас тобой сильно разные.


CM>Напоминаю еще раз, для самых-самых сообразительных. Я писал именно про сортировку. Ikemefula, я писал про сортировку. Про сортировку, Ikemefula. Сортировку. Сортировку, а не инициализацию.

CM>Так до тебя лучше дошло?

Я в курсе, что ты из за сортировки беснуешься. Для того, что бы объяснить, почему и у тебя и у меня вылазят эти 1.5с, надо посмотреть на инициализацию. Там, внезапно, совсем другая картина. И именно это даёт объяснение.
Собтсвенно, ровно та же картина и на других компах. Надейся я на тебя, ничего бы не заметил.
Инициализация доказыет, что сортировка есть аномалия. И именно её нужно объяснять. Понемногу я тебе разжевываю, как это было например с CompareOrdinal. Глядишь, к НГ управимся.

I>>Если ты про разброс внутри серии, то это GC и потому я вывожу всю серию.


CM>Вот именно, что GC. Похоже, разработчики рантайма тоже любят мухлевать и отложили GC максимально — так, чтобы он выполнялся после первого прогона. Бенчмарки выглядят намного красивее, а что проги в целом тормозят так же — это уже неважно.


GC дотнета, джавы работают похоже. Ради пару мб памяти GС и напрягаться не будет — её навалом. Кстати, в твоём коде даже GC.Collect не вызывается

I>>Хоть миллиард тестов по миллиону. Нужно доказать общий случай, а миллион — это ровно один.


CM>Ну докажи ка мне корректность твоего кода сортировки в общем случае. Хочу посмотреть, как это делается.

Мне это не нужно делать, у меня абсолютно стандарный вариант. Ты изменил алгоритм — обоснуй.
Re[86]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 07.11.17 17:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Бенчмарки показывают влияние шины на _общую_ производительность системы в конкретной задаче. И здесь 5-10% это очень много.

I>В нашем случае у нас микробенчмарк — перетасовка одной лишь памяти. Фактически, здесь всё время даёт именно шина.

1. Тебе осталось только доказать, что причина именно в ней. Так что давай, показывай доказательства.
2. Не общую производительность, а именно в отдельных программах (при том, что в других программах DDR4 проигрывает). Так что — те же самые микробенчмарки.
Так что твоя любимая шина, в самом лучше для нее случае, может иногда дать +10%.
Память то у тебя какая, кстати? А то вдруг на твоем тормозожелезе стоит какой-нибудь PC4-12800

I>Опаньки! А как бодро начиналось "сортировка в JS у тебя сработала намного быстрее".


Ну так я думал, что ты измерял среднее или медианное время, как делают все нормальные люди.
И это мы еше временно исключили из картины Firefox — а он, между тем, по прежнему есть. Так что по хорошему, надо усреднять и с ним.

I>А щас выходит у тебя среднее меньше, а нижняя граница вовсе на 20% меньше моей


А должна быть — меньше в два раза.

I>Инициализация доказыет, что сортировка есть аномалия. И именно её нужно объяснять. Понемногу я тебе разжевываю, как это было например с CompareOrdinal. Глядишь, к НГ управимся.


Какая такая аномалия? Мы сравниваем твой код, только на разных компьютерах.

I>GC дотнета, джавы работают похоже. Ради пару мб памяти GС и напрягаться не будет — её навалом. Кстати, в твоём коде даже GC.Collect не вызывается


И такого огромного разброса, как в JS, нет. Вот ведь удивительно.

I>Мне это не нужно делать


Нужно, достаточно вспомнить про баг в стандартной сортировке Java. Давай, обосновывай. В общем виде.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Отредактировано 07.11.2017 17:40 CodeMonkey . Предыдущая версия .
Re[87]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.11.17 13:19
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Бенчмарки показывают влияние шины на _общую_ производительность системы в конкретной задаче. И здесь 5-10% это очень много.

I>>В нашем случае у нас микробенчмарк — перетасовка одной лишь памяти. Фактически, здесь всё время даёт именно шина.

CM>1. Тебе осталось только доказать, что причина именно в ней. Так что давай, показывай доказательства.


Да, надо перепроверить на разном железе, в т.ч. ddr4. У меня все что есть, это DDR3 1600

CM>2. Не общую производительность, а именно в отдельных программах (при том, что в других программах DDR4 проигрывает). Так что — те же самые микробенчмарки.


Не вижу связи между "отдельная программа" и "микробенчмарк". Что делает эта "отдельная программа" ? Если исключительно память туда-сюда копирует или сортирует, это микробенчмарк. А если, скажем, зип упаковывает-распаковывает, или рисует-вычисляет чего, то совсем другая вещь.

CM>Так что твоя любимая шина, в самом лучше для нее случае, может иногда дать +10%.

CM>Память то у тебя какая, кстати? А то вдруг на твоем тормозожелезе стоит какой-нибудь PC4-12800

wmic MemoryChip get BankLabel, Capacity, MemoryType, TypeDetail, Speed, Tag
BankLabel  Capacity    MemoryType  Speed  Tag                TypeDetail
BANK 3     8589934592  24          1600   Physical Memory 3  128


I>>Опаньки! А как бодро начиналось "сортировка в JS у тебя сработала намного быстрее".

I>>А щас выходит у тебя среднее меньше, а нижняя граница вовсе на 20% меньше моей

CM>А должна быть — меньше в два раза.


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

I>>Инициализация доказыет, что сортировка есть аномалия. И именно её нужно объяснять. Понемногу я тебе разжевываю, как это было например с CompareOrdinal. Глядишь, к НГ управимся.

CM>Какая такая аномалия? Мы сравниваем твой код, только на разных компьютерах.

Ты как поляк, который смеётся с анекдота трижды — когда ему рассказывают, когда объясняют и когда доходит
Читаем медленно:
Аномалия в том, что: 
1 замеры в сортировке     не соответствуют разнице в мощности железа. ( НЕ СООТВЕТСТВУЮТ)
2 замеры в инициализации     соответствуют разнице в можности железе. (    СООТВЕТСТВУЮТ)


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

I>>GC дотнета, джавы работают похоже. Ради пару мб памяти GС и напрягаться не будет — её навалом. Кстати, в твоём коде даже GC.Collect не вызывается

CM>И такого огромного разброса, как в JS, нет. Вот ведь удивительно.

А почему они должны показывать одно и то же ? Если ты один и тот же GC запускаешь в разных условиях, с разной частотой, из разных потоков — ты получаешь совершенно разные вещи.

I>>Мне это не нужно делать

CM>Нужно, достаточно вспомнить про баг в стандартной сортировке Java. Давай, обосновывай. В общем виде.

Мне достаточно того факта, что ты не можешь даже источник указать, т.е. код _на_коленке_.
Re[88]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 08.11.17 15:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Да, надо перепроверить на разном железе, в т.ч. ddr4. У меня все что есть, это DDR3 1600


Тогда чего столько шума поднимал, если у тебя самого тормозная память? Похоже, опять решил приврать для красного словца?

I>Не вижу связи между "отдельная программа" и "микробенчмарк". Что делает эта "отдельная программа" ? Если исключительно память туда-сюда копирует или сортирует, это микробенчмарк. А если, скажем, зип упаковывает-распаковывает, или рисует-вычисляет чего, то совсем другая вещь.


Для архиваторов пиковая пропускная способность как раз очень важна. Для остальных программ — намного менее.

I>
I>wmic MemoryChip get BankLabel, Capacity, MemoryType, TypeDetail, Speed, Tag
I>BankLabel  Capacity    MemoryType  Speed  Tag                TypeDetail
I>BANK 3     8589934592  24          1600   Physical Memory 3  128
I>


И о чем мне должен говорить "MemoryType 24" в какой-то неведомой говнопрограмме? Может, в ней вообще DDR1 закодирован таким образом?

I>Итого — можешь обосновать или ... ?


Обосновать то, что тормозное железо обычно примерно одинаково тормозное во всем, кроме редких исключений, когда для этого есть конкретные и хорошо известные причины? Следующей серией, специально для Ikemefula — вода мокрая, солнце яркое и другие "невероятные открытия".

I>Теоретически, у нас может любой случай, т.к. у тебя не то много медленнее, не то быстрее чем у меня. Сам определить не можешь.

I>Может даже окажется так, что и сортировка и инициализация показывают одну и ту же разницу, если померить среднее время по первому числу из пары десятков прогонов.

Нет, не может. Среднее время я — в отличии от тебя — измерял.
Время инициализации в JS и тесты в C# у тебя вполне соответствуют ожидаемому. Сортировка в JS — совершенно не соответствует. Вывод по прежнему тот же — Ikemefula хотел смухлевать с цифрами.

I>Мне достаточно того факта, что ты не можешь даже источник указать, т.е. код _на_коленке_.


Напоминаю еще раз, что сортировка в одном вполне хорошо известном источнике была кривая. Так что мимо тазика. Доказывай корректность твоего кода в обшем случае.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[89]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.11.17 18:45
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Да, надо перепроверить на разном железе, в т.ч. ddr4. У меня все что есть, это DDR3 1600

CM>Тогда чего столько шума поднимал, если у тебя самого тормозная память? Похоже, опять решил приврать для красного словца?

Шум вообще говоря только ты подымаешь.

I>>Не вижу связи между "отдельная программа" и "микробенчмарк". Что делает эта "отдельная программа" ? Если исключительно память туда-сюда копирует или сортирует, это микробенчмарк. А если, скажем, зип упаковывает-распаковывает, или рисует-вычисляет чего, то совсем другая вещь.


CM>Для архиваторов пиковая пропускная способность как раз очень важна. Для остальных программ — намного менее.


Пропускная способность __чего__ ? Есть ответ ?

Кто в архиваторе занимается упаковкой, распаковкой, т.е. _вычислениями_, которые и отнимают бОльшую часть времени ? Назови этого героя И сразу станет ясно. Их целых два, кстати говоря, героя

I>>
I>>wmic MemoryChip get BankLabel, Capacity, MemoryType, TypeDetail, Speed, Tag
I>>BankLabel  Capacity    MemoryType  Speed  Tag                TypeDetail
I>>BANK 3     8589934592  24          1600   Physical Memory 3  128
I>>


CM>И о чем мне должен говорить "MemoryType 24" в какой-то неведомой говнопрограмме? Может, в ней вообще DDR1 закодирован таким образом?


Забавно, и тут тебе неведомо. 24 и есть DDR3. wmic это _стандартная_ утилита.
Покажи, кстати, что у тебя показывает, на том же железе, чьи замеры ты публиковал здесь.

I>>Итого — можешь обосновать или ... ?


CM>Обосновать то, что тормозное железо обычно примерно одинаково тормозное во всем, кроме редких исключений, когда для этого есть конкретные и хорошо известные причины? Следующей серией, специально для Ikemefula — вода мокрая, солнце яркое и другие "невероятные открытия".


Тебе надо обосновать разницу "вдвое". С чего ты взял, что должна быть такая же разница в JS ? Непонятно, что ты вообще хочешь сказать — может твоё железо такое же тормозное как и моё ?

Ты не забыл, что "вдвое" всего лишь предположение, основаное на сравнении результатов одних версий теста с другими ? До кучи, свой код ты так и не опубликовал.

От тебя требуется:
1 тест C# — компилируемый, первый вариант, на гуидах, + фикс CompareOrdinal. В этом случае результаты сравнимы с JS.
2 запустить на фремворке 4.0 — у меня другого нет

Показать результаты сюда. Отсюда будет худо бедно ясна разница в производительности железе.

Далее — JS. Всё замеры по ём уже дадены. Если сомневаешься — тебе дорога в jsPerf. Создавай тест, будем проверять публично, раз у тебя какие то проблемы.

CM>Нет, не может. Среднее время я — в отличии от тебя — измерял.


Судя по тому, что ты путаешь деление и вычитание, верится с трудом.

CM>Время инициализации в JS и тесты в C# у тебя вполне соответствуют ожидаемому. Сортировка в JS — совершенно не соответствует.


Забавно, что ты в очередной раз меняешь придирки. Сначала у тебя сортировка JS работала намного медленее. Потом вдруг оказалось, что не только медленнее, но и быстрее.
Сколько, по твоему, должна показывать сортировка и на каком основании ?

>Вывод по прежнему тот же — Ikemefula хотел смухлевать с цифрами.


Эмоции это твой единственный "аргумент".
Re[90]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 08.11.17 19:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Шум вообще говоря только ты подымаешь.


Ну это просто враньё. Цитирую, например:

Ты наверняка сам собирал себе комп, раз "сэкономил" для такого процессора на хилой памяти. Ну может такой же "умелец" собирал конфигурацию.
Будешь смеяться, у тебя DDR3 и именно это объясняет эти полторы секунды.


А тут внезапно выясняется, что у тебя самого DDR3, да еще и тормознее моей. Вот ведь незадача. Цирк уехал, а Ikemefula остался.

I> Пропускная способность __чего__ ? Есть ответ ?

I>Кто в архиваторе занимается упаковкой, распаковкой, т.е. _вычислениями_, которые и отнимают бОльшую часть времени ? Назови этого героя И сразу станет ясно. Их целых два, кстати говоря, героя

В архиваторе, вычисления — самые тривиальные. Так что в реальных бенчмарках, WinRar, например — одно из немногих приложений, где DDR4 действительно выигрывает, при близкой частоте.

I>Забавно, и тут тебе неведомо. 24 и есть DDR3. wmic это _стандартная_ утилита.


В первый раз вообще слышу

I>Покажи, кстати, что у тебя показывает, на том же железе, чьи замеры ты публиковал здесь.


Уже писал. Какой смысл писать снова, если до тебя опять не дойдет?

I>Тебе надо обосновать разницу "вдвое". С чего ты взял, что должна быть такая же разница в JS ? Непонятно, что ты вообще хочешь сказать — может твоё железо такое же тормозное как и моё ?


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

I>Ты не забыл, что "вдвое" всего лишь предположение, основаное на сравнении результатов одних версий теста с другими ? До кучи, свой код ты так и не опубликовал.


Какой еще мой код? Аномалия — в твоем коде, а точнее — в сортировке. Сколько раз надо повторить, чтобы до тебя наконец дошло?

I>Забавно, что ты в очередной раз меняешь придирки. Сначала у тебя сортировка JS работала намного медленее. Потом вдруг оказалось, что не только медленнее, но и быстрее.


В Firefox — таки медленнее, и намного. Это ты же сам решил по желанию своей левой пятки, что мы считаем только Chrome.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[91]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.11.17 13:21
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

I>>Шум вообще говоря только ты подымаешь.


CM>Ну это просто враньё. Цитирую, например:

CM>

CM>Ты наверняка сам собирал себе комп, раз "сэкономил" для такого процессора на хилой памяти. Ну может такой же "умелец" собирал конфигурацию.
CM>Будешь смеяться, у тебя DDR3 и именно это объясняет эти полторы секунды.


И где здесь этот самый шум ? А вот если мы посмотрим твои сообщения, то видим, что
1 ты постоянно уходишь от ответов
2 используешь эмоциональные "аргументы"
3 от тебя поступает много обвинений.
4 конструктив почти что отсутствует

Вот это и есть — шум.

CM>А тут внезапно выясняется, что у тебя самого DDR3, да еще и тормознее моей. Вот ведь незадача. Цирк уехал, а Ikemefula остался.


Браво, капитан! А ты уже забыл, что я объясняю слабую разницу во времени сортировки одинаковой памятью у тебя и меня ?

I>> Пропускная способность __чего__ ? Есть ответ ?

I>>Кто в архиваторе занимается упаковкой, распаковкой, т.е. _вычислениями_, которые и отнимают бОльшую часть времени ? Назови этого героя И сразу станет ясно. Их целых два, кстати говоря, героя

CM>В архиваторе, вычисления — самые тривиальные. Так что в реальных бенчмарках, WinRar, например — одно из немногих приложений, где DDR4 действительно выигрывает, при близкой частоте.


Если узкое место — шина, то быстрый процессор Винрару погоды не сделает. Согласен или у тебя альтернативная логика ?
Скажем, если узкое место — шина, то многопоточные, многопроцессорные конфигурации погоды не делают.
Чего же мы видим в бенчмарках навроде Winrar ? Перформанс зависит в основном от проца и кеша. А вот шина дает жалкие 13-15%.

Надо объяснять, что сортировка намного проще и легче чем винрар ?

I>>Забавно, и тут тебе неведомо. 24 и есть DDR3. wmic это _стандартная_ утилита.

CM>В первый раз вообще слышу

Ты многое в данной беседе в первый раз слышишь. wmic это _стандартная_ утилита, в указаном примере всего то дергает Win32_PhysicalMemory WMI class
https://msdn.microsoft.com/en-us/library/aa394347(v=vs.85).aspx

I>>Покажи, кстати, что у тебя показывает, на том же железе, чьи замеры ты публиковал здесь.

CM>Уже писал. Какой смысл писать снова, если до тебя опять не дойдет?

Результаты wmic ты не приводил — факт.

I>>Тебе надо обосновать разницу "вдвое". С чего ты взял, что должна быть такая же разница в JS ? Непонятно, что ты вообще хочешь сказать — может твоё железо такое же тормозное как и моё ?

CM>Нет, это тебе надо обосновать, почему твой результат выбивается из общей закономерности. И ты, кстати, в очередной раз забыл рассказать, что там за процессор на твоем "нетормозном" железе

Из какой "общей" ? У нас разное понимание этой общей. Я говорю о том, что дело в DDR3 и у меня, и у тебя, а потому разница в сортировке минимальна.
У тебя абстрактное "вдвое" основаное непойми на чем — на сравнении результатов одной версии теста с результатами другой версией теста.
Итого — ответа нет. Фиаско ?

I>>Ты не забыл, что "вдвое" всего лишь предположение, основаное на сравнении результатов одних версий теста с другими ? До кучи, свой код ты так и не опубликовал.

CM>Какой еще мой код? Аномалия — в твоем коде, а точнее — в сортировке. Сколько раз надо повторить, чтобы до тебя наконец дошло?

Ты никак определиться не можешь — то замеры не те, не то соотношения не те, то быстрее, то медленнее. Сейчас вот уже код не той системы.
Мой код работает и у тебя и у меня, он один и тот же, замеры все приведены, а тебе проблема в коде мерещится.
Ты чего сказать хочешь? Признаться в фиаско ?

I>>Забавно, что ты в очередной раз меняешь придирки. Сначала у тебя сортировка JS работала намного медленее. Потом вдруг оказалось, что не только медленнее, но и быстрее.

CM>В Firefox — таки медленнее, и намного. Это ты же сам решил по желанию своей левой пятки, что мы считаем только Chrome.

С какого бодуна мне писать про фаерфокс, если я замерял движок V8 ?
Re[92]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 09.11.17 21:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вот это и есть — шум.


Он еще и меня обвиняет

I> Браво, капитан! А ты уже забыл, что я объясняю слабую разницу во времени сортировки одинаковой памятью у тебя и меня ?


Не объясняешь, а придумываешь оправдания для своего вранья. Это не одно и то же.
1. Какой у тебя процессор? Этот вопрос ты опять проигнорировал. Видимо, решил оставить себе пространство для маневра?
2. Где доказательства, что твоя сортировка так сильно упирается в память и/или шину?

I>Чего же мы видим в бенчмарках навроде Winrar ? Перформанс зависит в основном от проца и кеша. А вот шина дает жалкие 13-15%.


Жалкие 13-15% — это и есть тот максимум прироста, который может дать DDR4 в условиях, когда всё упирается именно в нее.

I>Надо объяснять, что сортировка намного проще и легче чем винрар ?


Давай-давай, объясни, а я пока за попкорном схожу.

I>Ты многое в данной беседе в первый раз слышишь. wmic это _стандартная_ утилита, в указаном примере всего то дергает Win32_PhysicalMemory WMI class


Стандартная для мазохистов, видимо? Зачем использовать это говно с неведомыми магическими константами, когда есть бесплатный HWiNFO?

I>Мой код работает и у тебя и у меня, он один и тот же, замеры все приведены, а тебе проблема в коде мерещится.


Повторяю снова, специально для Ikemefula — не в коде, а в твоих странных цифрах
Хотя, кстати, ты поскипал обоснование корректности твоего кода в общем виде. Я всё еще жду.

I> С какого бодуна мне писать про фаерфокс, если я замерял движок V8 ?


А с какого бодуна мне писать по V8, если я писал про фаерфокс? Дошло наконец или еще надо объяснять?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.