Форум программистов, компьютерный форум, киберфорум
Наши страницы
C++
Войти
Регистрация
Восстановить пароль
 
 
karat39
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 137
#1

На что влияет правильный выбор типа данных? - C++

09.06.2016, 11:05. Просмотров 809. Ответов 32
Метки нет (Все метки)

Вопрос банальный. Предлагаю некий мозговой штурм. Сам не очень владею этой темой.

Код работает с целыми числами. Для целых чисел в с++ разработан целый набор типов для конкретных задач. На что может повлиять выбор того или иного типа?
Если я работаю с числами до 1000, то например, можно использовать short int и unsigned short int и int. При этом логично использовать short int в целях экономии памяти. Но не проиграю ли я в производительности? Что очень важно.

Заранее спасибо за аргументированные мысли.
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
09.06.2016, 11:05
Я подобрал для вас темы с готовыми решениями и ответами на вопрос На что влияет правильный выбор типа данных? (C++):

Ошибка что то типа не объявленный идентификатор,и типа невозможно преобразовать CStringW в там что..то
Даже не знаю как сказать... короче есть база а Access,которую я подключил к...

Нужен способ помещения разного рода типа данных в контейнеры типа массивов или структур
Сабж. Нужен способ помещения разного рода типа данных в контейнеры типа...

Как сделать что бы в listbox было типа заголовков, а в ValueListEditor содержание(что то типа бд)
Как сделать что бы в listbox было типа заголовков, а в ValueListEditor...

Выбор верного типа данных
Здравствуйте! У меня такой вопрос, если я хочу использовать в программе...

Правильный выбор типа данных
Помогите ,пожалуйста, выбрать тип данных. Считаем уравнение.:wall: Sub lab()...

Как организовать правильный выбор данных из таблицы?
Здравствуйте господа программисты :-) Имеется сложность с выбором данных из...

32
rao
857 / 412 / 158
Регистрация: 02.04.2014
Сообщений: 1,201
09.06.2016, 19:32 #2
Мне кажется на быстродействие кода размер и тип операндов не влияет потому что процессору без разницы что складывать/вычитать/умножать/делить char'ы (или byte), short'ы или int'ы - количество тактов на операцию будет одинаковое.
0
liv
375 / 342 / 124
Регистрация: 07.10.2015
Сообщений: 1,281
Завершенные тесты: 1
09.06.2016, 19:39 #3
Цитата Сообщение от rao Посмотреть сообщение
количество тактов на операцию будет одинаковое
Не совсем так...
Short-ы преобразуются в int-ы.
Так что, если хотите (совсем чуть-чуть!) выиграть в скорости, то лучше хранить в int-ах.
1
rao
857 / 412 / 158
Регистрация: 02.04.2014
Сообщений: 1,201
09.06.2016, 20:11 #4
_liv_, а с чего это short'ам преобразовываться в int'ы если процессор может спокойно работать не только с целыми регистрами (32 битными: EAX, ECX, EDX и т.д.), но и с их половинками (8 битными AX, BX, и тд.) ?
0
liv
375 / 342 / 124
Регистрация: 07.10.2015
Сообщений: 1,281
Завершенные тесты: 1
09.06.2016, 21:13 #5
rao, разумеется, может. Но, при работе, например, на 32-битной системе, основной единицей является 32-битный int.
При работе с 16-битными регистрами, в код добавляется префикс, который удлиняет и код, и время работы, даже если не будет преобразования в 32-битный int.
Поэтому оптимальнее всего работать именно с 32-битными величинами.
Посмотрите в отладчике ассемблерный код и сами убедитесь...
1
rao
857 / 412 / 158
Регистрация: 02.04.2014
Сообщений: 1,201
09.06.2016, 22:58 #6
Посмотрел, но сомнения остались. Потому что преобразование происходит не всегда. Например строка
C++
1
WORD wordTest = 3;
компилируется в
Assembler
1
2
mov         ecx,3 
mov         word ptr [ebp-0C0h],cx
Т.е. никакого преобразования нет.
А вот сложение двух ячеек памяти происходит с "расширением:"
C++
1
WORD wordSum =  wordTest + wordTest;
выглядит так:
Assembler
1
2
3
4
movzx       eax,word ptr [ebp-0C0h] 
movzx       ecx,word ptr [ebp-0C0h] 
add         eax,ecx 
mov         word ptr [ebp-0CCh],ax
Так себя ведет компилятор Visual Studio 2008 с выключенной оптимизацией. Вполне возможно, что другие компиляторы генерируют другой код. Поэтому однозначно утверждать об оптимальности 32-битных переменных я бы все таки не стал.
2
karat39
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 137
09.06.2016, 23:11  [ТС] #7
Спасибо, хорошее обсуждение получается

Добавлено через 8 минут
Цитата Сообщение от _liv_ Посмотреть сообщение
При работе с 16-битными регистрами, в код добавляется префикс, который удлиняет и код, и время работы
я правильно понял, что удлинение кода ведет к увеличению времени работы?
0
Почтальон
Модератор
584 / 522 / 106
Регистрация: 22.03.2015
Сообщений: 3,630
Завершенные тесты: 1
10.06.2016, 08:28 #8
Цитата Сообщение от karat39 Посмотреть сообщение
я правильно понял, что удлинение кода ведет к увеличению времени работы?
Такое бывает не всегда, все зависит от сложности алгоритма, наличие циклов, вызовы библиотек и т.п.
0
CheshireCat
Эксперт С++
2907 / 1256 / 114
Регистрация: 27.05.2008
Сообщений: 3,451
10.06.2016, 10:01 #9
Цитата Сообщение от karat39 Посмотреть сообщение
Код работает с целыми числами. Для целых чисел в с++ разработан целый набор типов для конкретных задач. На что может повлиять выбор того или иного типа? Если я работаю с числами до 1000, то например, можно использовать short int и unsigned short int и int. При этом логично использовать short int в целях экономии памяти. Но не проиграю ли я в производительности? Что очень важно.
Premature optimization is the root of all evil. (c) Donald Ervin Knuth.

Не лучше ли сначала написать правильный алгоритм, и, если он "вдруг" окажется недостаточно производительным, - посмотреть профилировщиком, где узкое место, и оптимизировать именно и только это узкое место?
0
karat39
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 137
10.06.2016, 10:06  [ТС] #10
Цитата Сообщение от CheshireCat Посмотреть сообщение
Не лучше ли сначала написать правильный алгоритм, и, если он "вдруг" окажется недостаточно производительным, - посмотреть профилировщиком, где узкое место, и оптимизировать именно и только это узкое место?
конечно лучше. Код и так не плох. Я просто человек въедливый и мне важна каждая мелочь. Если есть шанс на данной платформе выжать еще микросекунду, я буду ее выжимать. =)
0
CheshireCat
Эксперт С++
2907 / 1256 / 114
Регистрация: 27.05.2008
Сообщений: 3,451
10.06.2016, 10:38 #11
Ну ты перфекционист ) А что говорит Заказчик по этому поводу? Нужно ли ее выжимать? Будет ли Заказчик платить за это деньги?
0
karat39
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 137
10.06.2016, 10:46  [ТС] #12
Цитата Сообщение от CheshireCat Посмотреть сообщение
Ну ты перфекционист ) А что говорит Заказчик по этому поводу? Нужно ли ее выжимать? Будет ли Заказчик платить за это деньги
Да, бьемся за каждую микросекунду.
Приходится замерять под конкретной платформой даже стандартные функции (например, sprintf, atoi) и реализовывать свои решения.
0
CheshireCat
Эксперт С++
2907 / 1256 / 114
Регистрация: 27.05.2008
Сообщений: 3,451
10.06.2016, 10:55 #13
Тады да, согласен. Ну что ж, лучший выход в твоем случае - спускаться на уровень ассемблерного кода и смотреть. Потому что даже из одного и того же исходного кода две разные версии одного и того же компилятора (например, GCC 4.8 и 5.2) могут нагенерировать разный код.
0
karat39
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 137
10.06.2016, 11:02  [ТС] #14
Цитата Сообщение от CheshireCat Посмотреть сообщение
Потому что даже из одного и того же исходного кода две разные версии одного и того же компилятора (например, GCC 4.8 и 5.2) могут нагенерировать разный код.
Спасибо, так и эксперементирую. Применяю даже Intel. Но сколько бы его не хвалили, ощутимо в моих задачах он себя еще не показал.
Что касается ассма, тоже пытаюсь до него спуститься. Не все пока получалось. Я заводил тут тему соответствующую.
Пытаюсь банально на асме обогнать и strcpy и memcpy, подгоняя размеры блоков памяти (db, dw, и тд) для меньшего количества итераций, не получается обогнать. Хотя дизассебмлерный strcpy генерирует невероятное кол-во кода. Не хватает знаний скорее всего про память, процессор, взаимодействие и тд. Ну ничего, решатся более глобальные задачи, спущусь до оптимизации и до этого уровня =))
0
liv
375 / 342 / 124
Регистрация: 07.10.2015
Сообщений: 1,281
Завершенные тесты: 1
10.06.2016, 11:03 #15
rao, Вы забыли добавить, что перед каждой командой, у которой стоит word ptr
добавляется префикс 0x66, который удлиняет и команду и время работы на один цикл
Если в одном месте, то немного, но если будет везде, то может и набежать...
Кроме того, некоторые компиляторы формируют так:
mov eax, [dword]
and eax, 0xffff
что тоже удлиняет код
2
karat39
6 / 6 / 2
Регистрация: 09.02.2016
Сообщений: 137
10.06.2016, 11:07  [ТС] #16
Расскажите на пальцах, как длина кода влияет на скорость?
Я начинал читать книгу, но пока отложил из важности других задач. Там рассказывалось, что исполняемый код помещается в кэш процессора, от сюда я и подумал, что чем меньше код, тем больше его туда поместится и быстрее будет алгоритм.
Сильно не смейтесь над моей мыслью, я тут (в этой области знаний) явно не авторитет.
0
liv
375 / 342 / 124
Регистрация: 07.10.2015
Сообщений: 1,281
Завершенные тесты: 1
10.06.2016, 12:11 #17
karat39, в общем-то, по большому счету, не стоит заморачиваться на оптимизации каждой команды...
Хоть это и может дать эффект, но весьма незначительный. Т.к. кэш процессора весьма существенно сглаживает
все эти мелкие потери.
Можно немного убыстрить, если стараться меньше работать непосредственно с памятью, а больше с регистрами, такие команды и размером меньше, и быстрее работают. Но это обеспечивают, по крайней мере, должны, оптимизаторы кода.
А вот сосредоточиться максимально на оптимизации алгоритма стоит. Именно здесь обычно самые большие потери времени. Т.к. кэш тут не поможет, да и оптимизаторы, скорее всего, тоже. Можно так накрутить, что, будут делаться элементарно лишние вычисления... Или, как пример, если в наличии много ветвлений, то это заставит процессор постоянно перестраивать кэш, тем самым уменьшая выгоду от кэша и, соответственно, увеличивая время работы. Правда, оптимизаторы и с ветвлениями тоже пытаются справляться. Но все же...
И наконец, если передо мной стоит задача написать что-то действительно быстро работающее, я пишу полностью на Ассемблере
Я не надеюсь на оптимизаторы, а пишу так, как мне надо
Но таких задач на современных компьютерах уже практически нет
0
Nick Alte
Эксперт С++
1646 / 1018 / 174
Регистрация: 27.09.2009
Сообщений: 1,945
Завершенные тесты: 1
12.06.2016, 18:49 #18
Цитата Сообщение от _liv_ Посмотреть сообщение
Я не надеюсь на оптимизаторы, а пишу так, как мне надо
И измерения показывают, что получается таки лучше, чем у оптимизаторов? Если да, то на сколько процентов? Если измерения не производились, то как знать, что получается вообще лучше, а не хуже?
0
liv
375 / 342 / 124
Регистрация: 07.10.2015
Сообщений: 1,281
Завершенные тесты: 1
13.06.2016, 10:27 #19
Nick Alte, Вы знаете, лично мне не требуется проводить измерения. Мой 30-летний опыт рассматривания всевозможного кода под микроскопом говорит о том, что никогда не сделать автоматом так, как можно сделать ручками.
Безусловно, оптимизаторы неплохо компонуют код, особенно, если код хорошо написан. Но все равно, человек, хорошо знающий Ассемблер, сделает лучше. Я говорю не об отдельных вставках и фрагментах, а обо всем приложении в целом.
Я, разумеется, не призываю всех писать на асме, нужды нет, да и не каждому это дано. Сейчас для современных компьютеров более, чем достаточно, ЯВУ с оптимизаторами, да и неоптимизированные программы вполне сносно работают
А вот для контроллеров, где ресурсов не так много, лично я пишу исключительно на асме.
0
ct0r
Игогошка!
1784 / 686 / 43
Регистрация: 19.08.2012
Сообщений: 1,323
Завершенные тесты: 1
13.06.2016, 11:03 #20
Цитата Сообщение от _liv_ Посмотреть сообщение
Вы знаете, лично мне не требуется проводить измерения.
А еще лично вам не нужно ничего тестировать, потому что ваш код всегда работает. Сразу вспоминается Чак Норрис программирования - Джефф Дин
"Джефф Дин компилирует и запускает свой код перед коммитом, но только чтобы проверить на баги компилятор и CPU".

Цитата Сообщение от _liv_ Посмотреть сообщение
Но все равно, человек, хорошо знающий Ассемблер, сделает лучше.
А когда он сделает лучше, его сразу уволят, потому что все дедлайны пройдут. Есть такая вероятность. Нерационально тратить много человеческих ресурсов там, где еще не выяснили, что это нужно.

Цитата Сообщение от _liv_ Посмотреть сообщение
А вот для контроллеров, где ресурсов не так много, лично я пишу исключительно на асме.
А у нас и тут плюсы - и все норм!
1
13.06.2016, 11:03
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
13.06.2016, 11:03
Привет! Вот еще темы с решениями:

Выбор типа источника данных
Работаю в Visual Studio 2008. При попытке выбрать тип источника данных на...

Выбор типа базы данных
Лирическая часть. В университете получил тему на доклад: "Тенденції в...

Выбор типа данных пользователем во время работы программы
Работаю с формами, хочется сделать выбор пользователем типа данных во время...

Убрать выбор типа документа в составном типе данных
Добрый день. Такой вопрос, как убрать выбор типа документа в составном типе...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru