Насчет стандартов они не всегда поддерживаются компилятором, даже недавно где-то читал статью, что ради производительности компиляторы не спешат добавлять поддержку некоторых функций новых стандартов C++, и что в приоритете у них производительность. Да и есть к примеру самый известный ключ оптимизации -ffast-math, который в угоду производительности частично отказывается от совместимости со стандартом. К примеру про алгоритм разворачивания циклов, который в gcc 9 добавили по умолчанию, а до этого он включался ключем оптимизации, слышал, что он тоже нарушает стандарт. В любом случае оказался прав, асм листинг при использовании массива был в раза 1.5 короче, и работает примерно на 1% быстрее.
Действительно это так, жизнь объектов созданных new не должна заканчиваться при выходе, иначе теряется весь смысл указателей. Так в примере она же локальная и указатель никуда не передается, в таком случае мы просто получим утечку памяти.
Компилятор может как угодно оптимизировать код, тут никто не знает.
Могу предположить, что может использоваться inline для new. Это лишь предположения, что вполне возможно такое поведение с современными компиляторами, не давно с людьми смотрели как GCC развернул циклы и как LLVM, люди с опытом, которые занимаются написанием компиляторов не могли понять, что делает GCC и как оптимизировал код. LLVM посчитал цикл бесконечным и не смог развернуть, GCC его развернул и выплюнул очень длинный ассемблерный код. Как итог GCC был значительно быстрее и это с дефолтными настройками.
1. Это была опечатка, указатель на массив.
2. Компилятор может как угодно оптимизировать код, тут никто не знает. Сейчас компиляторы значительно умные, и там может быть что угодно, зависит от реализации. Все правильно new изначально размещал всегда в куче. Если указатель далее никуда не передается, то компилятор вполне может предсказать поведение. Предлагаю вам взять несколько современных компиляторов и разобрать ассемблерный код на выходе.
3. Когда даже не константа, если размер стека нам позволяет, то мы можем выделить нужный размер и сместить указатель на вершину стека.
4. Все то, только поведение зависит от компилятора и ключей оптимизации. Что на выходе будет предсказать сложно, новые компиляторы оптимизируют агрессивнее.
Грубая ошибка для C++. Много где встречал, что это является плохим тоном. Для базовых числовых типов не желательно использовать массив из указателей и использовать new, если переменная локальная! Основная проблема, что при указателях C++ может разместит массив в куче, а не в кэше(на стеке), отсюда алгоритм может потерять в скорости. Но посмотрел плюс минус скорость одинаковая при размере 100000, и видимо компилятор все же оптимизировал код, но с указателями примерно на 0.2с медленее(не смотрел почему, но некоторые компиляторы все же добавляют разименовывание указателя). Правильно для локальных массивов делать:
cbelkin математический алгоритм генерации случайных чисел с нужным распределением, на java отрабатывает 2.5с, на C++ с O2 оптимизацией под Linux 4.1с, на Windows с O2 — 6.3c, на NodeJS 5.2c. Да развиты, но не всегда идеально кэшем пользуются и не всегда могут развернуть циклы. На самом деле, еще скорость зависит от реализации стандартной библиотеки. Факторов много. Вот к примеру отправил pastebin.com/rhpWvssR в багрепорт LLVM, почти в 1.6 раз медленнее GCC, LLVM не может развернуть полностью цикл. Пишут виртуальные машины, люди, которые понимают C, C++ и компиляторы, лучше чем 90% программистов C++ и С. Они еще знают все популярные алгоритмы и пишут отдельно оптимизации кода под компиляторы и платформы. Это тот уровень к которому надо всем стремиться так как они делают просто чудеса. Сейчас JVM и NodeJS мягко говоря подтирают попу за слабыми программистами, сглаживают и даже прощают их грубые ошибки. Основной минус в скорости NodeJS и JVM это сборка мусора, если лишний раз ее не тригерить, то можно приличных скоростей добиться. Переписав алгоритм и минимизировав сборку мусора, даже на JS реально добиться существенного ускорение алгоритма. У NodeJS еще минус нет строгой типизации, отсюда есть оверхед — дополнительная проверка переменных. На личном опыте знаю, что не сложно добиться отличных скоростей на любом языке, главное знать как и понимать его особенности. К примеру кто пишет браузерные игры, они знают, что если взять к примеру анимацию с частотой кадров 30 кадров в секунду, то один кадр — страница должна рендериться менее чем за 30мс, иначе анимация будет дерганная. Поэтому там строго лишний раз не тригерят изменения стилей и сборку мусора, правильно используется подготовка кадров в циклах, иначе легко улететь более чем за 1с на отрисовку одного кадра, что происходит на большом количестве сайтов, и еще бывает тормозят они на мобильных устройствах.
dwdraugr причем тут полубог? Бессмертными богами считают себя люди, которые не читают документацию, но с пеной у рта пишут, что bash не безопасный язык программирования и при этом не понимают самых простых вещей. Подобные вещи из unpredictable behavior описываются в документации, и на нормальных курсах по программированию. Даже есть специальные задания на курсах по программированию на тренировку подобных кейсов. Такие вещи есть не только в shell скрипте, а во всех языках. Часто при трудоустройстве в солидную компанию, есть задания на понимание их и вас просто не примут, если вы их не знаете! С опытом такие вещи сразу бросаются в глаза, потому что это не какая-то супер сложная ошибка, а самая простая и детская. Конечно в шараж конторе ушатать сервер может вам сойдет с рук, но если убьете кластер в крупной компании, с вас за убытки могут взыскать очень приличную сумму и трудовую вам напишут не приятную запись, с которой вас почти никуда не возьмут… Да и best practice это использовать shellcheсk.
Совершали ли вы опасные ошибки при написании shell-скриптов?
Конечно, не совершает ошибок только тот кто ничего не делает. И сервера удаленные убивал и систему на рабочем компе. Правда было это лет 20 назад. Наверное самые распространенные грабли на которые наступал, это были правила файервола на удаленном сервере.
Это не C программист писал, а какой-то PHP гавнокодер. Нормальный кодер сразу видит и понимает потенциальные проблемы кода. Про что статья, я писал практически под каждым постом про shell скрипт, какие проблемы могут возникнуть и как от них защититься. Но тут на хабре действительно больше гавнокодеров, чем думающих и практикующих, и меня тупо заминусовали люди, которые не пишут правильно скрипты. Такое ощущение, что люди никогда даже в глаза официальную документацию не видели.
Речь про некие оболочки для админских задач, возможно, интерактивных из консоли.
С каких пор непревилегированные пользователи выполняют админские задачи?
Вам не кажется, что тут проблемы в архитектуре приложения, но никак не в шелл скрипте?
Такое количество кода поддерживать ничего сложного. Проблема не в количестве кода, а что архитектор приложения мудак. Такие вещи предусматриваются на этапе проектирования. Как правильно делать такое, уже ниже отписал. У меня есть скрипты в тысячи строк. Нет ничего не реального…
Есть сервер. На нем есть непривилегированные пользователи. Скрипт запускается либо со sticky bit/suid или чем-то подобным, либо прописан в sudo у пользователя на исполнение.
Это называется архитектор мудак. Можно уволнять. Запускать шелл скрипты через вебсервер это сверх извращение. Для выполнения задач от вебсервера где-то видел используют perl скрипт, но самое правильное пишется сервер с FIFO очередью(команды могут выполняться долго, вебсервер не может ждать выполнения, и должен быстро вернуть страницу на запрос), который будет принимать, валидировать и выполнять сообщения от вебсервера. bash это обычный язык сценариев, не надо молотком шурупы закручивать!
Вполне приличный скриптовый язык сценариев, ни больше ни меньше. Автоматизировать работу вполне удобно, хоть мне знакомы с десяток языков программирования и опыт программирования около 25 лет, для своих целей shell скрипт хорошо подходит. Вам никто не мешает переписать скрипт например на perl или любой другой язык. Вы всегда шуроповертом гвозди забиваете и утверждаете, что это плохой инструмент? Выстрелить в ногу можно в любом языке, все претензии не языку, а к автору скрипта, что он мудак и не смог нормально написать. С дуру даже коего чего можно сломать… Гавнокодеров в любом языке программирования полно.
Полностью согласен. Такое ощущение, что люди официальную документацию никогда не читали, и все поведение давно уже описано. Делают непонятные открытия туалетной бумаги в своих статьях вместо газеты, и всем пытаются о ней рассказать. Что все давно уже используют туалетную бумагу их не волнует…
ntsaplin открою секрет, несколько топовых авторов с большим количеством постов, продают инвайты и так же голоса накрутки, видимо создали сетку аккаунтов. Так же на хабр есть просто замечательная функция поощряющая накрутку и называется она «Программа Поощрения Авторов», с одной стороны штука хорошая, но так как некоторые авторы фултайм заняты постингом статей на хабр, то они живут с этого и как говорится грех себе не помочь, чтобы не сидеть месяц у пустой тарелки…
Была бы еще защита от накрутки, крупные компании были не раз замечены в накрутке голосов, в комментариях не редко срач и только негативные комментарии на публикацию, а автор еще пытается хамить на правильную критику, но самое интересное у таких людей и у статей репутация растет на хабре, когда мигом должны были бы увести в минус, да и статья мягко говоря слабая и автор больше пиарится, чем пользу хочет принести…
rzykov нет не читал, речь не про вашу книгу. Меня честно напрягают книги, в которых много воды, у издательств до сих пор отношение к книгам, как в художественной литературе — надо больше текста, и редакторы или автор заполняют книгу водой, а когда в книге тянут резину очень напрягает. Даже переводы некоторых книг настолько ужасны и не точны, что были куплены их оригиналы на английском.
dlinyj наверное потому, что не читаете официальную документацию к ядру, а там много интересного, а главное полезного, притом не только программистам, но так же администраторам и обычным пользователям))) Вот вам на закусочку www.kernel.org/doc/html/latest/kbuild/kconfig.html Может еще как минимум узнаете, что у menuconfig есть цветовые схемы, которые задаются MENUCONFIG_COLOR )))
JerleShannara честно говоря, сборку ядра уже давно делаю на нормальном многоядерном компе с десктопом, там нет таких проблем, да и ядра примерно за 2-3 минуты собираются и удобно конфигурировать, есть автосборочные скрипты, в любой момент могу обновить компилятор на новую версию, собрать из исходников и т.д., чтобы собрать ядро под ARM не обязательно собирать ядро на ARM системе с непонятным терминалом… Если терминал нормальный, то в nconfig все же приятнее работать. Удаленные сервера отдельная история, ошибка при сборке ядра может не вернуть сервер из ребута, по хорошему тоже надо делать сборку где-то у себя, дальше на тестовой системе с таким же оборудованием протестировать ядро, и уже залить на сервер.
Это во многих книгах так, больше половины книги рассказывается, какой офигенный автор или компания в которой он работает. Зато когда затрагиваются серьезные темы много важных деталей опускается, и ты сидишь пытаешься понять, что же автор там хотел сказать и главное как решать проблемы которые могут возникнуть, как их избежать. В итоге открываешь документацию на английском в интернете, и выбрасываешь книгу в корзину…
Могу предположить, что может использоваться inline для new. Это лишь предположения, что вполне возможно такое поведение с современными компиляторами, не давно с людьми смотрели как GCC развернул циклы и как LLVM, люди с опытом, которые занимаются написанием компиляторов не могли понять, что делает GCC и как оптимизировал код. LLVM посчитал цикл бесконечным и не смог развернуть, GCC его развернул и выплюнул очень длинный ассемблерный код. Как итог GCC был значительно быстрее и это с дефолтными настройками.
2. Компилятор может как угодно оптимизировать код, тут никто не знает. Сейчас компиляторы значительно умные, и там может быть что угодно, зависит от реализации. Все правильно new изначально размещал всегда в куче. Если указатель далее никуда не передается, то компилятор вполне может предсказать поведение. Предлагаю вам взять несколько современных компиляторов и разобрать ассемблерный код на выходе.
3. Когда даже не константа, если размер стека нам позволяет, то мы можем выделить нужный размер и сместить указатель на вершину стека.
4. Все то, только поведение зависит от компилятора и ключей оптимизации. Что на выходе будет предсказать сложно, новые компиляторы оптимизируют агрессивнее.
Грубая ошибка для C++. Много где встречал, что это является плохим тоном. Для базовых числовых типов не желательно использовать массив из указателей и использовать new, если переменная локальная! Основная проблема, что при указателях C++ может разместит массив в куче, а не в кэше(на стеке), отсюда алгоритм может потерять в скорости. Но посмотрел плюс минус скорость одинаковая при размере 100000, и видимо компилятор все же оптимизировал код, но с указателями примерно на 0.2с медленее(не смотрел почему, но некоторые компиляторы все же добавляют разименовывание указателя). Правильно для локальных массивов делать:
Вторая причина компилятор может векторизовать циклы при работе с массивом, а с указателями нет. Тут подробно расписано.
stackoverflow.com/questions/2305770/efficiency-arrays-vs-pointers
Третья причина при выходе из функции массив автоматически удалится.
Конечно, не совершает ошибок только тот кто ничего не делает. И сервера удаленные убивал и систему на рабочем компе. Правда было это лет 20 назад. Наверное самые распространенные грабли на которые наступал, это были правила файервола на удаленном сервере.
С каких пор непревилегированные пользователи выполняют админские задачи?
Вам не кажется, что тут проблемы в архитектуре приложения, но никак не в шелл скрипте?
Это называется архитектор мудак. Можно уволнять. Запускать шелл скрипты через вебсервер это сверх извращение. Для выполнения задач от вебсервера где-то видел используют perl скрипт, но самое правильное пишется сервер с FIFO очередью(команды могут выполняться долго, вебсервер не может ждать выполнения, и должен быстро вернуть страницу на запрос), который будет принимать, валидировать и выполнять сообщения от вебсервера. bash это обычный язык сценариев, не надо молотком шурупы закручивать!