В векторе он не быстрее, а может даже наоборот. Обращение по индексу - прямой доступ к данным без прослойки в виде итератора.

djamshud, обращение по индексу - это *(base+index) а обращение через итератор это *iterator.
feel the difference

GoldFinch, 









feel the difference 

djamshud, и что? я не юзаю гцц, я хз что это за время, и плохая оптимизация гцц - проблемы гцц

если ты хотел этим доказать что гцц - плохой компилятор, тебе это удалось, поздравляю

Это сообщение отредактировал(а) GoldFinch - 19.12.2009, 00:34

GoldFinch, а при чем тут оптимизация? Мы же говорим об идее итератор Vs индекс, а не о том, как ее извратит оптимизатор. Именно поэтому оптимизация была совсем выключена.

Про цифры поясню. Процессор работает в двух режимах (реально может в большем количестве) - режиме пользователя (обычный режим, числодробления и пр) и режиме ядра (это системные вызовы, обращение к железу). Программа с итератором выполнялась 4.388 секунды в режиме пользователя и 0.040 - в режиме ядра. Всего она "прожила" 4.514 секунд (процессор был занят не толькой ей, поэтому sys+usr!=real). Программа с индексом работала почти в четыре(!) раза меньше, т.е. быстрее.

djamshud, жги еще

Добавлено через 2 минуты и 48 секунд
хоть и говорили недавно, что без профайлера нельзя ничего сказать о быстродействии кода,
но всетаки программисту надо самому понимать что он делает и во что компилится его код, иначе это будет называться 100%-м быдлокодингом.

>хоть и говорили недавно, что без профайлера нельзя ничего сказать о быстродействии кода,
но всетаки программисту надо самому понимать что он делает и во что компилится его код, иначе это будет называться 100%-м быдлокодингом.

И это говорит человек, уповающий на оптимизацию компилятора? Ууух, жгунишка!

Добавлено через 2 минуты и 9 секунд
>без профайлера нельзя ничего сказать о быстродействии кода

Т.е. на самом деле четырехкратный слив как бэ намекает нам, что программа просто разминается перед тем, как попасть в профайлер? Там то она точно даст жару!

Добавлено через 10 минут и 14 секунд
>если ты хотел этим доказать что гцц - плохой компилятор, тебе это удалось, поздравляю

Посмеялся. Блажен неведающий.

Для Zhekin,
Опред. "итерация"
И я с этим согласен.

По твоим примерам, небольшая, однако итераторы, как мне думается, следует применять в конструкциях вроде стандартных алгоритмов или при необходимости задания некоторого порядка следования элементов при итерации (некий "интеллектуальный" вариант). В остальных случаях дело за автором кода.

ЗЫ
Сильно ИМХО: В остальных случаях предпочитаю классический вид обхода элементов массива. Думается он как-то нагляднее показывает работу кода, чем все эти .begin(), .end(), "..элемент, следующий за последним..." и остальное, т.е., иными словами, как-то проще читать код.

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

Добавлено @ 06:16

  

Это сообщение отредактировал(а) andrew_121 - 19.12.2009, 06:16

Я последнее время предпочитаю такой способ 



Удобно.

Добавлено через 6 минут и 28 секунд

Вероятнее всего, после оптимизации, разницы в скорости доступа не будет вообще. Ни там ни там нет проверок на выход за границы массива. Почти любой современный компилятор способен на это.

Есть ещё std::vector<Type>::at

Леопольд, да оптимизация практически сравнивает показатели.

И медленно. 

Тогда уж так:





Тоже штука тормозная. Хотя и безопасная.  

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

Lazin, не передергивайте. Во-первых, отладочная версия и без оптимизации - совершенно разные вещи. Во-вторых изначально я и написал, что индексы выиграют если и выиграют, то чуть-чуть, а про "слив" - это ответ на совсем другое заявление одного товарища. Stl-итератор запрятывает реальную работу с указателем за слои абстракций, поэтому работа через него однозначно медленнее, это все, что я хотел сказать. Оптимизация вытаскивают его из лужи, но речь то шла не про нее.

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

У stl-списка нет интерфейса доступа к объектам через индекс? Бугагашеньки:).

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

ты в курсе что такое список?)

>ты в курсе что такое список?)

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

ЗЫ. Прежде чем язвить, ознакомся с матчастью или погляди в сторону других библиотек (хинт: Qt). Сначала про gcc глупость ляпнул, теперь про список... Хоть бы учился на собственных ошибках, что ли.

djamshud, у STL есть политика - не давать ту функциональность, которую не заказывали. Т.е. если списку добавить индексированный доступ, то он будет очень медленно работать (линейная скорость), или класс будет потреблять больше ресурсов. В первом случае, это будет подталкивать писать неэффективный код. Во втором случае вообще бред. Мне нужен список, зачем мне дополнительная функциональность? Зачем я должен за нее платить ради пары процентов новичков, которые без нее никак не могут?

В случае с вектором полностью присоединяюсь к Lazin по части скорости доступа. Те, кто  говорит о понижении скорости при обращении через итератор, тот не до конца уяснил что такое шаблоны и их код после оптимизации. Как ни крути , а без оптимизации не обойтись и сравнивать скорости работы этих двух механизмов, тем более без оптимизации - дело не  благородное. Разница в скорости без оптимизации не умоляет универсальности использования итераторов. Просто два механизма существуют для несколько разных целей, а их скорость с оптимизацией лишь говорит свое "слово" за использование итераторов. Другое дело личная приверженность в написании кода к классическому механизму обращения.

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

А при непоследовательном обращении к элементам механизм с индексов еще и упрощает код. Таким образом профит во все поля. ЧТД.

Ваше заявление о "новичках" безосновательно: программисту нужны уникальные _свойства_ контейнера, а не способ их извлечения. Итератор есть, но должен был быть и индекс.

ЗЫ. Сам итераторы использую лишь при сложной логике проходе по контейнеру, то есть когда производить расчет индексов - очевидный идиотизм.

djamshud, такая бы уверенность хороша когда она подкреплена знаниями, но это не про тебя

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

Мальчик, иди в школу. Найдешь, что сказать, возвращайся.

djamshud, не, завтра воскресенье - не пойду

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

Это сообщение отредактировал(а) GoldFinch - 19.12.2009, 23:08

GoldFinch, ну тогда домашнее задание как следует подготовь:).

ЗЫ. Не нужно, а можно. А можно всегда, кроме тех случаев, когда ты пользуешься STLевской или еще какой-нибудь обрезанной реализацией списка.

djamshud, так тебе же писали, что сложность [] у любого списка O(n), поэтому его "всегда" использовать нельзя, только в особых случаях, и вот я хз в каких

Это сообщение отредактировал(а) GoldFinch - 19.12.2009, 23:53

GoldFinch, перечитай сообщение, содержащее запредельное количество "уверенности, не подкрепленной знаниями". Перечитывай до просветления.

djamshud, может ты еще и доказать можешь, что

?

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

Цитата(djamshud @  19.12.2009,  23:00 )

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

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

Добавлено @ 00:16

это называется (преждевременной, необдуманной) пессимизацией.

Это сообщение отредактировал(а) mes - 20.12.2009, 00:17

Угу, точно, лучше по ссылке 


Предлагаю реализовать поиск делением пополам в отсортированном списке и в векторе с доступом по индексу. 
Так же можно сделать быструю сортировку, по примеру qsort.

!  bsa

djamshud, прекращай уже троллинг. Ты пытаешься вести себя как профессионал, хотя иногда такое сморозишь!

Для программы:Получается код:Тогда как для:Создается код:
Вывод, второй код работает не медленнее первого, более того, скорее всего, даже быстрее, так как вычислительных операций процессором производится гораздо меньше: movl    $10, (%rsi) и movl    $10, (%rax,%rdx) немного отличаются, так как для выполнения второй необходимо сначала сложить регистры rax и rdx

Это сообщение отредактировал(а) bsa - 20.12.2009, 01:23

>djamshud, может ты еще и доказать можешь

Я это делал собственноручно. Пока что не покажу, мучайся, думай. Попробуй таки напрячь мозг или чем ты обычно это делаешь.

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

"Можно" всю жизнь означало "если хочется". Еще одно значение - позволение, но я, очевидно, никому разрешений на что-либо не выдаю.

>тон, честно говоря, оставляет желать лучшего..тем более что отсыл идет в "пустоту"

Ищущий всегда найдет. Посмотрите сообщение товарища перед вами.

bsa, я не троллю). И вообще они меня обижают, дайте им ремня! :D.

bsa, если компилятор способен в итоге так компактно развложить итератор, то это просто здорово. На примере, что я делал в начале топика, с простым -O3, итератор чуток отставал на 0.05 - 0.01 секунды, но асм не смотрел, ибо ни бум бум.

ЗЫ! А почему тему в холиворы пренесли? Черт, вот так вот стоит высказать свой маленький емнипчик и тут же топик скатывается в... Ну понятно в общем.:)

Добавлено @ 01:50
Блин, я отчаянно защищаюсь, а мне еще и предупреждения вкатывают. Ну вас, злые вы.

Это сообщение отредактировал(а) djamshud - 20.12.2009, 01:50

"можно" всегда (в програмировании) означало "хуже не будет", а за "хочется" полагаю (хоть собственного опыта и нет) начальник бы показал бы где некие членистоногие зимуют,
расставив точки над i в этой теме ))


Это сообщение отредактировал(а) mes - 20.12.2009, 02:37

bsa, ох уж этот страшный AT&T синтаксис %)

Добавлено через 5 минут и 35 секунд

то как ты меряешь время - это ты меряешь что угодно, но не производительность алгоритмов
для нормальных измерений надо мерять такты, хотябы используя просто rdtsc (__rdtsc() в msvc и тоже какой-то интринсик в гцц)
при этом у процесса должен быть максимальный приоритет

GoldFinch, я меряю при равных условиях - на бездействующей системе. Когда что-то идет нос к носу, проводится серия опытов. И заметь, показатели user и sys достойны доверия, т.к. показывают, сколько программа пробыла прямо в процессоре.

Да, это не лабораторные условия, ну так и я не лаборант. Использумый мной метод просто показывает, что программа А работает быстрее программы Б примерно в столько раз. Надеюсь, ты не станешь утверждать, что "реальные" тактовые измерения будут давать результат в точности до наоборот?

mes, "хуже не будет" по смыслу тоже подходит.

что то я сомневаюсь что ты представляешь как работает ОС и железо


может еще и не программист?


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

>что то я сомневаюсь что ты представляешь как работает ОС и железо

Что-то я сомневаюсь, что ты хотя бы думаешь, прежде чм писать. Ну что ж, давай, гуру, изложи тезисно семитомный труд "как работает ОС и железо", я посмеюсь.

>может еще и не программист?

Ты так говоришь "программист", как будто это что-то особенное. Самомнение на высоте! Неподкрепленное знаниями(с), ага?

>если и показывает - то неточно, и точно не показывает разницу между двумя способами итерации

Да, оно показывает, что  Виллариба собрала урожай и гуляет, а Виллабаджа все ждет профайлер, чтобы потом ВНЕЗАПНО начать быстрее работать.

У нас появился толстый тролль   

я забыл, в этом разделе счетчик постов идет?