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

I>Вот этот код скомпилируется и выполняется, всё ок. Но он выполняется по разному в зависимости от продолжения.


Бобер, выдыхай. У этого кода есть "энергичное" продолжение, прямо в той же строке.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[57]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.17 09:21
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>С помощью ToArray ты леникую последовательность перегоняешь в массив. Скорость этого участка кода соответсвует скорости узкого места. Никакого чуда здесь нет.

CM>Вот именно. В чем проблема то?

Проблема в том, что ленивый код работает в лучшем случае в 10 раз медленнее своего энергичного аналога, если хорошо написан. Если ты перепишешь linq часть на циклы, узнаешь много нового.

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


CM>Результаты все равно дерьмовые, к гадалке не ходи

CM>
  Скрытый текст
CM>index.html:28 Init, miliseconds: 4353
CM>Main @ index.html:28
CM>index.html:31 Total miliseconds: 1578


Ты видишь ровно то, о чем я тебе говорил. _Первая_ версия C# кода работает быстрее в инициализации, примерно в 3 раза, и медленнее в сортировке, примерно в 3 раза.
Запусти _первую_ версию C# и увидишь, что время _сортировки_ у тебя будет около 3500...5000мс.

I>>Во-вторых, смотри сам, что ты выдал — твой код не компилируется

CM>Ошибок компиляции там нет, в отличие от твоего кода

Браво — код компилируется, но код надо куда-то скопировать, что бы он скомпилировался
Все что у меня есть под рукой, это командная строка, компилятор C# из фремворка 4.0 и больше ничего.

>Ты решил включить дурака и не догадаться, куда этот код надо копировать?


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

I>>Твои "пара фиксов" это изменение типа данных. Фактически, это глобальное изменение. Ты сравниваешь разные вещи


CM>Заюлил Никаких глобальных изменений там нет.


И давно у тебя guid стал эквивалентом дабла ? Ты искусственно растягиваешь 52значащих бита в 128. В гуид у тебя 128 значащих бит.
Соответсвенно характер данных изменился, следовательно среднее время работы компаратора изменилось. А именно — уменьшилось относительно GUID версии.

CM>И разница в 3-4 раза против JS, и по скорости, и по памяти.


Разница с какой версией, алё ?
1 Ты изменил тип данных(увеличил перформанс как минимум), а JS всё еще использует guid.
2 ты изменил компаратор, а я говорю про разницу со старым вариантом

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

Ты вообще адекватный или где?
Re[59]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.17 09:21
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Вот этот код скомпилируется и выполняется, всё ок. Но он выполняется по разному в зависимости от продолжения.


CM>Бобер, выдыхай. У этого кода есть "энергичное" продолжение, прямо в той же строке.


А перформанс определяется узким местом, то есть — ленивой частью этого кода.
Re[60]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 12.10.17 16:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А перформанс определяется узким местом, то есть — ленивой частью этого кода.


... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[58]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 12.10.17 16:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Проблема в том, что ленивый код работает в лучшем случае в 10 раз медленнее своего энергичного аналога, если хорошо написан. Если ты перепишешь linq часть на циклы, узнаешь много нового.



На самом деле — нет. Во всяком случае, в .NET.

I>Ты видишь ровно то, о чем я тебе говорил. _Первая_ версия C# кода работает быстрее в инициализации, примерно в 3 раза, и медленнее в сортировке, примерно в 3 раза.

I>Запусти _первую_ версию C# и увидишь, что время _сортировки_ у тебя будет около 3500...5000мс.

В 2 раза. И это потому, что твой код был неэквивалентен функционально. Я этот факт исправил.

I>Браво — код компилируется, но код надо куда-то скопировать, что бы он скомпилировался

I>Все что у меня есть под рукой, это командная строка, компилятор C# из фремворка 4.0 и больше ничего.

Ох ты ж боже ж ты мой. Сумеешь разобраться, что в какой файл вставить?

  Скрытый текст
namespace QuickSort
{
class Program
{
static void Main(string[] args)
{
Sorting.Test();
}
}
}

namespace QuickSort
{
public static class Sorting
{
public static void Test()
{
var repeatCount = 10;

var initWatch = Stopwatch.StartNew();

TestClass[] origVals = null;
for (var i = 0; i < repeatCount; i++)
{
origVals = Enumerable.Range(0, 1000_000).Select(x => new TestClass()).ToArray();
}

initWatch.Stop();
Console.WriteLine($"Init: {initWatch.Elapsed.TotalSeconds / repeatCount}");

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

var watch = Stopwatch.StartNew();

for (var i = 0; i < repeatCount; i++)
{
var vals = origVals.ToArray();
QuickSort(vals, Compare);
}

watch.Stop();
Console.WriteLine($"Sort: {watch.Elapsed.TotalSeconds / repeatCount}");

if (Debugger.IsAttached)
Debugger.Break();
}

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', 16);

public override string ToString()
{
return Id;
}
}
}


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


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

I>И давно у тебя guid стал эквивалентом дабла ? Ты искусственно растягиваешь 52значащих бита в 128. В гуид у тебя 128 значащих бит.

I>Соответсвенно характер данных изменился, следовательно среднее время работы компаратора изменилось. А именно — уменьшилось относительно GUID версии.

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

I>1 Ты изменил тип данных(увеличил перформанс как минимум), а JS всё еще использует guid.


В JS нет guid. Ты сам про это недавно писал и даже пытался представить как преимущество. Я переделал код, чтобы можно было реализовать более похожим образом на обеих платформах.

I>2 ты изменил компаратор, а я говорю про разницу со старым вариантом


Але, в твоем коде какой компаратор используется — ordinal или культуро-зависимый?
Ты адекватный или где?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[59]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.17 19:45
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Проблема в том, что ленивый код работает в лучшем случае в 10 раз медленнее своего энергичного аналога, если хорошо написан. Если ты перепишешь linq часть на циклы, узнаешь много нового.


CM>

CM>На самом деле — нет. Во всяком случае, в .NET.

На самом деле alexzzzz уже написал код и все промерял. Взял бы да посмотрел.

I>>Запусти _первую_ версию C# и увидишь, что время _сортировки_ у тебя будет около 3500...5000мс.

CM>В 2 раза. И это потому, что твой код был неэквивалентен функционально. Я этот факт исправил.

А ты не думал, что мои слова относились именно к первой версии ?

CM>Ох ты ж боже ж ты мой. Сумеешь разобраться, что в какой файл вставить?


Без понятия. Нет желания проверять, где именно нужный набор using.

I>>Соответсвенно характер данных изменился, следовательно среднее время работы компаратора изменилось. А именно — уменьшилось относительно GUID версии.

CM>Неа, причина там совсем в другом месте. Если склеивать данные из двух рандомов по 8 байт или 4-х по 4 байта каждый, время сортировки то же. Так что думай лучше.

А ты не забыл, что мы еще и инициализацию меряем ?

I>>1 Ты изменил тип данных(увеличил перформанс как минимум), а JS всё еще использует guid.


CM>В JS нет guid. Ты сам про это недавно писал и даже пытался представить как преимущество. Я переделал код, чтобы можно было реализовать более похожим образом на обеих платформах.


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

I>>2 ты изменил компаратор, а я говорю про разницу со старым вариантом


CM>Але, в твоем коде какой компаратор используется — ordinal или культуро-зависимый?


А ты не видишь ? Дефолтный, как и в твоём коде. Я ж сказал — мой код это максимально близкий порт твоего кода
Re[60]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 12.10.17 20:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>На самом деле alexzzzz уже написал код и все промерял. Взял бы да посмотрел.


Посмотрел, идея примерно та же.
И что ты хотел сказать?

I>А ты не думал, что мои слова относились именно к первой версии ?


И твоя версия неэквивалентна ей функционально. Решил смухлевать или просто от неграмотности?

I>Без понятия. Нет желания проверять, где именно нужный набор using.




I>А ты не забыл, что мы еще и инициализацию меряем ?


И?

I>Ты, кстати, в курсе, в чем разница между рандомами на этих платформах ?


В том, что на JS он довольно халтурно сделан?

I>А ты не видишь ? Дефолтный, как и в твоём коде. Я ж сказал — мой код это максимально близкий порт твоего кода


Заюлил. Я так понимаю, в JS по дефолту — ordinal, не так ли?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[61]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.17 11:24
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>На самом деле alexzzzz уже написал код и все промерял. Взял бы да посмотрел.


CM>Посмотрел, идея примерно та же.

CM>И что ты хотел сказать?

А разницу по времени ты видишь ?
В простом цикле (alexzzzz)всех издержек на единицу данных это инкремент переменной цикла. Генератор — конечный автомат, унутре. Он, мягко говоря, не может работать так же быстро, как и переменная цикла.
То есть, в твоем случае на каждый элемент надо
1 прокрутить генератор Enumerable.Range
2 передать данные в следующий генератор
3 прокрутить генератор Select
4 вызвать проектор, т.е. лямда функци — это уже сравнимо со временем инкремента

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

Собственно, это не проблема, тк. цель Linq — ленивость, а не числодробилки. Соответсвенно и экономия за счет ленивости, то есть, частичные вычисления. У тебя же ничего такого нет — ты вычисляешь 1млн элементов. Зачем тебе linq ?

I>>А ты не думал, что мои слова относились именно к первой версии ?

CM>И твоя версия неэквивалентна ей функционально. Решил смухлевать или просто от неграмотности?

Ты же сам попросил портировать именно её. Кроме того, каким образом, по твоему, я мог портировать нынешний код ?

I>>А ты не забыл, что мы еще и инициализацию меряем ?

CM>И?

Ты несколько раз обвинил меня во вранье, что де я привел не те цифры. Сейчас ты решил вывести меня на чистую воду, но только делаешь это как то странно.
Неужели страшно, что цыфры в тесте совпадут с теми, что я сам же и привел ?
Re[62]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 23.10.17 16:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>У тебя довольно тривиальный код, но тем не менее он уже, судя по замерам 2-3 раза медленнее простого цикла. В типичных задачах потери времени будут намного больше, как я сказал раз в 10.


На самом деле — нет Реальная разница в несколько процентов.
Почему бы тебе не перестать высасывать из пальца?

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


Твоя версия неэквивалентна функционально самой первой версии. Что здесь для тебя непонятно?

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

I>Неужели страшно, что цыфры в тесте совпадут с теми, что я сам же и привел ?

А они не совпадают. Лучший результат для JS, который мне удалось получить (проигнорировав результаты всех браузеров, кроме самого кошерного по твоему мнению ) по прежнему на ~50% хуже числа, которое привел ты. А полученный мной результат для C# по прежнему на ~100% лучше твоего (для самого первого варианта кода). Просто поразительно, что твоя "архитектура процессора" так сильно любит JS и ненавидит C#
Будешь и дальше списывать на лучи Венеры, которые отразились в болотных газах, или придумаешь что умнее?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[63]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.10.17 18:18
Оценка:
Здравствуйте, CoderMonkey, Вы писали:

I>>У тебя довольно тривиальный код, но тем не менее он уже, судя по замерам 2-3 раза медленнее простого цикла. В типичных задачах потери времени будут намного больше, как я сказал раз в 10.


CM>На самом деле — нет Реальная разница в несколько процентов.


Покажи, куда ты смотришь. Наверное снова сравниваешь результаты с разных компов ?

I>>Неужели страшно, что цыфры в тесте совпадут с теми, что я сам же и привел ?


CM>А они не совпадают. Лучший результат для JS, который мне удалось получить (проигнорировав результаты всех браузеров, кроме самого кошерного по твоему мнению ) по прежнему на ~50% хуже числа, которое привел ты.


Именно. И похожая разница между замерами C# версий, глаза то раскрой. Ты что, реально не догоняешь, что это значит ?

Init: 0.777316665
Sort: 0.57440166


Это твои показатели. А у меня в 1.5-2 раза больше. Опаньки!

CM>Будешь и дальше списывать на лучи Венеры, которые отразились в болотных газах, или придумаешь что умнее?


Первый раз вижу человека, который два месяца старательно игнорирует железо
Re[64]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 24.10.17 18:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Покажи, куда ты смотришь.


Я смотрю на разницу между ленивой версией и энергичной. Она, в одних и тех же условиях — на несколько процентов. Что, собственно, и ожидалось. Так что не знаю, откуда ты высосал свою разницу в разы. Хотя догадываюсь

I>Это твои показатели. А у меня в 1.5-2 раза больше. Опаньки!


Ты так и не удосужился привести свои данные для моей последней версии для C#. Догоняй, там и посмотрим.

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


Если бы и JS и C# у тебя были в два раза медленнее, то я бы поверил. А так у тебя почему-то один быстрее почти в два раза, а другой — медленнее. Странновато как то
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[65]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.10.17 09:14
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Покажи, куда ты смотришь.


CM>Я смотрю на разницу между ленивой версией и энергичной. Она, в одних и тех же условиях — на несколько процентов. Что, собственно, и ожидалось. Так что не знаю, откуда ты высосал свою разницу в разы. Хотя догадываюсь



Покажи ссылкой, куда ты смотришь и что с чем сравниваешь. alexzzzz начал вроде как с ~500мс и дошел до ~100мс. Где тут несколько процентов — не ясно.

I>>Это твои показатели. А у меня в 1.5-2 раза больше. Опаньки!

CM>Ты так и не удосужился привести свои данные для моей последней версии для C#. Догоняй, там и посмотрим.

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

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

CM>Если бы и JS и C# у тебя были в два раза медленнее, то я бы поверил. А так у тебя почему-то один быстрее почти в два раза, а другой — медленнее. Странновато как то


Покажи ссылкой, куда ты смотришь, и что с чем сравниваешь.

Краткий пересказ предыдущих серий:
А — 1й вариант JS быстрее первого варианта C# в сортировке — причина в CompareOrdinal.
Б — 1й вариант JS медленнее первого вариант C# в инициализации — причина в медленном yield ES6.
В — 1й вариант C# у меня медленнее 1го варианта у тебя — причина в железе.
Г — 2й вариант JS медленнее 2го вариант C# — решена проблема CompareOrdinal.
Д — 2й вариант C# у меня медленнее 2го варианта C# у тебя — причина в железе.
Е — Оба варианта JS медленнее соответствующий твоих — снова причина в железе.
Ж — Разница между C# у тебя/меня и JS у тебя/меня разная. Причины в том, что JS чаще промахивается по кешу, в силу его динамической типизации и соответствующего внутренного устройства типов.
З — Результаты 1х версий нельзя сравнивать со 2ми — разные типы данных+CompareOrdinal, это влияет и на инициализацию, и на сортировку.

Где ты видишь противоречие и с чем именно это противоречие?

У меня сильное ощущение, что ты читаешь по диагонали и путаешь что к чему относится и как правильно надо сравнивать.
Re[66]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 26.10.17 16:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Покажи ссылкой, куда ты смотришь и что с чем сравниваешь. alexzzzz начал вроде как с ~500мс и дошел до ~100мс. Где тут несколько процентов — не ясно.


А с чего ты решил, что это имеет хотя бы малейшее отношение к ленивости? Услышал звон, да не понял где он.

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


И он еще мне какие-то претензии предъявляет.

I>Д — 2й вариант C# у меня медленнее 2го варианта C# у тебя — причина в железе.

I>Е — Оба варианта JS медленнее соответствующий твоих — снова причина в железе.

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

I>>Покажи ссылкой, куда ты смотришь и что с чем сравниваешь. alexzzzz начал вроде как с ~500мс и дошел до ~100мс. Где тут несколько процентов — не ясно.


CM>А с чего ты решил, что это имеет хотя бы малейшее отношение к ленивости? Услышал звон, да не понял где он.


alexzzzz выбросил ленивость. Сравни разницу между своей инициализацией и его оптимизированой версией. Там разы а не проценты. Ну если ты конечно не думаешь, что он запустил на чудо-железе, которое и выдало 100мс

I>>Д — 2й вариант C#

у меня медленнее
2го варианта C# у тебя — причина в железе.
I>>Е — Оба варианта JS
медленнее ... твоих
— снова причина в железе.

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


Читаем вместе — у меня и C# и JS работают медленее чем у тебя.

Похоже, что таки да, дело всё в "умении" читать. Стало быть, пора заканчивать ?
Re[68]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 26.10.17 21:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>alexzzzz выбросил ленивость. Сравни разницу между своей инициализацией и его оптимизированой версией. Там разы а не проценты. Ну если ты конечно не думаешь, что он запустил на чудо-железе, которое и выдало 100мс


Там вообще много отличий, например, в его версии используется unsafe для генерации значений. Небольшое такое отличие, неважное, а вот ленивость — это дооо, это сразу в 10 раз

На самом деле, на устранении ленивости как таковой там можно устранить чуть больше 13 миллисекунд, и еще около 8 — на более эффективном методе заполнения массива, чем ToArray. Что и составляет чуть больше процента от общего времени инициализации в ~800 миллисекунд для умеренно оптимизированной версии.
Но зато сколько вони ты поднял именно из-за ленивости, у меня аж глаза режет. И не надоест тебе нести чушь, а? Может, хоть немного займешься матчастью вместо тыкания пальцем наугад?

I>Читаем вместе — у меня и C# и JS работают медленее чем у тебя.


Возвращаемся к первоисточнику http://rsdn.org/forum/flame.comp/6907242?tree=tree
Автор: Ikemefula
Дата: 18.09.17

По твоему заявлению, JS работает у тебя намного быстрее, чем у меня (даже если взять твой любимый Хром и проигнорировать все остальные барузеры), зато C# — более чем в 2 раза медленнее. Совершенно поразительная избирательность у твоего железа.
Может, просто признаешь, что цифры с потолка взял? И так ведь очевидно, зато у тебя совесть чище будет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[69]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.10.17 11:43
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

I>>Читаем вместе — у меня и C# и JS работают медленее чем у тебя.


CM>Возвращаемся к первоисточнику http://rsdn.org/forum/flame.comp/6907242?tree=tree
Автор: Ikemefula
Дата: 18.09.17

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

По ссылке два числа для каждого из языков. Видишь ? Тебе понятно, что эти вещи сравнивают разные языковые фичи ? Инициализация сранивает ленивость, сортировка — энергичный код.

>Совершенно поразительная избирательность у твоего железа.



Здесь первая версия C# сравнивается с первой версией JS.

1 инциализация — быстрее C#, потому что yield в ES6 адски медленные. Такой вот факт.
2 сортировка — быстрее JS, потому что в C# тормозит дефолтный компаратор. Собственно это демонстрация того, почему и нужен CompareOrdinal.

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

CM>Может, просто признаешь, что цифры с потолка взял? И так ведь очевидно, зато у тебя совесть чище будет.


Похоже, ты вообще не читаешь, что тебе пишут.

P.S. Если посмотреть, что было дальше
1. твой комп работает примерно вдвое быстрее моего — разница в C# по сортировке 2.5 против 4.7 Собственно и в других сравнениях ровно то же. Там где у тебя ~0.5 у меня ~1с.
2. первую версию JS ты начал запускать в фоксе, когда надо было в хроме.

Вместо того, что бы разобраться, ты перешел к обвинениям
Re[70]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 27.10.17 17:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Инициализация сранивает ленивость, сортировка — энергичный код.



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

I>1. твой комп работает примерно вдвое быстрее моего — разница в C# по сортировке 2.5 против 4.7 Собственно и в других сравнениях ровно то же. Там где у тебя ~0.5 у меня ~1с.


И при этом у меня вызывает серьезнейшее недоумение тот факт, что сортировка в JS у тебя сработала намного быстрее, чем у меня (в Хроме). А у тебя — быстрее, на железе, которое в два раза медленнее моего. Удивительно, не правда ли?
Ну так что, кто тут не читает?

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

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


Тест показывает только узкое место. Если JS переписать инициализацию на энергичный цикл, что будет, ась ? Попробуй на досуге.

I>>1. твой комп работает примерно вдвое быстрее моего — разница в C# по сортировке 2.5 против 4.7 Собственно и в других сравнениях ровно то же. Там где у тебя ~0.5 у меня ~1с.


CM>И при этом у меня вызывает серьезнейшее недоумение тот факт, что сортировка в JS у тебя сработала намного быстрее, чем у меня (в Хроме). А у тебя — быстрее, на железе, которое в два раза медленнее моего. Удивительно, не правда ли?


Нет ничего удивительного. Эту часть я уже объяснял несколько раз
1. JS выдает очень большой разброс в показаниях.
Ты ведь видел это, не так ли ?
1.5с — как думаешь, какое число я взял из __серии__ замеров ?
2. _точная_ версия твоего JS-рантайма какая ? А у меня ? Надеюсь, ты помнишь, что речь была про эксперимернтальный рантайм ? На стандартном числа совсем другие, но расклад тот же — инициализация в пользу C#, сортировка — в пользу JS.
3. Разница в быстродействии в C# только предположение. Ты уверен, что между моим фремворком и твоим нет разницы даже на одном железе ?

Собственно я уже полтора месяца повторяю раз за разом одно и то же, но ты ухитряешься как то по-особенному вычитывать, кусочками — сам себе пазл составляешь на ходу.
Отредактировано 27.10.2017 18:29 Pauel . Предыдущая версия .
Re[72]: Реальная производительность WebAssembly?
От: CoderMonkey  
Дата: 27.10.17 19:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


А, ну замечательно. "Это в JS тормозит, мы это измерять не будем. То в JS тормозит, мы его измерять тоже не будем."

I>1. JS выдает очень большой разброс в показаниях.

I> Ты ведь видел это, не так ли ?

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

I> 1.5с — как думаешь, какое число я взял из __серии__ замеров ?


Минимальное, конечно же? Я вижу, без мухлежа ты просто жить не можешь.

I>2. _точная_ версия твоего JS-рантайма какая ? А у меня ? Надеюсь, ты помнишь, что речь была про эксперимернтальный рантайм ?


Да-да, я помню. А какой чудак вообще опирается на данные экспериментальных версий? Стандартный выбор нормального человека — это последний релиз.

I>На стандартном числа совсем другие, но расклад тот же — инициализация в пользу C#, сортировка — в пользу JS.


Только если в JS версии подмухлевать с форматтером и компарером, как мы уже обнаружили. А если не мухлевать, то JS сливает в обеих половинах теста.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[73]: Реальная производительность WebAssembly?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.10.17 11:35
Оценка: :)
Здравствуйте, CoderMonkey, Вы писали:

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


CM>А, ну замечательно. "Это в JS тормозит, мы это измерять не будем. То в JS тормозит, мы его измерять тоже не будем."


А что, по твоему, мы замерили в инициализации в JS ? Как раз то, что тормозит.
А если поменять ленивую часть, на энергичную, получим гораздо более другой расклад. Следовательно ленивость и есть узкое место в JS.

Кстати говоря, именно эти тормоза (yield) уже пофиксили:
Init, miliseconds: 1598
Sort miliseconds: 1573

Node 8.8.1. Только волосы не рви на себе — это еще одно железо, игровой ноутбук трехлетней давности.

I>>1. JS выдает очень большой разброс в показаниях.

I>> Ты ведь видел это, не так ли ?

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


А ты не пробовал дочитать до конца, прежде чем срывать покровы ?

I>> 1.5с — как думаешь, какое число я взял из __серии__ замеров ?


CM>Минимальное, конечно же? Я вижу, без мухлежа ты просто жить не можешь.


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

I>>2. _точная_ версия твоего JS-рантайма какая ? А у меня ? Надеюсь, ты помнишь, что речь была про эксперимернтальный рантайм ?


CM>Да-да, я помню. А какой чудак вообще опирается на данные экспериментальных версий? Стандартный выбор нормального человека — это последний релиз.


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

I>>На стандартном числа совсем другие, но расклад тот же — инициализация в пользу C#, сортировка — в пользу JS.


CM>Только если в JS версии подмухлевать с форматтером и компарером, как мы уже обнаружили. А если не мухлевать, то JS сливает в обеих половинах

теста.

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

Напоследок — я то пофиксил и сортировку в C#, а ты замеряешь свой "алгоритм" у которого всего лишь асимптотика такая же, а абсолютно число компараций отличается. Хы-хы.
Отредактировано 28.10.2017 12:20 Pauel . Предыдущая версия . Еще …
Отредактировано 28.10.2017 11:43 Pauel . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.