Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Там говорится что точность недостаточна, но ведь не на столько же — тут же речь идёт о лишней сотне миллисекунд.
Верно, дело не в точности, N достаточно велико. Это чудит микрософтовский компилятор — сопоставимого времени (50 ms) с C# вариантом (65 ms) удалось добиться только для x64, сделав передачу аргументов по ссылке
Здравствуйте, PM, Вы писали:
PM>Верно, дело не в точности, N достаточно велико. Это чудит микрософтовский компилятор — сопоставимого времени (50 ms) с C# вариантом (65 ms) удалось добиться только для x64,
У меня по-умолчанию было x32, для x64 результат примерно такой же — разницы на 100ms нет.
PM>сделав передачу аргументов по ссылке
У GCC ASM идентичный в обоих случаях. Если у MSVC из-за этого такая разница — то нужно отправлять report, так как случай тривиальный.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
PM>>Верно, дело не в точности, N достаточно велико. Это чудит микрософтовский компилятор — сопоставимого времени (50 ms) с C# вариантом (65 ms) удалось добиться только для x64,
EP>У меня по-умолчанию было x32, для x64 результат примерно такой же — разницы на 100ms нет.
PM>>сделав передачу аргументов по ссылке
EP>У GCC ASM идентичный в обоих случаях. Если у MSVC из-за этого такая разница — то нужно отправлять report, так как случай тривиальный.
Попробовал на Visual C++2015 RC, передача аргументов по ссылке: ~50 мс, по значению: ~60 мс. Сгенерированный код смотреть даже и не хочется, скорее всего VC2013 не осилил заинлайнить benchmark и std::transform
Думаю, репорт уже не поможет — МС не любит чинить баги в предыдущих версиях Visual C++. Где-то я читал, что обновлений для Visual C++2013 больше не будет. Видимо все силы брошены на выпуск новой версии.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
G>>А вот List, похоже, тормозит из-за проверки индекса, которую нельзя убрать, с помощью unsafe
Кстати, я забыл поставить unchecked вчера и никто не заметил.
unchecked
{
for (int i = 0; i < n; i++)
{
v[i] = v[i] * u[i];
}
}
.NET Elapsed: 102.0000 ms
Elapsed = 93.6 ms
.NET Elapsed: 102.0000 ms
Elapsed = 93.601 ms
.NET Elapsed: 104.0000 ms
Elapsed = 78.001 ms
.NET Elapsed: 105.0000 ms
Elapsed = 78 ms
.NET Elapsed: 101.0000 ms
Elapsed = 78 ms
.NET Elapsed: 105.0000 ms
Elapsed = 78 ms
.NET Elapsed: 109.0000 ms
Elapsed = 93.6 ms
.NET Elapsed: 107.0000 ms
Elapsed = 78.001 ms
.NET Elapsed: 106.0000 ms
Elapsed = 78 ms
.NET Elapsed: 107.0000 ms
Elapsed = 78 ms
EP>Не думаю что из-за проверки индекса будет такая разница — branch predictor должен с ней неплохо справится. Желательно посмотреть какой там ASM получается.
Смотри цифры наверху. Но это от unchecked и массива. То есть, немного другой случай.
EP>На MSVC++ если использовать std::vector::at, внутри которого такая же проверка, то там разница на десятки процентов а не в разы.
Согласен. Я это и имел ввиду. На десятки процентов, а то и меньше.
UPD:
не, не обращайте внимание. Сравнил IL, он такой же. Просто моя машина сегодня немножко быстрее работает Тем более, что калькуляция вообще не там происходит.
В щарпе геттер делается не методами а свойствами, поля не нужны(практически никогда), но да что бы прям как конст такого нет.
В другом случае если ваш коллега пхд из индии может залезть в исходники он может ваш конст убрать.
Здравствуйте, PM, Вы писали:
PM>Попробовал на Visual C++2015 RC, передача аргументов по ссылке: ~50 мс, по значению: ~60 мс. Сгенерированный код смотреть даже и не хочется, скорее всего VC2013 не осилил заинлайнить benchmark и std::transform
На VS2012 ситуация следующая:
* во всех четырёх вариантах сам transform не инлайнится (для этого теста особо без разницы)
* все внутренности transform заинлайнены (лямбда, оператор)
* на x32 отличие в ASM минимальное, отличие в скорости незаметно
* на x64 в версии по значению появляется код с лишними обращениями к стэку, отличие по скорости по этому таймеру около 10ms.
PM>Думаю, репорт уже не поможет — МС не любит чинить баги в предыдущих версиях Visual C++. Где-то я читал, что обновлений для Visual C++2013 больше не будет. Видимо все силы брошены на выпуск новой версии.
Тут две проблемы:
* одна про то что на VS2013 (на ней же тормоза были?) в трёх версиях появляется разница в 100ms — её видимо в 2015 уже пофиксили
* сильное отличие кода между вариантами на x64, которого нет на x32 — она по всей видимости осталась. Подобного кода много даже в самом стандарте — функциональные объекты в алгоритмах, std::next/prev и т.д.
Здравствуйте, greenpci, Вы писали:
G>>>А вот List, похоже, тормозит из-за проверки индекса, которую нельзя убрать, с помощью unsafe G>Кстати, я забыл поставить unchecked вчера и никто не заметил.
Забыл/не забыл зависит от того что именно ты хотел протестировать. А так, если интересно, то можешь ещё и на указателях попробовать через fixed.
Здравствуйте, greenpci, Вы писали:
G>Кстати, я забыл поставить unchecked вчера и никто не заметил.
G>
G>unchecked
G>{
G> for (int i = 0; i < n; i++)
G> {
G> v[i] = v[i] * u[i];
G> }
G>}
G>
Ты уверен, что в шарпе ты с бубном танцевал меньше, чем я в Яве?
Кстати, в Яве объекты дают только 3.5х просадку (~185мс против 58 мс) в отличии от полного ужоса шарпа (~4700 мс против 110 мс).
С опциями JVM, кстати, я не игрался в этом тесте. В отличии от...
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Забыл/не забыл зависит от того что именно ты хотел протестировать. А так, если интересно, то можешь ещё и на указателях попробовать через fixed.
Филосовский вопрос в следующем. Можно ли будет этот код на указателях и fixed назвать шарпом, или это будет Си плюс плюсная вставка в шарп?! Наподобие asm в си и паскале.
Я хотел понять для себя, можно ли написать управляемых код, который будет таким же быстрым, как Си плюс плюс, в рамках этой задачи. На данный момент, делаю вывод, что нельзя. Будет разница в пользу плюсов. То есть плюсы бытсрее.
И больше склоняюсь к выводу, что эти утверждения внизу ложны:
mik1 писал:
2) Я не думаю, что с byte[] в Яве управляться труднее, чем в плюсах. Соот-но, время и пространство не факт, что ухудшатся.
UPD: хотя вот в этом утверждении ниже unmanaged, и уже встает вопрос, зачем тогда вообще писать на шарпе.
gandjustas писал:
А с unmanaged можно писать на C# как на С (c соответствующими скоростями)
Здравствуйте, mik1, Вы писали:
M>Ты уверен, что в шарпе ты с бубном танцевал меньше, чем я в Яве?
нет, я ставлю вопрос managed vs C++, а не C# vs Java. Я слишком плохо знаю джаву для второго. На текущий момент, плюсы рулят и по скорости и по приятности кода.
M>Кстати, в Яве объекты дают только 3.5х просадку (~185мс против 58 мс) в отличии от полного ужоса шарпа (~4700 мс против 110 мс).
Не утешает. Обе просадки для моей задачи не допустимы.
M>С опциями JVM, кстати, я не игрался в этом тесте. В отличии от...
С плюсами тоже можно еще поиграться. Взять компилятор от интел, например.
Здравствуйте, mik1, Вы писали:
M>Кстати, в Яве объекты дают только 3.5х просадку (~185мс против 58 мс) в отличии от полного ужоса шарпа (~4700 мс против 110 мс).
У тебя наверное без перемешивания — а на C# насколько я помню был shuffle
Здравствуйте, greenpci, Вы писали:
EP>>Забыл/не забыл зависит от того что именно ты хотел протестировать. А так, если интересно, то можешь ещё и на указателях попробовать через fixed. G>Филосовский вопрос в следующем. Можно ли будет этот код на указателях и fixed назвать шарпом, или это будет Си плюс плюсная вставка в шарп?! Наподобие asm в си и паскале.
Это всё же будет C#, но такой код будет называться C-style. В Java даже этого нельзя — там будет C-minus-structs-style.
Точно также как на C++ можно писать в Java-style с кучей лишних индерекций, аллокаций, избыточным динамическим полиморфизмом и раздутыми иерархиями, и за это справедливо получать тормоза.
G>Я хотел понять для себя, можно ли написать управляемых код, который будет таким же быстрым, как Си плюс плюс, в рамках этой задачи. На данный момент, делаю вывод, что нельзя. Будет разница в пользу плюсов. То есть плюсы бытсрее.
Справедливости ради, эти десятки процентов не такая уж и значительная разница. Могу ещё раз повторится — и на Java и на C# можно писать быстрый код, но на C++ быстрый код получить на порядки проще. Даже есть вот такая цитата:
"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Справедливости ради, эти десятки процентов не такая уж и значительная разница. Могу ещё раз повторится — и на Java и на C# можно писать быстрый код, но на C++ быстрый код получить на порядки проще. Даже есть вот такая цитата: EP>
EP>"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu
Не стоит верить на слово в такие цитаты.
Во-первых fb переписал добрую половину STL, что уже недоступно в любом среднем проекте и большинстве крупных.
Во-вторых проценты прироста быстродействия в масштабах ФБ это десятки и сотни серверов, и это действительно стоит затраченных сотен тысяч и миллионов долларов на ЗП программистов.
Для большинства проектов проценты прироста быстродействия останутся незамеченными и дешевле будет сделать апгрейд железа, чем заниматься оптимизацией. Поэтому утверждение что "на C++ быстрый код получить на порядки проще" не имеет никакого смысла и верно только в контексте фейсбука\гугла и еще пары-тройки гигантов. В остальных случаях сложность оптимизации на C++ и C# (и иногда Java) сравнимы, а учитывая в общем более высокую сложность разработки на C++ еще непонятно что будет проще в итоге.
ЗЫ. При этом никто не сомневается что предел оптимизации программы на C++ выше, чем для C# или Java. Но достижение этого предела превышает в большинстве случаев выльется в слишком большие затраты.
Здравствуйте, gandjustas, Вы писали:
G>Не стоит верить на слово в такие цитаты.
Не верить в то что такая цитата была? Можем проверить.
Или в то что так на самом деле? Весь топик выше как раз это и демонстрирует
G>Во-первых fb переписал добрую половину STL, что уже недоступно в любом среднем проекте и большинстве крупных.
1. И какой ты делаешь из этого вывод?
2. У них есть оптимизации некоторых контейнеров под их нужды — это далеко не половина STL. Причём в "среднем проекте" в котором я работаю есть подобные оптимизированные контейнеры, а один из них вообще точь в точь такой же (когда делал они ещё не выложили свой на github).
G>Во-вторых проценты прироста быстродействия в масштабах ФБ это десятки и сотни серверов, и это действительно стоит затраченных сотен тысяч и миллионов долларов на ЗП программистов.
Тезис в цитате (с которым я полностью согласен) довольно прост — на C++ проще создать быстрый код. Ты же пытаешься передёрнуть в какую-то совершенно другую плоскость
G>Для большинства проектов проценты прироста быстродействия
Причём тут "проценты"?
Выше как раз показано что при использовании Java-style это не проценты, а разы, и даже порядки.
G>останутся незамеченными и дешевле будет сделать апгрейд железа, чем заниматься оптимизацией. Поэтому утверждение что "на C++ быстрый код получить на порядки проще" не имеет никакого смысла и верно только в контексте фейсбука\гугла и еще пары-тройки гигантов.
Ты почему-то говоришь в контексте каких-то отдельных областей типа web'а — причём так, что как-будто ничего другого нет. Уж поверь "быстрый код на C++" нужен не только гигантам.
Тебе попадаются задачи где не нужен? Поздравляю, вот только не надо необоснованно экстраполировать свой опыт на всю индустрию.
G>В остальных случаях сложность оптимизации на C++ и C# (и иногда Java) сравнимы, а учитывая в общем более высокую сложность разработки на C++ еще непонятно что будет проще в итоге.
Нет, не сравнимы. В C++ я могу сделать много уровней абстракций, которые будут либо бесплатными, либо крайне дешёвыми. В C#, а тем более Java, так не получится. И вот за счёт этого получается проще.
G>ЗЫ. При этом никто не сомневается что предел оптимизации программы на C++ выше, чем для C# или Java. Но достижение этого предела превышает в большинстве случаев выльется в слишком большие затраты.
Мой поинт наоборот противоположный, и я уже устал его повторять:
Предел оптимизации везде примерно одинаковый, разница в десятки процентов это не так уж серьёзно. Но на C++ этот предел гораздо проще достичь.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Тезис в цитате (с которым я полностью согласен) довольно прост — на C++ проще создать быстрый код. Ты же пытаешься передёрнуть в какую-то совершенно другую плоскость
Плоскость та же самая. Просто ответь на вопрос насколько проще и насколько нужна скорость с учетом всех факторов, потому что для сравнительных факторов нужна база для сравнения, иначе рассуждения ни о чем.
G>>Для большинства проектов проценты прироста быстродействия
EP>Причём тут "проценты"? EP>Выше как раз показано что при использовании Java-style это не проценты, а разы, и даже порядки.
А при использовании C# не разы. Кроме того операции с complex не такой уж частый случай. Я вот сомневаюсь что в том же ФБ много кода, работающего с вещественными числами.
G>>останутся незамеченными и дешевле будет сделать апгрейд железа, чем заниматься оптимизацией. Поэтому утверждение что "на C++ быстрый код получить на порядки проще" не имеет никакого смысла и верно только в контексте фейсбука\гугла и еще пары-тройки гигантов.
EP>Ты почему-то говоришь в контексте каких-то отдельных областей типа web'а — причём так, что как-будто ничего другого нет. Уж поверь "быстрый код на C++" нужен не только гигантам.
Не видел ни одного случая, чтобы без C++ нельзя было добиться достаточного быстродействия. Но это вовсе не отменяет факта, что в том же ФБ переписывание на С++ и оптимизация очень даже оправданы.
EP>Тебе попадаются задачи где не нужен? Поздравляю, вот только не надо необоснованно экстраполировать свой опыт на всю индустрию.
Как раз ты пытаешься опыт ФБ экстраполировать на всю индустрию. Увы никто, из тех кто будет читать этот форум, даже близко не подойдет к таким масштабам.
G>>В остальных случаях сложность оптимизации на C++ и C# (и иногда Java) сравнимы, а учитывая в общем более высокую сложность разработки на C++ еще непонятно что будет проще в итоге. EP>Нет, не сравнимы. В C++ я могу сделать много уровней абстракций, которые будут либо бесплатными, либо крайне дешёвыми. В C#, а тем более Java, так не получится. И вот за счёт этого получается проще.
А не делать уровни абстракции не? Или ты считаешь, что это на порядок сложнее?
EP>Мой поинт наоборот противоположный, и я уже устал его повторять: EP>Предел оптимизации везде примерно одинаковый, разница в десятки процентов это не так уж серьёзно. Но на C++ этот предел гораздо проще достичь.
На практике ровно наоборот. В C++ можно вовсе не выделять память под объекты, а в C#\Java без этого никак. В некоторых случаях только один этот факт позволяет из кода на C++ выжать в разы больше быстродействия. Правда затраты на такую оптимизацию очень быстро превышают разумные пределы. Но для ФБ такие оптимизации оправданы, а для других — вовсе нет.
Здравствуйте, gandjustas, Вы писали:
EP>>Тезис в цитате (с которым я полностью согласен) довольно прост — на C++ проще создать быстрый код. Ты же пытаешься передёрнуть в какую-то совершенно другую плоскость G>Плоскость та же самая. Просто ответь на вопрос насколько проще
Намного проще.
G>и насколько нужна скорость с учетом всех факторов,
Где-то нужна, а где-то нет
G>>>Для большинства проектов проценты прироста быстродействия EP>>Причём тут "проценты"? EP>>Выше как раз показано что при использовании Java-style это не проценты, а разы, и даже порядки. G>А при использовании C# не разы.
В разы, бывает и на порядки
G>Кроме того операции с complex не такой уж частый случай. Я вот сомневаюсь что в том же ФБ много кода, работающего с вещественными числами.
Повторюсь в N-ый раз Это бьёт далеко не только по арифметике и подобным вычислениям.
G>>>останутся незамеченными и дешевле будет сделать апгрейд железа, чем заниматься оптимизацией. Поэтому утверждение что "на C++ быстрый код получить на порядки проще" не имеет никакого смысла и верно только в контексте фейсбука\гугла и еще пары-тройки гигантов. EP>>Ты почему-то говоришь в контексте каких-то отдельных областей типа web'а — причём так, что как-будто ничего другого нет. Уж поверь "быстрый код на C++" нужен не только гигантам. G>Не видел ни одного случая, чтобы без C++ нельзя было добиться достаточного быстродействия.
Опять 25. Без C++, на Java и C# можно добиться быстродействия, что не ясно-то? Ты с чем споришь?
EP>>Тебе попадаются задачи где не нужен? Поздравляю, вот только не надо необоснованно экстраполировать свой опыт на всю индустрию. G>Как раз ты пытаешься опыт ФБ экстраполировать на всю индустрию.
Где я это пытаюсь делать?
G>Увы никто, из тех кто будет читать этот форум, даже близко не подойдет к таким масштабам.
Да причём тут вообще масштабы? Есть много программ которые работают на устройствах конечных пользователей и где нужна скорость.
Ты же пытаешься всё свести к каким-то случаям типа веб-масштабирования. Не хватает только коронного "всё в базу упирается".
G>>>В остальных случаях сложность оптимизации на C++ и C# (и иногда Java) сравнимы, а учитывая в общем более высокую сложность разработки на C++ еще непонятно что будет проще в итоге. EP>>Нет, не сравнимы. В C++ я могу сделать много уровней абстракций, которые будут либо бесплатными, либо крайне дешёвыми. В C#, а тем более Java, так не получится. И вот за счёт этого получается проще. G>А не делать уровни абстракции не? Или ты считаешь, что это на порядок сложнее?
Да, это на порядок сложнее. Например примеры из этого топика:
Вместо того чтобы просто объявить класс Complex — будешь вручную нарезать массив double.
Вместо того чтобы взять готовую ФВП transform, и передать в неё лямбду — будешь выписывать ручной for-цикл.
И чем больше уровней, тем больше ad-hoc boilerplate, причём комбинаторно.
EP>>Мой поинт наоборот противоположный, и я уже устал его повторять: EP>>Предел оптимизации везде примерно одинаковый, разница в десятки процентов это не так уж серьёзно. Но на C++ этот предел гораздо проще достичь. G>На практике ровно наоборот.
Почему это? Вот в этом топике и Java и C# показали скорость близкую к C++.
G>В C++ можно вовсе не выделять память под объекты, а в C#\Java без этого никак. В некоторых случаях только один этот факт позволяет из кода на C++ выжать в разы больше быстродействия. Правда затраты на такую оптимизацию очень быстро превышают разумные пределы.
Ты как раз подтверждаешь мои слова выше. Ты читал на что отвечаешь?
EP>>Предел оптимизации везде примерно одинаковый, разница в десятки процентов это не так уж серьёзно. Но на C++ этот предел гораздо проще достичь.
G>На практике ровно наоборот.
Здравствуйте, Sinix, Вы писали:
S>У меня соотношение 58ms/116ms в пользу x86.
S>UPD2. Тот же код с классами вместо структур: S>
S>.NET Elapsed: 4723,0000 ms
S>
Здравствуйте, mik1, Вы писали:
M>Ты уверен, что в шарпе ты с бубном танцевал меньше, чем я в Яве? M>Кстати, в Яве объекты дают только 3.5х просадку (~185мс против 58 мс) в отличии от полного ужоса шарпа (~4700 мс против 110 мс).
C++ версия
Несмотря на volatile, компилятор выкинул accumulate. Его можно принудительно добавить (через вывод в результата в cout), но на замер времени это не повлияло.
P.S. Думаю на базе Emscripten можно сделать компилятор из C++ в Java — тогда там наконец "появятся" автоматические структуры UPD: у компилятора есть опция выводить не "сжатый" код: