отведение 1 регистра под errno исключает его из некоторых мест. В результате добавляются push/pop — растет память и падает быстродействие. Но это происходит только в тех случаях, когда регистров перестает хватать. Если регистров хватает, то все остается как есть (при условии, что компилятор нормальный). А как часто случается, что регистров не хватает? Неизвестно. Это предмет для исследовательской работы.
Насчет 20лет назад. Действительно, это вполне может быть исторически сложившийся стиль.
Тот камент был адресный. Не думал, что вы его прочтете.
ABI какого компилятора так делает?
Вообще-то, компилятор должен начать использовать стек только если не хватает регистров, или если в функции берется адрес переменной. И то, если такая переменная не volatile, то компилятор может заоптимайзить. Я не скажу как поступает gcc для x86 и не скажу про clang, но когда-то я смотрел какой-то компилятор для arm от texas instrumnts — и там все было максимально регистровым.
Насчет замечаний про кэш. Вызов функции (хотя это может зависеть от архитектуры), это засовывание в стек адреса возврата. А возврат из функции — это соответственно, чтение адреса возврата из стека. По этой причине, размещение дополнительной переменной в стеке в большинстве случаев не должно создавать нагрузок, связаных с кэшем, т.к. стек и так должен быть в кэше.
Конечно, если сильно постараться, то можно сделать прогу, которая только и будет делать, что подтягивать в кэш данные ради errno. Но стараться придется очень сильно :)
Мое мнение — трюк не сэкономит быстродействия (тем более в большинстве случаев там однократный вызов) и не даст сколь-нибудь стоящего выигрыша в памяти. Он использован в большей степени исключительно ради наглядности.
Наглядность оно улучшает. Это да. Но в статье утверждается, что этот трюк позволяет повысить производительность и(или) экономить память. Пока нету тестов, очевидно, что это утверждение является оценочным суждением.
Хочется увидеть численные результаты эффекта, достигнутого за счет использования подобного стиля. Для различных платформ/компиляторов.
Но стоит ли сэкономленая память этого куска ~4кб вверху — это тоже вопрос, кстати. Тем более, что err выделяется обычно или в стеке, где занимает (даже с учетом теоретически возможной «нехватки» регистров процессора) никак не 4кб, или это вообще 1 ячейка на поток.
Вот кстати тоже интересный вопрос. Утверждается, что трюк позволяет убыстрить и(или) уменьшить размер в памяти. Но это лишь абстрактные слова, а где численные оценки достигнутого эффекта для разных архитектур?
У форка будет не тот адрес репозитория, что ставится вместе с любимой сборкой пользователя. А новый репозиторий еще надо прорекламировать.
Какая-то часть пользователей конечно найдет новый репозиторий, но не все.
В книге «толчок к размышлению или все о сортиах» есть глава про космос, в которой утверждается, что разработка космического туалета в ссср была поручена НИИ. Разработали. Чтобы продукты жизнедеятельности не летали по салону корабля, прилегание ягодиц к стульчаку должно быть плотным. По этой причине с ягодиц каждого космонавта снималась матрица, по ней отливался слепок в бронзе и по нему делали силиконовую насадку для конкретного космонавта. В книге утверждается, что зад Терешковой они потом так и не переплавили, и он там до сих пор хранится и является своего рода экспонатом. Правда ли это — не знаю. (Книга слегка желотопрессная)
Вообще-то, я и есть chabapok. Но вобщем, это сейчас не важно, т.к. речь о том, что в ядре под ошибки выделяют именно верхний диапазон. Я специально посмотрел код последнего стабильного ядра.
Вы оперируете таким понятием, как «исчезающе малая вероятность». Действительно, программисты иногда полагаются на вероятности. Например, uuid считается, что практически никогда не повторится, и им реально пользуются, и работает он хорошо.
Но по моему мнению, нету никаких оснований считать вероятность пренебрежимо маленькой в нашем конкретном примере.
Сами посудите:
— архитектур бывает много. Ядро же собирают не только под х86 и х86_64, но и под еще около 10архитектур.
— memory manager-ов бывает тоже много. Некоторые из них работают по приницпу чанков, которые циклически выделяются. Если будет такой и страница в него попадет — она обязательно отдастся в приложение когда-нибудь в обозримом будущем. К тому же достоверно известно, что отдача ранее использованных страниц — это потенциальная возможность кражи паролей, которую разработчики не игнорируют.
— вообще необязательно, чтобы речь шла о памяти. Например, в arm верхнее адресное пространство (это инфа не 100%) выделено под периферию. Т.е., адреса валидные и считай что уже выделены и используются не для ошибок. При этом в разных железках конкретная периферия может быть вшита в разные адресные пространства. Если драйвер такого периферийного устройства будет написан с использованием этих макросов, в железке устройство нельзя располагать по высоким адресам. Это совершенно неочевидный момент.
По этим причинам, тезис «если она вам не отдалась на старте процесса — то она вам не отдастся уже никогда» считаю в общем случае невалиден. По всей видимости, на х86 он работает хорошо.
Это вы сейчас о чем?
О user-программах, или о ядре?
Если о ядре. Допустим даже способ на х86 рабочий. Но кто гарантирует, что в других архитектурах оно не ляжет неблагоприятно?
Если о пользовательских программах — все сложней, чем вы написали. Даже если при старте захватить страницу не вышло, кто-нибудь эту страницу может когда-нибудь отпустить, она станет свободной. Потом ваш процесс запросит память — отдастся эта страница. А вы полагаетесь на то, что она вам не отдастся никогда.
Сишников никогда не останавливала опасность выстрелить себе в ногу! И если ты это сделал — ты ссзб. Если хочется уберечься от самострела, используйте java :)
А вообще конечно странно. Мне тоже несовсем ясно, как подобное оказалось в ядре. Допустим даже на х86 оно рабочее, но ведь ядро собирают под множество архитектур. И в какой-нибудь из них верхние адреса памяти вполне могут быть задействованы под валидные данные.
А что насчет второго вопроса? Ну пускай не Торвальдс, но неужели кто-то это принял?
Лучше тогда уж так:
0 — это null
1...MAX_ERRNO — это ошибки. может даже они поместятся в диапазон традиционного null.
все остальное — это валидные адреса.
потому, что ваш метод с 64 битной архитектурой в лучшем случае некрасив, а в худшем нерабочий.
А что это за диапазон такой странный — который третий по счету? это же пределами 32 бит.
Получается, такое может работать только на 64битном ядре, или как?
И еще такой вопрос: что значит ваш пассаж «люди начали ими пользоваться!»? Неужели Торвальдс принял от вас коммит с такими изменениями?
Скорей всего, уберут. Время cpu и gpu майнеров уже прошло, и поэтому этот майнер вряд ли даст сколь-нибудь ощутимый положительный эффект. Несмотря на большое количество установок.
Автор опоздал с этой идеей на несколько лет.
Лучше б придумал torrentcoin, которое базируется на участии в торрентах, но не является рейтингом и которое можно монетизировать.
Есть принципиальное отличие — собой можно перекрыть ту часть обзора камеры, где надо видеть. В этом случае адаптироваться будет просто не к чему.
Еще люди с очками подтвердят: Новые очки практически всегда что-то делают неуловимое с пространством, что чувствуешь себя неуютно, но к каждым следующим очкам привыкаешь быстрей. Это значит, что если натренировать себя к переворачивающим очкам, то очки от третьего лица, возможно, «пройти» будет проще.
Странно, что не Склоково, и не Британские ученные. Не замедляют ток воды, но при этом генерируют энергию? Ну так это же гениально! Подключаем это энергию к насосу, который качает воду в эти турбины! Ура! Вечный двигатель, Энштейн не прав и все такое. Это даже не нобелевка, это круче.
А если серьезно, кпд будет ниже, чем у электростанций, заточеных специально под выработку электричества. А про цену обслуживания «этого» вообще страшно представить. Вывод — либо это такая форма попила бабла (да да, отрицательной селекции политических элит подвержены все страны, и сша в том числе), либо проект предполагает какие-то ништяки, про которые журналисты в статье умолчали. Например, в качестве резервной системы, или что-нибудь в этом роде.
Вот теперь корректней, но все это расчет с позиции постфактум. Была, мол, такая неисправность, и посчитаем сколько стоит ее починка.
На практике же, в сц все наоборот: сначала надо огласить цену, потом убедиться, что клиент согласен, и только потом ремонт. Такой подход не может быть дешевле, и только в идеальном случае цена будет такой же, как в случае расчета постфактум.
Ну и плюс, мы не знаем что за сервис. Если это официальный сервис, то и запчасти там оригинальные.
Насчет 20лет назад. Действительно, это вполне может быть исторически сложившийся стиль.
ABI какого компилятора так делает?
Вообще-то, компилятор должен начать использовать стек только если не хватает регистров, или если в функции берется адрес переменной. И то, если такая переменная не volatile, то компилятор может заоптимайзить. Я не скажу как поступает gcc для x86 и не скажу про clang, но когда-то я смотрел какой-то компилятор для arm от texas instrumnts — и там все было максимально регистровым.
Насчет замечаний про кэш. Вызов функции (хотя это может зависеть от архитектуры), это засовывание в стек адреса возврата. А возврат из функции — это соответственно, чтение адреса возврата из стека. По этой причине, размещение дополнительной переменной в стеке в большинстве случаев не должно создавать нагрузок, связаных с кэшем, т.к. стек и так должен быть в кэше.
Конечно, если сильно постараться, то можно сделать прогу, которая только и будет делать, что подтягивать в кэш данные ради errno. Но стараться придется очень сильно :)
Мое мнение — трюк не сэкономит быстродействия (тем более в большинстве случаев там однократный вызов) и не даст сколь-нибудь стоящего выигрыша в памяти. Он использован в большей степени исключительно ради наглядности.
Наглядность оно улучшает. Это да. Но в статье утверждается, что этот трюк позволяет повысить производительность и(или) экономить память. Пока нету тестов, очевидно, что это утверждение является оценочным суждением.
Хочется увидеть численные результаты эффекта, достигнутого за счет использования подобного стиля. Для различных платформ/компиляторов.
Но стоит ли сэкономленая память этого куска ~4кб вверху — это тоже вопрос, кстати. Тем более, что err выделяется обычно или в стеке, где занимает (даже с учетом теоретически возможной «нехватки» регистров процессора) никак не 4кб, или это вообще 1 ячейка на поток.
Вот кстати тоже интересный вопрос. Утверждается, что трюк позволяет убыстрить и(или) уменьшить размер в памяти. Но это лишь абстрактные слова, а где численные оценки достигнутого эффекта для разных архитектур?
Какая-то часть пользователей конечно найдет новый репозиторий, но не все.
Вы оперируете таким понятием, как «исчезающе малая вероятность». Действительно, программисты иногда полагаются на вероятности. Например, uuid считается, что практически никогда не повторится, и им реально пользуются, и работает он хорошо.
Но по моему мнению, нету никаких оснований считать вероятность пренебрежимо маленькой в нашем конкретном примере.
Сами посудите:
— архитектур бывает много. Ядро же собирают не только под х86 и х86_64, но и под еще около 10архитектур.
— memory manager-ов бывает тоже много. Некоторые из них работают по приницпу чанков, которые циклически выделяются. Если будет такой и страница в него попадет — она обязательно отдастся в приложение когда-нибудь в обозримом будущем. К тому же достоверно известно, что отдача ранее использованных страниц — это потенциальная возможность кражи паролей, которую разработчики не игнорируют.
— вообще необязательно, чтобы речь шла о памяти. Например, в arm верхнее адресное пространство (это инфа не 100%) выделено под периферию. Т.е., адреса валидные и считай что уже выделены и используются не для ошибок. При этом в разных железках конкретная периферия может быть вшита в разные адресные пространства. Если драйвер такого периферийного устройства будет написан с использованием этих макросов, в железке устройство нельзя располагать по высоким адресам. Это совершенно неочевидный момент.
По этим причинам, тезис «если она вам не отдалась на старте процесса — то она вам не отдастся уже никогда» считаю в общем случае невалиден. По всей видимости, на х86 он работает хорошо.
О user-программах, или о ядре?
Если о ядре. Допустим даже способ на х86 рабочий. Но кто гарантирует, что в других архитектурах оно не ляжет неблагоприятно?
Если о пользовательских программах — все сложней, чем вы написали. Даже если при старте захватить страницу не вышло, кто-нибудь эту страницу может когда-нибудь отпустить, она станет свободной. Потом ваш процесс запросит память — отдастся эта страница. А вы полагаетесь на то, что она вам не отдастся никогда.
А вообще конечно странно. Мне тоже несовсем ясно, как подобное оказалось в ядре. Допустим даже на х86 оно рабочее, но ведь ядро собирают под множество архитектур. И в какой-нибудь из них верхние адреса памяти вполне могут быть задействованы под валидные данные.
заглянте в linux-3.19.1/tools/virtio/linux/err.h
Лучше тогда уж так:
0 — это null
1...MAX_ERRNO — это ошибки. может даже они поместятся в диапазон традиционного null.
все остальное — это валидные адреса.
потому, что ваш метод с 64 битной архитектурой в лучшем случае некрасив, а в худшем нерабочий.
Получается, такое может работать только на 64битном ядре, или как?
И еще такой вопрос: что значит ваш пассаж «люди начали ими пользоваться!»? Неужели Торвальдс принял от вас коммит с такими изменениями?
Автор опоздал с этой идеей на несколько лет.
Лучше б придумал torrentcoin, которое базируется на участии в торрентах, но не является рейтингом и которое можно монетизировать.
Еще люди с очками подтвердят: Новые очки практически всегда что-то делают неуловимое с пространством, что чувствуешь себя неуютно, но к каждым следующим очкам привыкаешь быстрей. Это значит, что если натренировать себя к переворачивающим очкам, то очки от третьего лица, возможно, «пройти» будет проще.
Странно, что не Склоково, и не Британские ученные. Не замедляют ток воды, но при этом генерируют энергию? Ну так это же гениально! Подключаем это энергию к насосу, который качает воду в эти турбины! Ура! Вечный двигатель, Энштейн не прав и все такое. Это даже не нобелевка, это круче.
А если серьезно, кпд будет ниже, чем у электростанций, заточеных специально под выработку электричества. А про цену обслуживания «этого» вообще страшно представить. Вывод — либо это такая форма попила бабла (да да, отрицательной селекции политических элит подвержены все страны, и сша в том числе), либо проект предполагает какие-то ништяки, про которые журналисты в статье умолчали. Например, в качестве резервной системы, или что-нибудь в этом роде.
На практике же, в сц все наоборот: сначала надо огласить цену, потом убедиться, что клиент согласен, и только потом ремонт. Такой подход не может быть дешевле, и только в идеальном случае цена будет такой же, как в случае расчета постфактум.
Ну и плюс, мы не знаем что за сервис. Если это официальный сервис, то и запчасти там оригинальные.
Рассчет с позиции сц выглядел бы совершенно иначе.
Т.е., вы только подтвердили своим расчетом мысль — что это тот тип поломки, который имеет смысл устранять самостоятельно.