Что быстрее if или switch
Что быстрее if или switch
А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные?
Например, есть примерно след. участок кода:
Вызов данной функции происходит довольно часто, поэтому интересует, будет ли хоть какой-то полезный выигрыш от использования switch в данном случае?
Не оптимизирует ли всё это дело компилятор так, что выйдет либо одинаковая производительность, либо даже хуже?
 | От: | LaptevVV |
| Дата: | 05.02.12 15:31 | |
| Оценка: | 1 (1) | |
 | От: | potapov.d |
| Дата: | 05.02.12 15:48 | |
| Оценка: |
Здравствуйте, Аноним, Вы писали:
А>Приветствую.
А>А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные?
А>Например, есть примерно след. участок кода:
А>
лет пять назад дизассемблировал подобный сниппет. в Release сборке студия данную последовательность if’ов преобразует в switch. (его ассемблерное представление, разумеется)
Здравствуйте, Аноним, Вы писали:
А>Приветствую.
А>А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные?
А>Например, есть примерно след. участок кода:
А>
А>Вызов данной функции происходит довольно часто, поэтому интересует, будет ли хоть какой-то полезный выигрыш от использования switch в данном случае?
А>Не оптимизирует ли всё это дело компилятор так, что выйдет либо одинаковая производительность, либо даже хуже?
А>Использую MS-компилятор.
Помнится даже на баше был гдето ответ. Тут чтоле
 | От: | watch-maker |
| Дата: | 08.02.12 12:36 | |
| Оценка: | 1 (1) | |
Здравствуйте, Аноним, Вы писали:
А>Приветствую.
А>А что, switch действительно выигрывает в скорости по сравнению с конструкциями if — else, если значения в нём последовательные?
А>Вызов данной функции происходит довольно часто, поэтому интересует, будет ли хоть какой-то полезный выигрыш от использования switch в данном случае?
Это существенно зависит от распределения значений входных данных. Если какой-либо зависимости в значениях value нет, то switch вполне может быть лучшим вариантом. Если же значение a или b встречаются значительно чаще (например в 95% и 4% случаев соответственно), то if может существенно превосходить в скорости switch.
Это связано с особенностью блока предсказания ветвлений процессора. Последовательные if позволяют ему «обучаться» на входных данных и лучше предсказывать нужную ветку программы. В то же время switch, если компилятор сделал из него таблицу и косвенный переход, будет справляться с этой задачей значительно хуже.
Например, для архитектур x86 и x86-64 подробнее об switch-против-if можно прочитать в «Intel® 64 and IA-32 Architectures Optimization Reference Manual».
Ну и вообще, в таких случаях может быть эффективна гибридная схема:
Для уверенности, что компилятор нас правильно понял, ещё бывает полезно обернуть условие (value == a) во что-то подобное __builtin_expect(value == a, 1) или __assume(value == a). Где __builtin_expect и __assume — соответствующие подсказки оптимизатору.
А>Не оптимизирует ли всё это дело компилятор так, что выйдет либо одинаковая производительность, либо даже хуже?
Универсального ответа тут нет. Но что тебе мешает просто посмотреть сгенерированный код самому? Для того, чтобы сказать, что получился одинаковый код, можно же даже не знать ассемблера.
 | От: | Sheridan |
| Дата: | 10.02.12 13:16 | |
| Оценка: |
Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит).
Методика: берем switch и else if каждого по сотне проверок. Замеряем время отработки цикла из 100000 итераций отдельно для if else, отдельно для switch. И это все замеряем по каждому числу, тоесть обходим каждую ветку ветвления. Выводим результаты по каждому ветвлению и усредненные в конце.
Ну, по коду думается мне будет понятнее.
Для не желающих листать эту простыню — вывод: собирайте с оптимизацией — в этом случае абсолютно без разницы что использовать 
В результатах конечно простыня еще та.
Результаты неоптимизированной сборки:
Как видите — вариант с if практически сразу потерял свои позиции и под конец разница с switch на порядок.
А вот результаты сборки с оптимизацией мгновенно ставят все на свои места
 | От: | Сыроежка |
| Дата: | 10.02.12 13:23 | |
| Оценка: |
Здравствуйте, Sheridan, Вы писали:
S>Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит).
На мой взгляд это совершенно бессмиысленное заниятие. Во-первых, часто компилятор для двух конструкций генерирует один и тот же ассемблерный код, если конструкции не сложные. Во-вторых, не каждый if можно заменить предложением switch. И, в-третьих, скорость ни одной программы не страдает от того, используете ли вы if или swicth.
| | От: | Sheridan |
| Дата: | 10.02.12 13:28 | |
| Оценка: |
Здравствуйте, Сыроежка, Вы писали:
С>На мой взгляд это совершенно бессмиысленное заниятие. Во-первых, часто компилятор для двух конструкций генерирует один и тот же ассемблерный код, если конструкции не сложные. Во-вторых, не каждый if можно заменить предложением switch. И, в-третьих, скорость ни одной программы не страдает от того, используете ли вы if или swicth.
Ребе, ну человек задал конкретный вопрос — я на него дал не просто ответ, а вполне себе даже исследование.
С написанными тобой буквами я то согласен и так. Только вот было интересно их както подтвердить
Подтвердил таки?
| | От: | watch-maker |
| Дата: | 10.02.12 13:46 | |
| Оценка: |
Здравствуйте, Sheridan, Вы писали:
S>Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит).
S>Методика: берем switch и else if каждого по сотне проверок. Замеряем время отработки цикла из 100000 итераций отдельно для if else, отдельно для switch. И это все замеряем по каждому числу, тоесть обходим каждую ветку ветвления. Выводим результаты по каждому ветвлению и усредненные в конце.
S>Ну, по коду думается мне будет понятнее.
S>Для не желающих листать эту простыню — вывод: собирайте с оптимизацией — в этом случае абсолютно без разницы что использовать
Тест плохой.
Например, gcc43 просто преобразует функцию test_if в такую:
Вы сравнили скорость работы двух пустых функций.
 | От: | batu |
| Дата: | 10.02.12 14:08 | |
| Оценка: |
Здравствуйте, Sheridan, Вы писали:
S>Написал на коленке немножко кода для замеров. Меряет в тиках процессора (ну, во всяком случае гугл так говорит).
S>Методика: берем switch и else if каждого по сотне проверок. Замеряем время отработки цикла из 100000 итераций отдельно для if else, отдельно для switch. И это все замеряем по каждому числу, тоесть обходим каждую ветку ветвления. Выводим результаты по каждому ветвлению и усредненные в конце.
S>Ну, по коду думается мне будет понятнее.
S>Для не желающих листать эту простыню — вывод: собирайте с оптимизацией — в этом случае абсолютно без разницы что использовать
| | От: | batu |
| Дата: | 10.02.12 14:10 | |
| Оценка: |
| | От: | Sheridan |
| Дата: | 10.02.12 15:51 | |
| Оценка: |
| | От: | Sheridan |
| Дата: | 10.02.12 16:29 | |
| Оценка: |
— оптимизатор г++ слишком хорош для данного случая, а я писал на работе, слишком хотел домой и не подумал об этом. Посыпаю голову пеплом, и все такое.
В общем я нагрузил алгоритм еще одной функцией, которая принимает в себя число-счетчик цикла и на его основе считает всякую фигню. Ну типа полезную работу делает.
Также я на отдельно замеряю среднее количество тиков работы этой функции и вычитаю это потом из результата.
Результат без оптимизаций
и результат с оптимизациями
Эстетическая красота: Switch vs If
Вводная
Немного нюансов
Речь ниже пойдет о сравнении оператора switch и его конкретной реализаций на языке Java и операторами if в виде оппонентов этой конструкции. О том, что у оператора switch имеется туз в рукаве — производительность (за редким исключением), пожалуй, знает каждый и этот момент рассматриваться не будет — так как крыть его нечем. Но все же, что не так?
1. Многословность и громоздкость
Среди причин, отталкивающих меня от использования оператора switch — это многословность и громоздкость самой конструкции, только взгляните — switch, case, break и default, причем опускаю за скобки, что между ними, наверняка, еще встретится return и throw. Не подумайте, что призываю не использовать служебные слова языка java или избегать их большого количества в коде, нет, лишь считаю, что простые вещи не должны быть многословными. Вот небольшой пример того, о чем говорю:
Итого для меня: switch/case/default VS if.
Если спросить, кому какой нравится больше код, то большинство отдаст предпочтение 1ому варианту, в то время как по мне, он — многословный. Речь о рефакторинге кода здесь не идет, все мы знаем, что можно было бы использовать константу типа EnumMap или IdentityHashMap для поиска списка по ключу channel или вообще убрать нужные данные в сам Channel, хотя это решение дискуссионное. Но вернемся.
2. Отступы
Возможно в академических примерах использование оператора swicth — это единственная часть кода, но тот код, с которым приходится сталкиваться, поддерживать — это более сложный, обросший проверками, хаками, где-то просто предметной сложностью код. И лично меня, каждый отступ в таком месте напрягает. Обратимся к ‘живому’ примеру (убрал лишнее, но суть осталась).
Итого для меня: 5 отступов VS 2.
Но опять, кому какой нравится вариант? Большинство отдаст предпочтение getReference1.
Отдельно стоит отметить, что количество отступов еще зависит от выбранного стиля форматирования кода.
3. Проверка на null
Если используется оператор switch со строками или енумами параметр выбора необходимо проверять на null. Вернемся к getTypes примерам.
Итого для меня: лишний код.
Даже если Вы абсолютно уверенны сейчас в том, что null ‘не придет’, это абсолютно не значит, что так будет всегда. Я проанализировал корпоративный багтрэк и нашел этому утверждению подтверждение. Справедливости ради стоит отметить, что структура кода выраженная через if не лишена этой проблемы, зачастую константы для сравнения используются справа, а не слева, например, name.equals(«John»), вместо «John».equals(name). Но в рамках данной статьи, по этому пункту, хотел сказать, что при прочих равных, подход со switch раздувается проверкой на null, при if же проверка не нужна. Добавлю еще, что статические анализаторы кода легко справляются с возможными null-багами.
4. Разношерстность
Очень часто, при длительном сопровождении кода, кодовая база раздувается и можно легко встретить код, похожий на следующий:
Итого для меня: разный стиль.
Раньше был ‘чистенький’ switch, а теперь switch + if. Происходит, как я называю, смешение стилей, часть кода ‘выбора’ выражена через switch, часть через if. Разумеется никто не запрещает использовать if и switch вместе, если это не касается операции выбора/под выбора, как в приведенном примере.
5. Чей break?
При использовании оператора switch, в case блоках может появиться цикл или на оборот, в цикле — switch, со своими прерываниями процесса обработки. Вопрос, чей break, господа?
Итого для меня: читаемость кода понижается.
Если честно, встречались и куда более запутанные примеры кода.
6. Неуместность
В java 7 появилась возможность использовать оператор switch со строками. Когда наша компания перешла на java 7 — это был настоящий Switch-Бум. Может по этому, а может и по другой причине, но во многих проектах встречаются похожие заготовки:
Итого для меня: появляются неуместные конструкции.
7. Гламурный switch под аккомпанемент хардкода
Немного юмора не помешает.
Заключение
Я не призываю Вас отказываться от оператора switch, местами он действительно хорош собой и лапша из if/if-else/else та еще каша. Но черезмерное его использование где ни попадя, может вызывать недовольство у других разработчиков. И я один из них.
Отдельно хотелось отметить, что c точки зрения понимания кода, у меня нет никаких проблем с switch/case — смысл написанного ясен, но вот с точки зрения восприятия эстетической красоты — есть.
И напоследок. Используйте то, что Вам приходится по душе, опуская за скобки навязанные мнения, главное, чтобы Ваш код был простым, рабочим, красивым и надежным. Всего хорошего.
if \ else vs. switch \ case в C#
Что лучше использовать: if\else или switch\case?
3 ответа 3
Ответ выше не совсем корректный, даже учитывая комментарий.
Если значения лежат рядом, например:
В таком случае компилятор генерирует таблицу переходов (jump table) (IL-код):
Как видно, «дырки» заполнились переходами за конец конструкции switch : IL_009a
Если расстояние между значениями слишком большое для построение одной таблицы, компилятор может разделить их на 2+ таблицы. Например:
Посмотрим что будет в общем случае. Я взял 20 случайных чисел:
В таком случае компилятор их сортирует, и ищет бинарным поиском:
Дополнение для String :
Я попытался создать очень большой switch на 60 строк, но ничего не изменилось.
Оба условных оператора работают с одинаковой скоростью. Так как на уровне машинных команд они преобразуются в одни и те же инструкции.
Выбирать имеет смысл только по вкусу и по задаче.
switch может работать только с одной переменной. У if таких ограничений нет.
На мой взгляд, язык C# слишком высокоуровневый для такого рода оптимизаций.
Пишите читаемый код 😉
Вы задаётесь неправильным вопросом.
Если ваша задача — ускорить вашу программу, то решением этой задачи никогда не будет «заменить свитч на последовательность ифов» или наоборот. Ускорение программы проводится на уровне используемых алгоритмов и структур данных.
Тот факт, что один или другой вариант в тех или иных условиях, на той или иной версии компилятора выполняется на несколько наносекунд быстрее, не стоит потраченных на него байт текста.
Во-первых, вы должны помнить, что ваша главная задача — не выиграть 10 тактов процессора (несчастное переключение контекста стоит намного больше!), а сделать вашу программу понятной. Поэтому вы должны использовать switch там, где это прибавляет читаемости коду, там, где это соответствует тому, что именно вы хотите сказать этим кодом. И использовать if там, где это лучше отражает вашу мысль.
Ну и во-вторых, то, что на одной версии компилятора один из методов выражения одной и той же идеи компилируется в более быстрый код, чем другой метод — штука временная и преходящая. Помните, что в C++ сначала рекомендовалось возвращать значения по ссылке для скорости, а затем пришёл тренд «want speed? pass by value!», и наверняка это поменялось сейчас ещё раз.
Поскольку код имеет одинаковый смысл, то в любом из его вариантов рано или поздно он будет компилироваться в одно и то же. JIT-компилятор C# покамест не генерирует одинаковый объектный код для этих двух случаев, а вот компиляторы C++ уже умеют.
Итак, то, какая из имплементаций скорее, а какая медленнее — это не абсолютное понятие.
Вы не должны жертвовать читаемостью кода ради сиюминутной мизерной выгоды. Пишите не «как скорее», а «как правильнее». Расходы на поддержку плохо написанного кода несравнимо больше выгод от микрооптимизаций.
«Switch» быстрее, чем «if»?
это switch сообщении на самом деле быстрее if заявление?
я запустил приведенный ниже код в компиляторе x64 C++ Visual Studio 2010 с помощью /Ox флаг:
и получил следующие результаты:
переключатель заявление: 5261 ms
Оператор If: 5196 ms
из того, что я узнал, switch операторы, по-видимому, используют таблицы переходов для оптимизации ветвление.
вопросы:
как будет выглядеть базовая таблица переходов в x86 или x64?
этот код использует таблицу перехода?
почему в этом примере нет разницы в производительности? Есть ли какая-либо ситуация, в которой и существенная разница в производительности?
обновление:
интересные результаты здесь. Не уверен, почему один быстрее,а другой медленнее.
12 ответов
существует несколько оптимизаций компилятора can сделайте на переключателе. Я не думаю, что часто упоминаемый «jump-table» очень полезен, поскольку он работает только тогда, когда вход может быть ограничен каким-то образом.
Если количество ветвей в коммутаторе чрезвычайно велико, компилятор может делать такие вещи, как использование двоичного поиска по значениям коммутатора, что (на мой взгляд) было бы гораздо более полезной оптимизацией, поскольку это значительно увеличивает производительность в некоторых сценариях, является таким же общим, как коммутатор, и не приводит к большему размеру генерируемого кода. Но чтобы увидеть это, вашему тестовому коду потребуется гораздо больше ветвей, чтобы увидеть любые разница.
чтобы ответить на ваши конкретные вопросы:
Clang генерирует тот, который выглядит как этой:
решение на основе таблицы переходов не использует сравнение вообще.
1.Как будет выглядеть базовая таблица переходов в x86 или x64?
таблица переходов-это адрес памяти, который содержит указатель на метки в чем-то вроде структуры массива. следующий пример поможет вам понять, как выглядит таблица переходов
2.Этот код использует таблицу перехода? В данном случае-нет.
3.Почему в этом примере нет разницы в производительности?
нет разницы в производительности, потому что инструкция для обоих случаев выглядит одинаково, нет таблицы перехода.
4.Существует ли какая-либо ситуация, в которой существует значительная разница в производительности?
Если у вас очень длинные последовательности если проверить, в в этом случае использование таблицы переходов снижает производительность, но это связано со стоимостью памяти.
девиз: компилятор достаточно умен, чтобы справиться с таким случаем:)
компилятор может скомпилировать оператор switch как код, эквивалентный if-оператору, или создать таблицу переходов. Скорее всего, он выберет один на другом на основе того, что будет выполняться быстрее или генерировать наименьший код в зависимости от того, что вы указали в параметрах компилятора-так что в худшем случае это будет та же скорость, что и if-statements
Я бы доверять компилятору, чтобы сделать лучший выбор и сосредоточиться на том, что делает код читаемый.
Если количество случаев становится очень большим, таблица переходов будет намного быстрее, чем серия if. Однако если шаги между значениями очень велики, таблица переходов может стать большой, и компилятор может не создавать ее.
откуда вы знаете, что ваш компьютер не выполнял какую-то задачу, не связанную с тестом во время цикла тестирования коммутатора, и выполнял меньше задач во время цикла тестирования if? Ваши результаты теста не показывают ничего, как:
до конца, чтобы он не оптимизируйте цикл, поскольку счетчик никогда не использовался в вашем примере, так почему компилятор выполняет цикл? Сразу же коммутатор всегда выигрывал даже с таким микро-бенчмарком.
другая проблема с вашим кодом:
в цикле переключения, против
в вашем цикле if. Очень большая разница, если вы это исправите. Я считаю, что размещение оператора внутри оператора switch провоцирует компилятор на отправку значения напрямую в регистры CPU, а не помещать его в стек первым. Поэтому это в пользу оператора switch, а не сбалансированного теста.
О, и я думаю, что вы также должны сбросить счетчик между тестами. На самом деле, вы, вероятно, должны использовать какое-то случайное число вместо +1, +2, +3 и т. д., Поскольку это, вероятно, оптимизирует что-то там. Под случайным числом я имею в виду число, основанное на текущем времени, например. В противном случае, компилятор может превратить ваши функции в одном длинная математическая операция и даже не беспокоиться о каких-либо петлях.
Я изменил код Райана достаточно, чтобы убедиться, что компилятор не мог понять вещи до запуска кода:
переключатель: 3740
если: 3980
(аналогичные результаты за несколько попыток)
Я также уменьшил количество случаев / ifs до 5, и функция переключателя все еще выиграла.
хороший оптимизирующий компилятор, такой как MSVC, может генерировать:
короче говоря, если переключатель выглядит медленнее, чем серия ifs, компилятор может просто преобразовать его в один. И это скорее всего будет не просто последовательность сравнений для каждого случая, но бинарное дерево поиска. См.здесь для примера.
Я отвечу 2) и сделаю несколько общих замечаний. 2) нет, в коде сборки, который вы разместили, нет таблицы перехода. Таблица переходов-это таблица назначений переходов и одна или две инструкции для перехода непосредственно в индексированное местоположение из таблицы. Таблица перехода будет иметь больше смысла, когда есть много возможных направлений переключения. Возможно, оптимизатор знает, что просто, если логика else быстрее, если количество назначений не превышает некоторого порога. Попробуйте еще раз пример с say 20 возможностей вместо 4.
Я был заинтригован и посмотрел, что я могу изменить в вашем примере, чтобы заставить его быстрее запускать оператор switch.
Если вы получаете 40 операторов if и добавляете случай 0, то блок if будет работать медленнее, чем эквивалентный оператор switch. У меня результаты вот: https://www.ideone.com/KZeCz.
эффект удаления случая 0 можно увидеть здесь:https://www.ideone.com/LFnrX.
нет, это если затем прыгать еще, если затем прыгать еще. Таблица перехода будет иметь таблицу адресов или использовать хэш или что-то в этом роде.
быстрее или медленнее субъективно. Например, случай 1 может быть последним, а не первым, и если ваша тестовая программа или программа реального мира использовали случай 1 большую часть времени, код будет медленнее с этой реализацией. Поэтому просто перестановка списка дел, в зависимости от реализации, может сделать большой разница.
не уверен, почему один быстрее,а другой медленнее.
это на самом деле не слишком сложно объяснить. Если вы помните, что неправильно интерпретированные ветви в десятки-сотни раз дороже, чем правильно предсказанные ветви.
на % 20 версия, первый случай / если всегда тот, который попадает. Современные процессоры «узнают», какие ветви обычно берутся, а какие нет, поэтому они могут легко предсказать, как эта ветвь будет вести себя почти каждая итерация цикла. Это объясняет, почему версия «if» летает; она никогда не должна выполнять что-либо после первого теста, и она (правильно) предсказывает результат этого теста для большинства итераций. Очевидно, что «переключатель» реализован немного иначе-возможно, даже таблица переходов, которая может быть медленной благодаря вычисляемой ветви.
на % 21 версия, ветви по существу случайны. Поэтому многие из них не только выполняют каждую итерацию, CPU не может угадать в какую сторону они пойдут. Это тот случай, когда таблица переходов (или другая оптимизация «коммутатора»), вероятно, поможет.
очень трудно предсказать, как часть кода будет работать с современным компилятором и процессором, и это становится все труднее с каждым поколением. Лучший совет: «даже не пытайтесь; всегда профиль». Этот совет становится лучше-и число людей, которые могут успешно игнорировать его, уменьшается-с каждым годом.
все это означает, что мой объяснение выше в значительной степени является догадкой. 🙂
обратите внимание, что когда коммутатор не компилируется в таблицу переходов, вы можете очень часто писать if более эффективно, чем коммутатор.
(1) Если в случаях есть порядок, а не худший случай тестирования для всех N, вы можете написать свои if, чтобы проверить, если в верхней или нижней половине, то в каждой половине этого, двоичный стиль поиска. в результате в худшем случае logN, а не N
(2) если некоторые случаи / группы гораздо чаще, чем другие случаи, то проектирование ваше если изолировать эти случаи сначала может ускорить среднее время через
вот некоторые результаты из старого (теперь трудно найти) bench++ benchmark:
нет. В большинстве частных случаев, когда вы входите в ассемблер и выполняете реальные измерения производительности, ваш вопрос просто неправильный. Для данного примера ваше мышление определенно слишком короткое, так как
Кажется мне правильным выражением приращения, которое вы должны использовать.