LINUX.ORG.RU

C++ std::vector быстрее QVector?

 , , , ,


0

4

имеется реализация одного кода с применением std::vector и QVector

по значению

time ./program
реализация с std::vector выполняется на 30% быстрее реализации с QVector (например 6сек и 9 сек соответственно).

это действительно так, либо к QVector необходимо как-то по особому обращаться?

и еще, у QVector отсутствует доступ к изменяемому элементу с контролем выхода за пределы массива, как в std::vector метод at()?
в QVector он является константным.

хотел писать прогу на QT, однако, думаю, если я все верно делал с QVector, то придется некоторые компоненты брать из STL.

★★

Код покажи хоть. Ну и можешь попрофилировать, чтобы понять, где QVector медленнее работает и почему.

zamazan4ik ★★ ()
Ответ на: комментарий от zamazan4ik

ссылки жеж на проект привел...
разница в двух ветках только в используемых динамических массивов

прошу прощения, забыл залить на гитхаб qt5 ветку, залил

safocl ★★ ()
Последнее исправление: safocl (всего исправлений: 2)

это действительно так, либо к QVector необходимо как-то по особому обращаться?

В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию

у QVector отсутствует доступ к изменяемому элементу с контролем выхода за пределы массива, как в std::vector метод at()?

Да, но в дебажной сборке выход за пределы массива контролируется ассертом

придется некоторые компоненты брать из STL

как будто есть что-то плохое в использовании стандартной библиотеки ЯП, на котором программируешь

annulen ★★★★★ ()
Ответ на: комментарий от annulen

как будто есть что-то плохое в использовании стандартной библиотеки ЯП, на котором программируешь

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

Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию

да, но данное действие происходит, лишь при передаче массива в разные потоки. Как реализовать данное действие без копирования я даже хз. Ведь, если передавать по ссылке, то несколько потоков будут изменять один и тот же объект, чего не должно быть по логике программы. Если передавать, как rvalue через move(), то исходник при первом вызове thread() уничтожится и остальным потокам не достанется.

safocl ★★ ()
Последнее исправление: safocl (всего исправлений: 1)

В QVector есть поддержка copy-on-write, поэтому при любом вызове неконстантного метода производится проверка, нужно ли чначала скопировать данные. Кроме того, беглый взгляд на дифф между ветками показывает, что QVector кое-где передает по значению, это значит что эти проверки могут привести и к реальному копированию

Вот такая причина может быть как выше написали, а я еще хочу добавить что:

stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом, не смотрел реализацию qt контейнеров, но возможно там много что завязано на их QVariant, что само по себе может отнимать такты процессора, но зато конечно предоставлять классную гибкость и удобства.

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

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

К сожалению сейчас не могу найти ссылку с описанием этого и там еще хорошая таблица сравнения скорости работы была, кроме этой ссылки (https://www.reddit.com/r/cpp/comments/692qhk/stditerators_vs_raw_pointers_per...) - но в этой ссылке не совсем то, но тоже про этот эффект.

Но правда конечно к чему таки оптимизации, ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе (если вдруг будут использовать нестандартный аллокатор, то так вполне может быть) - так что это скорее на поиграться возможность ускорить, а в реальный проектах не стоит так делать.

bonta ★★★★ ()
Последнее исправление: bonta (всего исправлений: 2)
PokerCalc-qt5$ time LD_LIBRARY_PATH=./src ./PokerCalc 
hi : 0
pairs : 3005328
sets : 726528
two pairs : 1577664
straits : 12192
flashes : 23760
fullhouses : 154368
straitflashes : 0
kares : 27360
sum_cycle : 5527200

real    0m5,375s
user    0m18,900s
sys     0m0,012s

PokerCalc-master$ time LD_LIBRARY_PATH=./src ./PokerCalc 
hi : 0
pairs : 84480
sets : 12960
two pairs : 19008
straits : 0
flashes : 0
fullhouses : 1152
straitflashes : 0
kares : 0
sum_cycle : 117600

real    0m0,077s
user    0m0,236s
sys     0m0,000s



Вывод и должен различаться или программы делают разную работу ?

x905 ★★★★★ ()

У меня обычно дикая мешанина stl и qt в проекте выходит. Потому что хоть убейся, но qt контейнеры не полностью умеют move semantics. С другой стороны вызывать кутешное АПИ приходится, да и есть немного функционала в qt непокрываемого stl, например QCache.

q0tw4 ★★★★ ()
Ответ на: комментарий от bonta

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

Не мешало бы подтвердить свои слова о разности в скорости итерации через итераторы и указатели в release-режиме актуальными замерами. А не отсылками к тому что где-то когда-то кто-то о чем-то говорил.

ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе

Правда? Речь все еще об std::vector?

если вдруг будут использовать нестандартный аллокатор, то так вполне может быть)

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

eao197 ★★★★★ ()
Ответ на: комментарий от safocl

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

Сами Qt'шники стараются отказаться от многих своих велосипедов и рекомендуют использовать STL, а ты наоборот.

m0rph ★★★★★ ()
Ответ на: комментарий от eao197

eao197, прошу прощения, что не в тему. Если не трудно, подскажите современные книги и прочие материалы по идиоматическому применению C++11 и новее. Спасибо.

anonymous ()
Ответ на: комментарий от anonymous

Rust - самое идиоматическое применение C++11

q0tw4 ★★★★ ()
Ответ на: комментарий от anonymous

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

Но, если говорить про книги, то, вероятно, классический набор отсюда: https://github.com/rigtorp/awesome-modern-cpp (раздел Books).

eao197 ★★★★★ ()
Ответ на: комментарий от m0rph

я qt еще не пробовал, по ентому интересно, да и вроде много кто грит, что проги на qt отличаются большой стабильностью

safocl ★★ ()
Ответ на: комментарий от safocl

qt не пробовал - С++ десктоп не писал. Это я к тому, что хороший qt или нет, но если надо гуй на плюсах, альтернатив тупо нет (gtk тот же qt, только менее документированный)

q0tw4 ★★★★ ()
Ответ на: комментарий от q0tw4

ясно, значит буду мешать qt с STL...
меня и в STL вроде все устраивает пока. Единственно, гуй все равно надо будет делать, а тут именно qt хочу, по ентому и начал изучать енту либу

safocl ★★ ()
Ответ на: комментарий от safocl

проекты не совсем одинаковые, в qt версии создается библиотека
я пересоздал заново qt проект, получилось чуть быстрее

real    0m4,113s
user    0m14,545s
sys     0m0,020s

x905 ★★★★★ ()
Ответ на: комментарий от bonta

stl контейнеры достаточно примитивны, а qt-шные, вероятно более богаты ф-лом

да ладно, в stl-контейнерах есть куча фич, которых нет в кутешных, в частности из свежих стандартов

annulen ★★★★★ ()
Ответ на: комментарий от bonta

Но правда конечно к чему таки оптимизации, ведь в общем на уровне интерфейса так сказать никто не гарантирует что даже в векторе следующий за этим элемент будет на следующем адресе

Стандарт гарантирует

annulen ★★★★★ ()
Ответ на: комментарий от anonymous

Скотт Мейерс «Эффективный и современный c++»

annulen ★★★★★ ()
Ответ на: комментарий от safocl

много кто грит, что проги на qt отличаются большой стабильностью

Лол. Стабильность проги в основном зависит от прямоты рук того, кто ее делает

annulen ★★★★★ ()
Ответ на: комментарий от annulen

да я чето не проснувшись видимо писал, действительно гарантирует.

bonta ★★★★ ()
Ответ на: комментарий от q0tw4

Потому что хоть убейся, но qt контейнеры не полностью умеют move semantics

В какой версии? Можно примеры?

UVV ★★★★★ ()
Ответ на: комментарий от annulen

да ладно, в stl-контейнерах есть куча фич, которых нет в кутешных, в частности из свежих стандартов

Пробежался по векторам, не нашёл кучи.

/me не защащиет stl или Qt вектор, просто интересно, что за куча..

UVV ★★★★★ ()
Ответ на: комментарий от UVV

Во всех контенейнерах: нет emplace; нет поддержки кастомных аллокаторов (да, API STL-ных аллокаторов много критикуют, но тут вообще ничего); нет конструкторов из пары произвольных итераторов

В ассоциативных контейнерах: нет поддержки кастомизации компараторов и хэш-функций для конкретного контейнера; нет insert с итератором

Может еще что-то забыл. Во времена Qt 4 все было еще хуже, не было даже реверсных итераторов

annulen ★★★★★ ()
Ответ на: комментарий от annulen

Еще по foreach по хешу пробегает значения, а не пары. В принципе оно удобнее, но а вдруг ключ тоже нужен. Не все как я дублируют ключи в самом объекте.

q0tw4 ★★★★ ()
Ответ на: комментарий от UVV

Потому что хоть убейся, но qt контейнеры не полностью умеют move semantics

В какой версии? Можно примеры?

Так не работает: QVector<std::unique_ptr<int>>

QVector и другие контейнеры в Qt работают только с копируемыми типами, потому что при copy-on-write контейнер обязан уметь склонировать элементы.

Dendy ★★★★★ ()

и еще, у QVector отсутствует доступ к изменяемому элементу с контролем выхода за пределы массива, как в std::vector метод at()?

.value(index, default_vaue)

next_time ★★★★★ ()
Ответ на: комментарий от q0tw4

В принципе оно удобнее, но а вдруг ключ тоже нужен

Удобнее бывает не всегда, а в контексте range-for (foreach уже не актуален) такой финт удивляет неподготовленных людей

annulen ★★★★★ ()
Ответ на: комментарий от x905

а в мастер ветке, не создается либа?
qt5 ветка была выделена из мастер и потом переведена на QVector без изменений в остальном коде.

safocl ★★ ()
Последнее исправление: safocl (всего исправлений: 1)
Ответ на: комментарий от annulen

вухаахахаха, я грю чо прочел про qt5... люди так пишут, я ж им чо

safocl ★★ ()
Ответ на: комментарий от safocl

а в мастер ветке, не создается либа?

нет, не создается

x905 ★★★★★ ()
Ответ на: комментарий от safocl

значит буду мешать qt с STL

Вон я только что написал std::map<TileIndex, QHash<QString, std::shared_ptr<Tile>>> и доволен. Правда не все комбинации рабочие, но тут компилятор об этом вовремя сообщит.

q0tw4 ★★★★ ()
Последнее исправление: q0tw4 (всего исправлений: 1)
Ответ на: комментарий от q0tw4

О, вот это уже интересно. Спасибо за ссылку. А на каком оно енжине и умеет ли flexbox и css grid?

Там свой движок оптимизированный под десктоп и с аппаратно ускоренной графикой. Автор заседает в комитете W3C. В css там много специфичных для десктопа фишек https://sciter.com/docs/content/css/cssmap.html https://www.terrainformatica.com/w3/flex-layout/flex-layout.htm https://sciter.com/docs/flex-flow/flex-layout.htm Тут сравнение с браузером https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm

anonymous ()
Ответ на: комментарий от anonymous

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

q0tw4 ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.