Здравствуйте, alexzzzz, Вы писали:
A>Таким образом, берём решение задачи, оптимизированное по скорости средствами языка А, берём решение задачи, оптимизированное по скорости средствами языка Б, и сравниваем их между собой. Любые другие сравнения лишены практического смысла.
Чорт, по таким правилам C# слил втрое, потому что в самой сортировке только массив перетасовывается.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> Т.е. ты сейчас идеально подтвердил моё предположение о том, что ты стал писать на форуме вообще не читая предыдущие обсуждения и даже не понимая о чём реально речь.
НС>Не, это ты в очередной раз слил.
Я как ни зайду на форум, у тебя вечно ктото сливает Ты себя лучше после такого чувствуешь или что ?
Здравствуйте, alexzzzz, Вы писали:
A>Таким образом, берём решение задачи, оптимизированное по скорости средствами языка А, берём решение задачи, оптимизированное по скорости средствами языка Б, и сравниваем их между собой. Любые другие сравнения лишены практического смысла.
Оу, в темку подъехали здравомыслящие люди! Не может быть. )))
Здравствуйте, alexzzzz, Вы писали:
A>Таким образом, берём решение задачи, оптимизированное по скорости средствами языка А, берём решение задачи, оптимизированное по скорости средствами языка Б, и сравниваем их между собой. Любые другие сравнения лишены практического смысла.
И что мы в итоге сравниваем? Пузырьковую сортировку с быстрой?
. НС>Заменив на toString, работающую по самому примитивному алгоритму? Ну так я тебе уже сказал, что это намного хуже, чем исходный вариант.
Что значит хуже? Как раз лучше, т.к. быстрее при тех же самых входных/выходных данных. Именно это и надо для теста. Или ты хочешь внести новое слово в тестирование производительности, в котором будут рассматривать не самые быстрые, а самые сложные алгоритмы?
Здравствуйте, alex_public, Вы писали:
CM>На самом деле нет. Единственное, что тормозило в предыдущем примере — это ToString.
То, что твой вывод про массивы — ложный.
_>Так это оказывается было ещё в пользу .net сравнение. Потому как взяв твой пример теста (с объектами и динамическим выделением памяти), я бы получил проигрыш .net'а в разы...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, alexzzzz, Вы писали:
A>>Таким образом, берём решение задачи, оптимизированное по скорости средствами языка А, берём решение задачи, оптимизированное по скорости средствами языка Б, и сравниваем их между собой. Любые другие сравнения лишены практического смысла.
I>Чорт, по таким правилам C# слил втрое, потому что в самой сортировке только массив перетасовывается.
class TestClass
{
private Guid idGuid = Guid.NewGuid();
private Guid valueGuid = Guid.NewGuid();
public string Id => Format(idGuid);
public string Value => Format(valueGuid);
public override string ToString() => Id;
private string Format(Guid guid) => guid.ToString().Replace("-", "");
public class TestClassComparer : IComparer<TestClass>
{
public int Compare(TestClass x, TestClass y) => x.idGuid.CompareTo(y.idGuid);
}
}
инициализация массива минимум в 3 раза быстрее начальной, а его сортировка минимум в 11 раз быстрее. Общее ускорение по сравнению с оригинальным кодом — более чем в 7 раз.
Здравствуйте, Ikemefula, Вы писали:
I>Я больше 10 лет на дотнете писал. Из за тяжелых фремворков геморроя гораздо больше. I>Когда фремворк не делает того что надо, или делает не так как надо, часто вообще никаких способов обойти нет
Например?
I>А вот в JavaScript такие вещи гораздо реже встречаются. Это первое, что я заметил, когда пересел на JavaScript.
Помнится, с год назад ходил текст о выборе "правильных" инструментов для JS и их замечательной работе.
Здравствуйте, CoderMonkey, Вы писали:
A>>Самодельный quick sort непонятно зачем. CM>Чтобы сравнивать по возможности одинаковый код, естественно.
Нафиг не надо. Ты там написал "А давай ка посмотрим на более близкий к реальности код?", но кто будет в реальности писать свою сортировку, если однострочный Array.Sort быстрее. Быстрее работает, быстрее писать, быстрее понимать, легче поддерживать.
Здравствуйте, alexzzzz, Вы писали:
A>Нафиг не надо. Ты там написал "А давай ка посмотрим на более близкий к реальности код?", но кто будет в реальности писать свою сортировку, если однострочный Array.Sort быстрее. Быстрее работает, быстрее писать, быстрее понимать, легче поддерживать.
Спасибо, Кэп. Вопрос в том, что внутри реализация может быть сильно разной.
A>Нафиг не надо. Ты там написал "А давай ка посмотрим на более близкий к реальности код?", но кто будет в реальности писать свою сортировку, если однострочный Array.Sort быстрее. Быстрее работает, быстрее писать, быстрее понимать, легче поддерживать.
При этом внутри Array.Sort там была отдельная реализация для примитивных типов.
При этом мы оцениваем именно скорость Jit ров выполнения, а не конкретной реализации, которая может быть нативной на C++. Просто копироваться массивы
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, CoderMonkey, Вы писали:
I>>Я как ни зайду на форум, у тебя вечно ктото сливает Ты себя лучше после такого чувствуешь или что ?
CM>К вопросу о сливах, ты на вопрос так и не ответил. Re[24]: Реальная производительность WebAssembly?
Здравствуйте, CoderMonkey, Вы писали:
I>>Когда фремворк не делает того что надо, или делает не так как надо, часто вообще никаких способов обойти нет
CM>Например?
Это вообще проблема всех больших библиотек. В них можно делать только то, что предусмотрено и хорошо работает.
Например аппаратно ускореный wpf кривой шо сабля. А вообще больше похож на аппаратно замедленный. Как быть?
I>>А вот в JavaScript такие вещи гораздо реже встречаются. Это первое, что я заметил, когда пересел на JavaScript.
CM>Помнится, с год назад ходил текст о выборе "правильных" инструментов для JS и их замечательной работе.
Такие текста ходят про все популярные технологии.
До кучи — я чисто на js пишу уже пять лет. Ты точно хочешь открыть мне страшную тайну?
Здравствуйте, CoderMonkey, Вы писали:
CM>>На самом деле нет. Единственное, что тормозило в предыдущем примере — это ToString. CM>То, что твой вывод про массивы — ложный. _>>Так это оказывается было ещё в пользу .net сравнение. Потому как взяв твой пример теста (с объектами и динамическим выделением памяти), я бы получил проигрыш .net'а в разы... CM>Чувак, у тебя температуры нет?
Так, давай подведём итоги, а то мне надоела эта пустая болтовня. И так по пунктам:
1. Был некий мой старый тест сравнение производительности языков на обработке двухмерных массивов. Причём всплыл он тут как тест для WebAssembly (а все остальные языки там были для сравнения), но об этом уже все благополучно забыли. ))) И в этом тесте JS и C# (без unsafe) имеют сходную производительность.
2. Тебе показался сомнительным данный результат теста, т.к. по твоему утверждению JS медленнее C# в 10-20 раз.
3. Для доказательства своего утверждения, ты предложил некий свой тест с созданием и сортировкой массива объектов.
4. По результатам запуска этого теста (точнее только его начальной части с инициализаций массивов, т.к. код с сортировкой на JS ты не осилил, а писать за тебя код для твоего теста у меня никакого желания нет) мы увидели проигрыш C# в 3 раза на твоей машине и в 8 раз на моей.
Я ничего не упустил, всё верно? ) И после всего этого ты ещё продолжаешь что-то писать в данной темке? )))
Здравствуйте, alexzzzz, Вы писали:
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 раз.
Я чет не понял, ты собираешься конвертить в строку при каждом доступе к свойству ? И зачем тебе гуид хранить, что бы памяти больше съесть ?
Выложи полную версию кода, только напиши на какой версии фремворка/шарпа надо сранивать. У меня, скажем, только 4.0 есть
Ты себя лучше после такого чувствуешь или что ?
