«Какой моделью кода мне воспользоваться?» — часто возникающий, но нечасто разбираемый вопрос при написании кода для архитектуры х64. Тем не менее, это довольно интересная проблема, и для понимания генерируемого компиляторами машинного кода х64 полезно иметь представление о моделях кода. Кроме того, для тех, кто беспокоится о производительности вплоть до мельчайших команд, выбор модели кода влияет и на оптимизацию.

Информация по этой теме в сети, или где бы то ни было еще, встречается редко. Самым важным из доступных ресурсов является официальный х64 ABI, скачать его можно по ссылке (далее по тексту он будет упоминаться как «ABI»). Часть информации также можно найти на man-страницах gcc. Задача данной статьи — предоставить доступные рекомендации по теме, обсудить связанные с ней вопросы, а так же хорошими примерами через используемый в работе код продемонстрировать некоторые концепты.

Важное замечание: эта статья не является обучающим материалом для начинающих. Перед ознакомлением рекомендуется уверенное владение C и ассемблером, а так же базовое знакомство с архитектурой х64.

Воскресным вечером возникает особое чувство. Ты проводишь время с семьей после заслуженного отдыха, и наступает конец выходных, конец этого приятного перерыва. Завтра опять на работу. В такие моменты я часто засиживаюсь на кухне в одиночестве и мечтаю о лучшем будущем, где не надо подчиняться догмам и расписанию. Где не заставляют ставить жизнь на паузу и продавать своё время за копейки.

Хочется проснуться в понедельник без будильника и отправиться на прогулку в красивые калифорнийские горы. Посидеть на пляже, глядя на людей и вдыхая солёный воздух.

Шесть лет назад в один такой воскресный вечер я понял, что сил больше не осталось. Работа довела до полного изнеможения. По какой-то причине я был совершенно измотан. Хотя не напрягался физически, но зубы отчего-то сжимались до боли.

Я включил компьютер и сделал что-то невероятное для себя. Попросил помощи. Зашёл на HN и запустил новый тред. Я не знал, что и как сказать, но пальцы сами стучали, пока проблема не вылилась на страницу. Вот что я тогда написал: «Нас могут уволить, и я не знаю, что делать» (тред в разделе 'Ask HN', 114 комментариев).

Меня как фулстек-разработчика раньше всё устраивало. Коллеги обращались за советом. Я знал все входы и выходы из всех проектов моего отдела и некоторых других. В компании из тысячи человек все знали меня по имени. Я написал десятки инструментов, которые используются в компании по сей день.

Относительная производительность CPU на один доллар после анонса нового поколения сравнительно дешёвых серверных процессоров Intel Cascade Lake-X (W-2200) в октябре 2019 года. Источник: Intel

AMD официально подтвердила, что высокопроизводительные процессоры Ryzen Threadripper 3-го поколения выйдут в ноябре 2019 года, но сохранила в секрете детали. В то же время Intel сообщила торговым партнёрам, что готова потратить на ценовую войну три миллиарда долларов. Intel подчёркивает, что чистая прибыль AMD за прошлый год составила всего $300 млн, и она не выдержит демпинга. Intel также оперативно выпустила семейство относительно дешёвых серверных процессоров семейства W-2200 (см. под катом) и относительно дешёвых игровых процессоров Core i9 10-го поколения.

В то же время планы AMD становятся яснее благодаря «мастер-плану», который компания случайно (или «случайно») выложила в открытый доступ (документ уже удалён, вот копия, интерес представляют страницы 550/558).

SLA, оно же «service-level agreement» —соглашение-гарантия между заказчиком и поставщиком услуг о том, что получит клиент в плане обслуживания. Также в нем оговариваются компенсации в случае простоев по вине поставщика и так далее. По сути SLA — это верительная грамота, с помощью которой дата-центр или хостинг-провайдер убеждает потенциального клиента в том, что он будет всячески обласкан и вообще. Вопрос в том, что в SLA можно написать все что угодно, да и события, прописанные в этом документе, наступают не слишком часто. SLA — это далеко не ориентир в подборе дата-центра и надеяться на него уж точно не стоит.

Все мы привыкли подписывать какие-то договоры, которые возлагают определенные обязательства. Не исключением является и SLA — обычно самый оторванный от реалий документ, который можно вообразить. Более бесполезен, наверное, только NDA в юрисдикциях, где понятия «коммерческой тайны» толком не существует. А вся проблема в том, что SLA никак не помогает клиенту в правильном выборе поставщика, а только пускает пыль в глаза.

Что чаще всего пишут в публичной версии SLA хостеры, которую показывают публике? Ну, первой строкой идет такой термин, как «надежность» хостера — это обычно цифры от 98 до 99,999%. По сути, эти цифры — лишь красивая выдумка маркетологов. Когда-то, когда хостинг был молодым и дорогим, а облака только снились специалистам (как и широкополосный доступ для всех и каждого), показатель аптайма хостинга был крайне и крайне важен. Сейчас же, когда все поставщики используют плюс-минус одно и тоже оборудование, сидят на один и тех же магистральных сетях и предлагают одни и те же пакеты услуг, показатель аптайма абсолютно непоказателен.