Оператор goto. Ищу примеры эффективного использования

Приветствую,
Тема сложная, но может оказаться интересной для опытных программистов. Оператор goto хоть и гибкий, но отходит от принципов структурного программирования. Я исследую эту тему, и ищу примеры, где использование goto оправдано в плане компактности, эффективности, читабельности кода. Например, goto помогает:
* выйти из многоуровневого цикла (где break не справится)
* избавиться от структур вложенных if-блоков
* ...
какие еще примеры?

Добавлено через 16 секунд
Язык - любой, например Си.

0

Сообщение от Shamil1 Сообщение от Eddy_Em Видимо, имеется в виду вместо goto вызвать вложенную функцию Да. С захватом нужных переменных.

Так вы напишите это. И сами увидите как стало менее читаемо, чем с goto.

0

Сообщение от Quinn67 Например, goto помогает: * выйти из многоуровневого цикла (где break не справится) * избавиться от структур вложенных if-блоков

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

Сообщение от Quinn67 какие еще примеры?

Уже сам факт что найти удачные примеры затруднительно - показатель. Обычно если мысль удачна, то нет проблем с примерами.

Понимаю что иной раз прописные/банальные истины раздражают, и хочется пооригинальничать. Ничего, это проходит

0

Сообщение от Igor3D Уже сам факт что найти удачные примеры затруднительно - показатель

Батенька, а чего вы в эту тему залезли-то? Уж примеров было — пруд-пруди! Да и вообще, любой, кто хоть немного пишет код, может привести некоторое количество.

0

Сообщение от Eddy_Em Уж примеров было — пруд-пруди!

Та какой там "пруд", скорее "театр одного актера"

0

Сообщение от Eddy_Em Оптимизировать нужно все, что будет запускаться больше нескольких раз…

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

Оптимизация и низкоуровневая оптимизация - не одно и то же. Минусы низкоуровневой оптимизации обычно перевешивают плюсы. Так что пусть этим компилятор занимается.

Кроме того, низкоуровневая оптимизация часто завязана на конкретное железо и/или системное ПО. То, что вчера ускоряло работу, сегодня может замедлять. Мне теперь весь код переписывать?

0

Сообщение от Shamil1 Минусы низкоуровневой оптимизации обычно перевешивают плюсы. Так что пусть этим компилятор занимается.

Обычно так говорят те, кто не умеет оптимизировать.

Плюс оптимизации - задача выполнена. Так как ресурсов CPU стало достаточно для её выполнения. А без оптимизации - ресурсов не хватало. Низко- или высоко- уровневая - без разницы.
Такой ПЛЮС никакой минус не перевесит.

1

0

Сообщение от jcxz Плюс оптимизации - задача выполнена. Так как ресурсов CPU стало достаточно для её выполнения. А без оптимизации - ресурсов не хватало.

Не обязательно.

1. Весьма вероятно, что и без низкоуровневой оптимизации ресурсов хватало.
Обычно с приложениями, которые используют СУБД и/или HTTP, так и бывает.

2. А потом запустили на другом компьютере и выяснилось, что без оптимизации работает быстрее, чем с оптимизацией.
Потому что поменялся модуль предсказания переходов в процессоре или сборщик мусора в .NET или ещё что-нибудь.
Или совсем что-то экзотическое. Например, транспонирование матрицы стало работать в 10 раз медленнее из-за изменения размера кэша процессора.

Сообщение от jcxz Обычно так говорят те, кто не умеет оптимизировать.

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

0

Сообщение от jcxz Плюс оптимизации - задача выполнена. Так как ресурсов CPU стало достаточно для её выполнения. А без оптимизации - ресурсов не хватало. Низко- или высоко- уровневая - без разницы. Такой ПЛЮС никакой минус не перевесит.

В библии приводится 2 примера строчника: один оптимизирован "до упора", а второй написан "без затей". И говорится типа

Современный компилятор должен сгенерировать примерно одинаковый код

При этом "современный" писалось лет 30 назад.

Если Вы получили "ускоренный" вариант приложения - лучше внимательно разобраться за счет чего достигнут этот успех. Просто так, мол, "лучше код" не должно давать эффекта более 10%, скорее даже 5%. "В разы" ускоряется лишь изначально безграмотный код, ну или на каком-то зачуханом/специфичном процессоре. Но не нормальный код на нормальной, типовой машине. Возможен вариант "за счет использования новой версии используемых библиотек", может существенно, но "разов" обычно нет.

Гораздо более вероятно ускорение за счет multi-threading (распараллеливания) или его лучшей организации. Тут лучше знать текущее состояние дел, напр время выполнения тестовой задачи на 1, 4 и 8 нитках.

Дальше еще хуже. За счет "козырных" команд процессора (всяких SIMD). Мутное дело, особенно учитывая что новые команды/системы постоянно появляются. И наконец, GPU, отмахнуться от него сейчас не получается.

Конечно, все это можно назвать одним словом "оптимизация"

0

Сообщение от Igor3D multi-threading

там можно обратного эффекта добиться, если будет слишком много синхронизаций. Да и накладные расходы могут оказаться существенными при работе с небольшими объемами данных (грубо говоря, гистограмму для пары-тройки десятков измерений построить будет быстрей в один поток, чем в 16).
У видеокарты дополнительными тормозами является ветвление: как только в одном из потоков оно появляется, все встают и ждут… А еще та же CUDA не умеет в DMA, поэтому, т.к. объем видеопамяти у недорогих карт небольшой, приходится постоянно гонять массивы данных туда-сюда.
А алгоритмы значительно можно ускорить, действительно, продумав подход. Вот, лет много тому назад понадобилось мне для фильтрации шума и распознавания звезд на кадре использовать морфологические операции (эрозия и дилатация). Глянул в популярные на тот момент библиотеки - а там просто "в лоб" эта задача решалась, очень медленно. А мне же кадр примерно в 1 мегапиксель нужно было максимум за 20мс (а лучше - за 10) обработать - найти звезды и вычислить смещения (если звезда одна, достаточно тупого центроида, но нужно еще и фон вычесть). Реализовал это простыми логическими операциями: &|^~. Можно было бы вместо uint8_t использовать uint16_t, чтобы по 16 пикселей изображения "за один присест" обрабатывать, но поленился - "и так сойдет".
Вот интересно было бы сравнить, насколько сейчас "ускорили" openCV. А то, может, перестать уже свои старые велосипеды таскать и воспользоваться этой библиотекой? Еще реализация метода "шагающих квадратов" интересна: у меня не было желания ее параллелизовать, поэтому, увы, все делается очень медленно в один поток. Разве что построение изофот нужно не так уж и часто.

0