Здравствуйте, MTD, Вы писали:
MTD>>>У тебя выключена Whole program optimization (/GL). Что любопытно, если ее выключить std::vector работает быстрее чуть ли не вдвое (к вопросу об stl в time critical ), поведение велосипеда не меняется. Впрочем отрыв велосипеда все равно есть, процентов 15. N>>Цифры против, я их привёл.
MTD>Это неправда. Я проверил на той же оси, компиляторе и настройках, только процессор i5, а не i7.
Пойми простую вещь: цифры важнее твоих хотелок и комплексов. Вот они показывают, что ты облажался. Это факт. Твоё упорство — делает хуже тебе, а не им.
N>>Я уже говорил, что в подобных оптимизациях, по мимо их адской прямой и отложенной дороговизны — очень сильно влияние оползней на Луне.
MTD>Это потому, что ты процессов не понимаешь, поэтому для тебя это магия.
Да-да, тебе цифры показывают, что твой косой тест показывает рандомные результаты, но для меня это магия, ага.
N>>Ты ляпнул провокационное заявление, противоречащее архитектуре проца и всем основным бенчмаркам, тестам и практике. Никак его не обосновал -> гонишь.
MTD>Я тебе предложил подтвердить свои слова, а заодно подучить тебя, но разумеется не бесплатно — ты моментально слился.
Здравствуйте, MTD, Вы писали:
N>>Оо, да. Давай, докажи, что не болтун, покажи 10х прирост Впрочем ты просто зарвался и начал тупо гнать. MTD>Пока, что болтуном показал себя ты. Насчет на порядок я написал для красоты, но 8х — вполне. С тобой могу заключить пари, тысяч на 50 рублей, например. После этого покажу код с SSE делающий код без SSE на озвученную мной величину.
В 8х тоже не получится, потому как хотя сами операции будут выполняться реально в 8 раз быстрее, но подготовка процессора к ним будет существенно дольше, чем у не SIMD варианта. Так что реально говорить об ускорение в 6-7 раз максимум.
Здравствуйте, Nikе, Вы писали:
MTD>>Пока, что болтуном показал себя ты. Насчет на порядок я написал для красоты, но 8х — вполне. С тобой могу заключить пари, тысяч на 50 рублей, например. После этого покажу код с SSE делающий код без SSE на озвученную мной величину. N>Я на этот бред не подписываюсь. Ставлю на то, что ты либо невнимательно прочёл о чём идёт речь и думаешь о старших версиях SSE, которые служат для других задач, либо имеешь в виду какой-нибудь экзотичный изврат — хотя думаю, что верно первое.
Ну это ты уже что-то не то пишешь. AVX — это самый обычный SIMD, применяющийся ровно для тех же целей, что и самый первый древний MMX.
Здравствуйте, alex_public, Вы писали:
_>В 8х тоже не получится, потому как хотя сами операции будут выполняться реально в 8 раз быстрее, но подготовка процессора к ним будет существенно дольше, чем у не SIMD варианта. Так что реально говорить об ускорение в 6-7 раз максимум.
Да с чего в 8 то? В одном регистре SSE помещается 4 флоата. С чего это операции с ними должны быть в 8 раз быстрее?
Здравствуйте, alex_public, Вы писали:
N>>Я на этот бред не подписываюсь. Ставлю на то, что ты либо невнимательно прочёл о чём идёт речь и думаешь о старших версиях SSE, которые служат для других задач, либо имеешь в виду какой-нибудь экзотичный изврат — хотя думаю, что верно первое.
_>Ну это ты уже что-то не то пишешь. AVX — это самый обычный SIMD, применяющийся ровно для тех же целей, что и самый первый древний MMX.
Так я писал про первую версию расширения SSE. Сейчас-то понятно, что много всякого появилось — сам активно Cuda и OpenCL использую, но речь то шла про конкретный забавный опыт.
Здравствуйте, Nikе, Вы писали:
_>>В 8х тоже не получится, потому как хотя сами операции будут выполняться реально в 8 раз быстрее, но подготовка процессора к ним будет существенно дольше, чем у не SIMD варианта. Так что реально говорить об ускорение в 6-7 раз максимум. N>Да с чего в 8 то? В одном регистре SSE помещается 4 флоата. С чего это операции с ними должны быть в 8 раз быстрее?
Восемь float/int32 там помещается в наше время. А в этом году выходит пользовательский (специализированные уже несколько лет продаются) процессор в котором их будет 16 помещаться. )))
Здравствуйте, alex_public, Вы писали:
_>Восемь float/int32 там помещается в наше время. А в этом году выходит пользовательский (специализированные уже несколько лет продаются) процессор в котором их будет 16 помещаться. )))
Спасибо Кэп! Я специально для MTD акцентировал внимание на том, что это просто SSE (старый).
Здравствуйте, MTD, Вы писали:
MTD>>>использование STL зачастую напрочь убивает перформанс. MTD>Небольшой ликбез: MTD>[ccode] MTD>... MTD>[/code]
Позволю себе подвести краткие итоги по результатам обсуждения представленного ликбеза:
1. на некоторых платформах MTD::Vector немного обгоняет std::vector
2. на некоторых платформах std::vector немного обгоняет MTD::Vector
3. на некоторых платформах std::vector работает с такой же скоростью что и MTD::Vector
4. разница скорости работы этих двух вариантов примерно сопоставима с величиной погрешности замеров
Итого: нужен более качественный ликбез, этот не подходит, он не показывает напрочь убитый перформанс.
MTD>Из личной практики могу рассказать множество историй, как STL тормозит на ровном месте, но как нибудь отдельно. Сам сначала пишу с использованием стандартной библиотеки, в большинстве случаев — это ок, но осторожным надо быть всегда, бывают адские провалы порядка в 20 раз на отдельной платформе.
Здравствуйте, MTD, Вы писали:
MTD>Почему не нужен? А может как раз нужен. Гипотетически — есть код написанный с вектором, алгоритмически все оптимизировали, надо выжать еще процентов 20. Меняем вектор на свой — профит.
Хм, вопрос исправления уже написанной и при этом изначально кривой (не потому что быстродействие, а потому что vector тут банально менее удобен) архитектуры — это отдельный тяжёлый вопрос в программирования. Я его не рассматривал. А так да, теоретически это возможно.
MTD>>>Конечно нет. На маке ничего не изменилось, на вин10 произошли чудеса и разрыв между велосипедом и вектором усилился , на линуксе отставание вектора составило ~15%. _>>Ну а теперь смотри на реальность: MTD>Я уже посмотрел.
Куда-то не туда смотрел.
Ты увидел, что поставленный в одинаковые условия твой код и std::vector выдают одинаковые результаты с точностью до второго порядка после запятой? )
А так же увидел ли, что если всё же ограничиваться условием именно твоей задачи, то наиболее оптимальным решением будет использование "make_unique<T[]>(n)" (то же кстати часть стандартной библиотеки языка) вместо всех этих векторов? )
_>>500028 us //std::vector с clear() _>>415023 us //std::vector с resize(0) MTD>Можешь объяснить разницу? Давай без подколок, реально интересно.
Надо смотреть какой там ассемблер генерируется. Я настолько глубоко в твой примерчик не погружался. )))
Здравствуйте, Nikе, Вы писали:
_>>Ну это ты уже что-то не то пишешь. AVX — это самый обычный SIMD, применяющийся ровно для тех же целей, что и самый первый древний MMX. N>Так я писал про первую версию расширения SSE. Сейчас-то понятно, что много всякого появилось — сам активно Cuda и OpenCL использую, но речь то шла про конкретный забавный опыт.
А, значит я не так понял (MTD же писал про 8 раз — это очевидно AVX имелся в виду). Если говорить про старый SSE, то там и в 3 раза не всегда вытягивалось...
S>>>>vector<int>::iterator it = v.begin();
S>>>>auto it = v.begin();
S>>>>
R>>>Напишите это в реальном коде, где вектор где-то на полстраницы выше итератора. И уже надо смотреть наверх и искать, к чему относится этот итератор. _>>А вот как раз для этих целей программисты на C++ и предпочитают использовать IDE (а не какие-то простенькие редакторы с подсветкой синтаксиса). R>Я предпочитаю использовать IDE, чтобы упростить перемещение по коду, а не для того, чтобы сгладить проблемы с auto.
Так при использование IDE никаких проблем и нет — наводим курсор на нашу переменную (v в данном примере) и прекрасно видим её тип.
R>auto от меня скрывает типы и заставляет держать в памяти то, что можно было видеть глазками. Считайте, что огромный кусок моей памяти занят бессмысленными данными. Т.е. я по сути глупее с auto.
Информация в подсказке IDE не считается "видимой глазками" или как? )
Здравствуйте, Nikе, Вы писали:
N>В STL много до чего можно докопаться — банально их шаредпоинтеры действительно не годятся там, где идёт борьба за ресурсы.
А чьи годятся? И из-за чего не годятся? Из-за того что sizeof shared_ptr<T> > sizeof void*?
, на линуксе отставание вектора составило ~15%.
