Что быстрее: i++ или ++i ?

@programina · Регистрация: 23.10.2011

Только что прочитала в интернете, что префиксный итератор быстрее, чем постфиксный. Так ли это? Если так и если в С++ все есть обьект, то относится ли это к не итераторам в том числе?

@SmittWesson · 11.11.2014, 11:21

Префиксный выполняется быстрее. Не знаю почему, но это так.

@programina · 11.11.2014, 11:27 **[ТС]**

SmittWesson, я тоже не знаю, но пишут, что не происходит вызов конструктора.

Ilot · 11.11.2014, 11:28

programina, как бы истина вполне известная. Постфиксный инкремент итератора возвращает предыдущее свое значение для чего используется временная переменная. Для префиксной формы этого не требуется. Собственно данный факт относится ко всем типам в С++ поддерживаеммым инкремент или декремент. Как пример для реверсных итераторов:

C++

    
  reverse_iterator&
      operator++()
      {
    --current;
    return *this;
      }
 
      reverse_iterator
      operator++(int)
      {
    reverse_iterator __tmp = *this;
    --current;
    return __tmp;
      }

@aLarman · 11.11.2014, 11:28

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

@programina · 11.11.2014, 11:38 **[ТС]**

А как с простыми типами типа int, float и др.?

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

C++

1	int i = 0;

C++

1	for(;; ++i); значит быстрее, чем for(;; i++);

?

@aLarman · 11.11.2014, 11:38

programina, так же, т.е постфиксная во временную переменную сохраняет текущее значение, и оно возвращается по значению, префиксная изменяет переменную и возвращает константную ссылку

@Max Dark · 11.11.2014, 11:39

C++

int pre(int* i) {
    if(++(*i) == 0) return 0;
    return *i;
}
int pos(int* i) {
    if((*i)++ == 0) return 0;
    return *i;
}

Bash

1	gcc -S -O3 pre_vs_pos.c

Assembler

    .file   "pre_vs_pos.c"
    .text
; префикс
    .p2align 4,,15
    .globl  pre
    .def    pre;    .scl    2;  .type   32; .endef
    .seh_proc   pre
pre:
    .seh_endprologue
    movl    (%rcx), %eax
    addl    $1, %eax
    movl    %eax, (%rcx)
    ret
    .seh_endproc
; посфикс
    .p2align 4,,15
    .globl  pos
    .def    pos;    .scl    2;  .type   32; .endef
    .seh_proc   pos
pos:
    .seh_endprologue
    movl    (%rcx), %edx
    leal    1(%rdx), %eax
    testl   %edx, %edx
    movl    $0, %edx
    movl    %eax, (%rcx)
    cmove   %edx, %eax
    ret
    .seh_endproc
    .ident  "GCC: (rev5, Built by MinGW-W64 project) 4.8.1"

Как видим, ++i чуточку короче на ассемблере чем i++

@mporro · 11.11.2014, 11:39

programina. Зависит от компилятора и конкретного кода. Но в подавляющем большинстве случаев операции будут выполняться одинаково быстро.

@aLarman · 11.11.2014, 11:40

Сообщение от Cra3y

Как видим, ++i чуточку короче на ассемблере чем i++

учитывая соверменные скорости это не повляет

IGPIGP · 11.11.2014, 11:43

Сообщение от aLarman

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

Я тоже так думаю. Для итерации ведь используются простые вещи, - целые либо итераторы/указатели. Но если угораздит перегрузить инкремент-декремент для какого-то объёмистого типа, то разница может быть видна, наверное. Кроме всего, учитывая, что и при целом типе переменная может стать регистровой, а может и не стать, разница может проявиться. С другой стороны, "умный" компилятор может и не создать временную, если она не нужна (скорее мечты наверное))? Как это зависит от архитектуры и компилятора и зависит ли не скажу. Не знаю.

@aLarman · 11.11.2014, 11:45

Не по теме:

Сообщение от IGPIGP

переменная может стать регистровой, а может и не стать

да уж навернякак станет регистровой :)

@programina · 11.11.2014, 11:55 **[ТС]**

aLarman,

учитывая соверменные скорости это не повляет

Обьемы современные тоже надо учитывать, мало ли что, а если нужно сделать 10 000 000 операций

Добавлено через 54 секунды
Спасибо за ответы!

@SatanaXIII · 11.11.2014, 12:04

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

IGPIGP · 11.11.2014, 12:55

Не по теме:

Сообщение от aLarman

да уж наверняка станет регистровой

Это в том смысле, что если 64 разрядный регистр содержит 32 разрядное без знака, то он на половину полон? И тут согласен. :)

Сообщение от SatanaXIII

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

А это не про это:

Сообщение от IGPIGP

Но если угораздит перегрузить инкремент-декремент для какого-то объёмистого типа

?

@MickeyBlueEyes · 11.11.2014, 13:13

Сообщение от Cra3y

addl $1, %eax

Компилятор розошолся.

MrGluck · 11.11.2014, 14:25

На самом деле, в теории префиксная запись быстрее т.к. возвращает ссылку, а не объект (не создаётся временная локальная копия), но всем современным компиляторам уже всё равно, они всё это дело оптимизируют, тем более для POD типов.
Для итераторов уже не всё так просто:
http://www.viva64.com/ru/b/0093/
http://silviuardelean.ro/2011/... -operator/
однако чаще всего, в релизе всё равно всё приводится к префиксной записи.

@MickeyBlueEyes Студент 121 / 132 / 39 Регистрация: 07.04.2011 Сообщений: 503
	11.11.2014, 13:13	16
	Сообщение от Cra3y addl $1, %eax Компилятор розошолся. 0

MrGluck Форумчанин 8164 / 5012 / 1436 Регистрация: 29.11.2010 Сообщений: 13,455
	11.11.2014, 14:25	17
	На самом деле, в теории префиксная запись быстрее т.к. возвращает ссылку, а не объект (не создаётся временная локальная копия), но всем современным компиляторам уже всё равно, они всё это дело оптимизируют, тем более для POD типов. Для итераторов уже не всё так просто: http://www.viva64.com/ru/b/0093/ http://silviuardelean.ro/2011/... -operator/ однако чаще всего, в релизе всё равно всё приводится к префиксной записи. 1

@programina 2061 / 617 / 41 Регистрация: 23.10.2011 Сообщений: 4,468 Записей в блоге: 2
		1
	Что быстрее: i++ или ++i ? 11.11.2014, 11:19. Просмотров 7363. Ответов 16 Метки нет (Все метки) Только что прочитала в интернете, что префиксный итератор быстрее, чем постфиксный. Так ли это? Если так и если в С++ все есть обьект, то относится ли это к не итераторам в том числе? 0

@SmittWesson 236 / 194 / 21 Регистрация: 04.06.2014 Сообщений: 1,313
	11.11.2014, 11:21	2
	Префиксный выполняется быстрее. Не знаю почему, но это так. 1

@programina 2061 / 617 / 41 Регистрация: 23.10.2011 Сообщений: 4,468 Записей в блоге: 2
	11.11.2014, 11:27 [ТС]	3
	SmittWesson, я тоже не знаю, но пишут, что не происходит вызов конструктора. 0

@aLarman 653 / 574 / 164 Регистрация: 13.12.2012 Сообщений: 2,124
	11.11.2014, 11:28	5
	programina, по всей логикет префиксный должен быть быстрее, т.к там нет копирования исходного значения, но разница в производительности не ощутимая(даже не миллионе иттераций) 2

@aLarman 653 / 574 / 164 Регистрация: 13.12.2012 Сообщений: 2,124
	11.11.2014, 11:38	7
	programina, так же, т.е постфиксная во временную переменную сохраняет текущее значение, и оно возвращается по значению, префиксная изменяет переменную и возвращает константную ссылку 1

@mporro 306 / 101 / 18 Регистрация: 04.07.2014 Сообщений: 571
	11.11.2014, 11:39	9
	programina. Зависит от компилятора и конкретного кода. Но в подавляющем большинстве случаев операции будут выполняться одинаково быстро. 2

@aLarman 653 / 574 / 164 Регистрация: 13.12.2012 Сообщений: 2,124
	11.11.2014, 11:40	10
	Сообщение от Cra3y Как видим, ++i чуточку короче на ассемблере чем i++ учитывая соверменные скорости это не повляет 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 8634 / 4347 / 590 Регистрация: 04.12.2011 Сообщений: 13,010 Записей в блоге: 16
	11.11.2014, 11:43	11
	Сообщение от aLarman по всей логикет префиксный должен быть быстрее, т.к там нет копирования исходного значения, но разница в производительности не ощутимая Я тоже так думаю. Для итерации ведь используются простые вещи, - целые либо итераторы/указатели. Но если угораздит перегрузить инкремент-декремент для какого-то объёмистого типа, то разница может быть видна, наверное. Кроме всего, учитывая, что и при целом типе переменная может стать регистровой, а может и не стать, разница может проявиться. С другой стороны, "умный" компилятор может и не создать временную, если она не нужна (скорее мечты наверное))? Как это зависит от архитектуры и компилятора и зависит ли не скажу. Не знаю. 1

@aLarman
	11.11.2014, 11:45 #12
	Не по теме: Сообщение от IGPIGP переменная может стать регистровой, а может и не стать да уж навернякак станет регистровой :) 0

@programina 2061 / 617 / 41 Регистрация: 23.10.2011 Сообщений: 4,468 Записей в блоге: 2
	11.11.2014, 11:55 [ТС]	13
	aLarman, учитывая соверменные скорости это не повляет Обьемы современные тоже надо учитывать, мало ли что, а если нужно сделать 10 000 000 операций Добавлено через 54 секунды Спасибо за ответы! 1

@SatanaXIII Почетный модератор 5842 / 2851 / 390 Регистрация: 01.11.2011 Сообщений: 6,903
	11.11.2014, 12:04	14
	Ну я удивляюсь, что никто не вспомнил про самый глубоководный камень инкремента именно пользовательского типа. Когда уже компилятор ничего не оптимизирует и бла-бла-бла. 1

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 8634 / 4347 / 590 Регистрация: 04.12.2011 Сообщений: 13,010 Записей в блоге: 16
	11.11.2014, 12:55	15
	Не по теме: Сообщение от aLarman да уж наверняка станет регистровой Это в том смысле, что если 64 разрядный регистр содержит 32 разрядное без знака, то он на половину полон? И тут согласен. :) Сообщение от SatanaXIII Ну я удивляюсь, что никто не вспомнил про самый глубоководный камень инкремента именно пользовательского типа. А это не про это: Сообщение от IGPIGP Но если угораздит перегрузить инкремент-декремент для какого-то объёмистого типа ? 1