Здравствуйте, Ночной Смотрящий, Вы писали:
_>> Именно это и надо для теста. НС>Нет, для теста надо идентичные алгоритмы.
Для теста нужны идентичные данные на входе и на выходе. А в середине крутись как можешь. Это и будет объективное сравнение языков, потому что так оно происходит в реальности.
Здравствуйте, CoderMonkey, Вы писали:
A>>Нафиг не надо. Ты там написал "А давай ка посмотрим на более близкий к реальности код?", но кто будет в реальности писать свою сортировку, если однострочный Array.Sort быстрее. Быстрее работает, быстрее писать, быстрее понимать, легче поддерживать. CM>Спасибо, Кэп. Вопрос в том, что внутри реализация может быть сильно разной.
Неважно. Если в JS нет указателей, к примеру, это его проблемы. Ты ведь не будешь писать код на C#, постоянно вспоминая, что в JS нет указателей? Если в JS нет quick sort (может и есть, я не знаю), то пусть тот, кто пишет на JS, сам делает свою реализацию.
Здравствуйте, Ikemefula, Вы писали:
A>>Самодельный quick sort непонятно зачем. Стандартный Array.Sort работает немного быстрее. I>А мы сравниваем языки по перформансу, а не либы.
Тип System.Array в C# есть всегда. Входит в CLR наравне с System.Int32 или System.String. Мы же не станем велосипедить ещё и конкатенацию строк?
A>>А с такой реализацией TestClass: A>>
class TestClass
A>>{
A>> private Guid idGuid = Guid.NewGuid();
A>> private Guid valueGuid = Guid.NewGuid();
A>> public string Id => Format(idGuid);
A>> public string Value => Format(valueGuid);
A>>}
A>>инициализация массива минимум в 3 раза быстрее начальной, а его сортировка минимум в 11 раз быстрее. Общее ускорение по сравнению с оригинальным кодом — более чем в 7 раз. I>Я чет не понял, ты собираешься конвертить в строку при каждом доступе к свойству ? И зачем тебе гуид хранить, что бы памяти больше съесть ?
1. Я не вижу в коде никого, кому были бы нужны строковые представления гуидов. Ни одного их потребителя. Разве что TestClass.ToString, но и тот нигде не вызывается.
2. Guid — value-тип длинной 16 байт. В виде строки он занимает (навскидку) 32*2+6 байт + оверхед + 4/8 байт под ссылку на эту строку. Гуиды экономнее аналогичных строк раз в пять.
Я бы TestClass вообще в TestStruct переделал. ТЗ нет, JS нам не указ, никто так делать не запрещает, памяти расходуется ещё меньше, локальность данных лучше, скорость инициализации и сортировки ещё выше.
I>Выложи полную версию кода, только напиши на какой версии фремворка/шарпа надо сранивать. У меня, скажем, только 4.0 есть
Сейчас перетестил поаккуратнее, получилось, что оптимизированная версия быстрее оригинальной в 11 раз, а оптимизированная со структурами — в 16 раз.
Оригинальная версия на C#:
Initialization: 1710 ms, Sorting: 5464 ms, Total: 7174 ms
Initialization: 1847 ms, Sorting: 5162 ms, Total: 7009 ms
Initialization: 1976 ms, Sorting: 4937 ms, Total: 6913 ms
Initialization: 1729 ms, Sorting: 5275 ms, Total: 7004 ms
Initialization: 1988 ms, Sorting: 5031 ms, Total: 7019 ms
GC: 360 131 17 <-- количество сборок мусора по поколениям 0, 1, 2
Оптимизированная версия C#:
Initialization: 232 ms, Sorting: 398 ms, Total: 630 ms
Initialization: 265 ms, Sorting: 403 ms, Total: 668 ms
Initialization: 321 ms, Sorting: 394 ms, Total: 715 ms
Initialization: 271 ms, Sorting: 395 ms, Total: 666 ms
Initialization: 279 ms, Sorting: 404 ms, Total: 683 ms
GC: 46 24 8
Оптимизированная версия C# с заменой TestClass на TestStruct:
Initialization: 184 ms, Sorting: 256 ms, Total: 440 ms
Initialization: 185 ms, Sorting: 251 ms, Total: 436 ms
Initialization: 185 ms, Sorting: 248 ms, Total: 433 ms
Initialization: 185 ms, Sorting: 249 ms, Total: 434 ms
Initialization: 185 ms, Sorting: 247 ms, Total: 432 ms
GC: 4 4 4
I>Предлагаешь запилить рей-трейсинг алгоритм или обработку звука ? Не многовато ли для форумной беседы ?
Предлагаю запилить что-нибудь менее абстрактное, более практичное и с понятными конкретными требованиями. Например:
1. Считать png-картинку размера 1024x1024, перевести в чёрно-белый, заблюрить, повернуть на 90 градусов по часовой стрелке, сохранить обратно в png рядом с исходным.
2. Считать png-картинку размера 1024x1024 с лабиринтом (черные пикселы — препятствия, белые — проходимые). Найти кратчайший путь из левого нижнего угла в правый верхний. Результат сохранить в текстовый файл в виде количества узлов пути и списка их координат
N
(x1, y1)
(x2, y2)
...
(xN, yN)
Здравствуйте, CoderMonkey, Вы писали:
_>>Тебе вроде как уже несколько человек сказали, что при тестах производительности надо выбирать самую быструю реализацию на данном языке, а не самую медленную. А то иначе можно доказать что и bash быстрее ассемблера x64... CM>Сравнивать надо, по возможности, аналоги, а не выбирать "что с чем мне выгоднее сравнить". Иначе грош цена таким сравнениям.
Нужно сравнивать не аналоги и не "что с чем выгодно", а вполне конкретную вещь: наиболее эффективное решение на данном языке для конкретной, точно сформулированной задачи. Т.е. вот твоя постановка задачи (но не реализация!) с quicksort для некого однозначно определённого (два строковых id поля фиксированной ширины) объекта — это в принципе очень даже не плохой пример. А вот как его будут реализовывать на каждом конкретном языке — это уже личное дело данного языка.
_>>Вообще то ничего не обнаружилось и никакого мухлежа естественно не было. Но ты знаешь, я согласен даже считать что проигрыш C# всего в 3 раза относительно аналогичного JS кода, чтобы не препираться лишний раз. Всё равно итоговая ситуация получается крайне забавной. ))) CM>Обнаружилось. Ты взял минимальный возможный замер, а не среднее значение.
Оу, т.е. ты кроме всего прочего ещё и ничего не понимаешь в тестах производительности... Среднее значит, понятненько...
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Что значит хуже? НС>То и значит что сравнить ты пытаешься разные алгоритмы. _>> Как раз лучше, т.к. быстрее при тех же самых входных/выходных данных. НС>Это называется мухлеж. _>> Именно это и надо для теста. НС>Нет, для теста надо идентичные алгоритмы.
сообщения не эквивалентен JS коду из того же сообщения? И если это именно так, то тебя конечно же не затруднит продемонстрировать уже полностью эквивалентный тому же самому JS коду вариант на C#? А мы тогда все вместе его потестируем и наконец сделаем выводы, с которыми уже никто не будет спорить (надеюсь)...
Здравствуйте, alex_public, Вы писали:
_> И если это именно так, то тебя конечно же не затруднит продемонстрировать уже полностью эквивалентный тому же самому JS коду вариант на C#?
Конечно же затруднит. Я сейчас в отпуске в южных широтах и код тут писать, корячась на ноуте, не собираюсь.
using System;
using System.Diagnostics;
namespace QuickSort
{
public class Program
{
public static void Main(string[] args)
{
var watch = new Stopwatch();
for (int i = 0; i < 5; i++)
{
watch.Restart();
var vals = new TestClass[1000 * 1000];
for (int j = 0; j < vals.Length; j++)
{
vals[j] = new TestClass();
}
watch.Stop();
Console.WriteLine($"Total: {watch.ElapsedMilliseconds} ms");
}
Console.WriteLine($"GC: {GC.CollectionCount(0)} {GC.CollectionCount(1)} {GC.CollectionCount(2)}");
Console.ReadLine();
}
}
internal class TestClass
{
public string Id = CreateGuid();
public string Value = CreateGuid();
private static readonly Random gen = new Random();
private static string CreateGuid() => gen.Next(100000000).ToString("0000000000");
}
}
Total: 567 ms
Total: 652 ms
Total: 641 ms
Total: 606 ms
Total: 638 ms
GC: 114 60 15
Одинаково.
В C# в районе 40% времени приходится на стандартный рандом и 50% на ToString с параметром.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> И если это именно так, то тебя конечно же не затруднит продемонстрировать уже полностью эквивалентный тому же самому JS коду вариант на C#? НС>Конечно же затруднит. Я сейчас в отпуске в южных широтах и код тут писать, корячась на ноуте, не собираюсь.
Ну да, ну да. )))
Кстати, я же так понял, что у тебя к моему варианту C# кода ровно одна претензия — в том что использованная там функция ToString() вроде как не эквивалентна toString() из JS, т.к. использует системную локаль (хотя куда там расходовать ресурсы на целых числах без группировки не очень понятно, ну да ладно, поверим тебе на слово). Соответственно тебе достаточно подсказать какую именно .net функцию использует правильный программист на C# для написания подобного оптимального кода.
Здравствуйте, alexzzzz, Вы писали:
A>Оптимизированная версия C#:
а зачем ты убрал сам алгоритм ? Мы же не сравниваем библиотеки. Вопрос в том, насколько качественный код будет выполняться.
A>Предлагаю запилить что-нибудь менее абстрактное, более практичное и с понятными конкретными требованиями. Например:
Здравствуйте, CoderMonkey, Вы писали:
I>>И ты уверен, что на любом рантайме и железе будет тот же результат?
CM>Я уверен, что разница в 2-3 раза, причем в одном случае в большую сторону, а в другой раз в меньшую, и оба раза — в твою пользу, то это крайне странно и подозрительно.
> Вообще стоит читать, что тебе пишут. Проблема в твоём коде, ты сам его сделал тормозом
>Ну а поскольку твой код, который ты запостил, даже не запускается — скорее всего, ты просто наврал.
И как же ты его запустил ?
I>>На чем запускаешь, в браузере каком?
CM>Толстолис v55, 64 бита.
Я так и думал. Хорошо хоть не интернет эксплорер.
Запусти его в хроме последнем, в ноде 6м или 8м. Ты в курсе, что разные рантаймы имеют сильно разный перформанс ? Вот скажем MS Edge вообще 20 секунд сортирует.
Здравствуйте, CoderMonkey, Вы писали:
I>>А ты крут — на коленке честный табличный процессор запилить со всеми фичами, как у гугла.
CM>Тест запилить могу, естественно. Если ты сумеешь убедить меня, что стоит тратить на тебя время. А пилить именно всё приложение — необязательно.
Браво, ты предлагаешь сравнить гуглошит с наколеночной поделкой ?
I>>Собственно сравнение некорректное.
CM>Вот уже и превентивная попытка поюлить началась
Наоборот, ты предлагаешь сравнить память на данные +память на код с памятью толко на данные у экселя.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Я как ни зайду на форум, у тебя вечно ктото сливает Ты себя лучше после такого чувствуешь или что ?
НС>При чем тут я? Я на личности не переходил. А вы только этим и занимаетесь, потому что аргументов нет.
Ага, ты точно ни при чем. Когда следующий слив планируешь ?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> И если это именно так, то тебя конечно же не затруднит продемонстрировать уже полностью эквивалентный тому же самому JS коду вариант на C#?
НС>Конечно же затруднит. Я сейчас в отпуске в южных широтах и код тут писать, корячась на ноуте, не собираюсь.
Собственно, как и всегда. У тебя кроме морализаторства ничего и нет.
Здравствуйте, alexzzzz, Вы писали:
A>1. Я не вижу в коде никого, кому были бы нужны строковые представления гуидов. Ни одного их потребителя. Разве что TestClass.ToString, но и тот нигде не вызывается. A>2. Guid — value-тип длинной 16 байт. В виде строки он занимает (навскидку) 32*2+6 байт + оверхед + 4/8 байт под ссылку на эту строку. Гуиды экономнее аналогичных строк раз в пять.
А что, конверсия в строку при каждом доступе ничего не стоит ?
Кроме того, в тесте ведь не важно, что в строке. Главное что бы одинаково в обоих языках и были более-менее случайные символы.
Тест он про сортировку массива объектов, у которых есть строковые свойства. Гуиды там или не гуиды, дело десятое.
а зачем ты убрал сам алгоритм ? Мы же не сравниваем библиотеки. Вопрос в том, насколько качественный код будет выполняться.
Ты себя лучше после такого чувствуешь или что ?
