LINUX.ORG.RU

Объясните сишную магию v2

 ,


2

4

В продолжение темы: Объясните сишную магию

Ковыряю сорцы Skia и наткнулся на такой забавный ужас (ссылка):

int fLastMoveToIndex = 5; // любое число
fLastMoveToIndex ^= ~fLastMoveToIndex >> (8 * sizeof(fLastMoveToIndex) - 1);

Экспериментально удалось выяснить, что данный код меняет знак и отнимает 1 только если число положительное. Как он это делает - я даже знать не хочу.

Вопрос: что мешало написать банальный if, или хотя бы оставить комментарий? Типичное сишное какерство?

PS: производительно данного куска кода на погоду не влияет.

★★★★★

Ответ на: комментарий от max_lapshin

На 3% за год? Тут некоторые товарищи с криокамерой помнят как в n раз в год ускорялось. Сейчас такого нет и не будет.

peregrine ★★★★★
()
Ответ на: комментарий от seiken

потому что он хейтит с и с++ поэтому и прицепил что типа сишное какерство. Читает код видимо чтобы переписывать на свой любимый недоязычёк.

bonta ★★★★★
()
Ответ на: комментарий от peregrine

гораздо больше.

Интел очень сильно ускоряет процессоры и количеством ядер, и внутренней архитектурой.

Сравнивать одночастотные процессоры сегодняшние и 5-летние просто смешно.

max_lapshin ★★★★★
()

Тред не читал, но Hackers delight про подобные битовые хаки уже советовали?

anonymous
()
Ответ на: комментарий от max_lapshin

Интел очень сильно ускоряет процессоры и количеством ядер, и внутренней архитектурой. Нет, не сильно ускоряет. Последние 5 лет это все вариации скайлейка. Количество ядер(4/8 в 2016 вс 10/20 сейчас) это, конечно, хорошо, но амд объективно лучше.

anonymous
()
Ответ на: комментарий от bonta

Да я реторический вопрос задал. Понятно, что чел неадекват.

seiken ★★★★★
()
Ответ на: комментарий от max_lapshin

Заявляет тот кто на С ничего толкового не написал

А про оптимизации тем более не знает, лол

И в бложке отписывает как современные броузеры медленно файлы открывают

Видимо после переписывания оптимизаций в красивый код такими же «гениями» как вы ?

anonymous
()
Ответ на: комментарий от anonymous

Заявляет тот кто на С ничего толкового не написал

Ну давай, хвастай, маэстро! Наши глаза и уши открыты. Ведь ТЫ же не «тот, кто на С ничего толкового не написал»?

anonymous
()
Ответ на: комментарий от max_lapshin

Интел очень сильно ускоряет процессоры и количеством ядер, и внутренней архитектурой

Где факты, алеу? Я привел факты, корень десятой степени из двух — 7% в среднем роста производительности в год. Какие факты можешь противопоставить ты?

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Количество ядер(4/8 в 2016 вс 10/20 сейчас) это, конечно, хорошо, но амд объективно лучше

Делать процессоры 14 нм с малым числом ядер тупо экономически невыгодно. По этой причине в процессор уже засунули северный мост и видеокарту — потому что проще засунуть бесполезные транзисторы на кристалл, чем выпускать кристалл без них по почти той же цене. Десятилетний переход с 32 нм на 14 нм дал рост частоты с 3.9 до 5.2 ГГц — это курам на смех, абсолютный предел транзисторов по частоте уже достигнут.

byko3y ★★★★
()

А вот просто интересно. На эльбрусе, наверное, можно и через условный оператор написать с той же эффективностью? Как я понимаю, на Эльбрусе нет такой проблемы, которая есть на интелях, что на интелях очень дорогая ошибка по условному переходу. На эльбрусах типа такие вещи параллелятся, и ошибка не стоит так дорого уже.

Кто может прокоментировать из специалистов, если таковые присутствуют здесь?

dave ★★★★★
()

Комментарий не нужен. Код самодокументируемый.

perl5_guy ★★★★★
()
Ответ на: комментарий от dave

на интелях очень дорогая ошибка по условному переходу

Не знаю, почему ты берешь в пример эльбруас, а не передовые GPU, которые тоже имеют много элементов VLIW, или даже ARM с его условным выполнением в составе огромного числа инструкций.

На Cortex-M4 2010 года выпуска стоимость заполнения пайплайнов — 3 цикла максимум, однако, неправильное предсказание ветвления на Cortex-A15. Cortex-A57. Cortex-A72 стоит под 15 циклов. Как и у x86.

VLIW не используется где попало в GPU, потому что скорость выполнения у разных операций разная, и нет смысла совать деление и помещение значения в регистр в одну операцию. Потому в ARM и GPU независимые операции записываются различными инструкциями, а связанные операции могут быть записаны в одной инструкции, в том числе SIMD.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

VLIW может загнать весь условный оператор if в одну инструкцию? И никаких хаков подобных вышеописанному не нужно тогда?

И мне интересен эльбрус гораздо больше, чем армы и gpu.

dave ★★★★★
()
Ответ на: комментарий от dave

Чисто теоретически VLIW позволяет просто одновременно вычислить и условие и оба варианта и отбросить лишний вариант. Но как на практике это большой вопрос.

anonymous
()
Ответ на: комментарий от dave

загнать весь условный оператор if в одну инструкцию

Как-то наивно считать инструкции в настоящее время, когда инструкции - это многопараметрическое нечто.

anonymous
()
Ответ на: комментарий от dave

Не нравится слово «инструкция» - назови тогда словом «арбуз»

Тогда переиначу вопрос: какую (оптимизационную) задачу решаешь, считая количество инструкций: бинарный размер кода, количество строк асм-кода, время выполнения кода, что-то еще?

anonymous
()
Ответ на: комментарий от anonymous

Товарищ, что ты ко мне пристал? Читай выше, что я написал. Что мне было интересно, то я узнал. Отстань уже от меня.

dave ★★★★★
()
Ответ на: комментарий от dave

Интересно даются познания. Твое сообщение-вопрос Объясните сишную магию v2 (комментарий) осталось без ответа.

Ты пытаешься сложную последовательность зависимых действий собрать в одну инструкцию vliw (что-то вроде атомарного compare-and-swap). Вообще-то vliw задуман для компоновки в одну инструкцию незвисимых действий, которые параллельно раскидываются по исполнительным блокам. Я не отрицаю, что при желании можно собрать зависимые действия в одну составную инструкцию, но будет ли такая составная инструкция удовлетворять требованиям независимости времени выполнения от данных (или что ты хочешь получить от сего действия).

anonymous
()
Ответ на: комментарий от fsb4000

Могу предположить что код подготовили для сборки на платформах/компиляторах которые не могут оптимизировать. А вообще есть же сверху (в #if 0) пояснение для тех кто не осилил манипуляции с битами. Можно было бы ещё в макрос это запрятать.

GuruOfTheWeb
()
Ответ на: комментарий от peregrine

закон мура больше не работает (устал).

anonymous
()
Ответ на: комментарий от max_lapshin

Я на штеуде с 2003 года и менял проц 4 раза с тех пор, теперь 5 назревает. Профит был до 10 года, после слабый прирост производительности, ну а сейчас хочу менять, т.к. vt-d и vt-x нужны, а на i7-3770K vt-d нету, но теперь штеуд в пень и буду на amd собирать.

peregrine ★★★★★
()
Ответ на: комментарий от seiken

Подтверждаем.

composite = (pixel[0] & 243) | ((((min(95, max(0, color - 80))) // 32) << 2) ^ 8)
    luma = pixel[0] & 243
    color = 80 + ((pixel[0] >> 2 & 3) ^ 2) * 32

А как ещё-то?

mertvoprog
()
Последнее исправление: mertvoprog (всего исправлений: 1)
Ответ на: комментарий от a1batross

Я был бы рад увидеть ЛОР без анонимусов

Анонимус, рад был бы видеть ЛОР без тебя, но тогда, наверное, форум окончательно превратится в помойку. Лучше уж такие модераторы как ты, чем вообще никаких.

anonymous
()

Как он это делает - я даже знать не хочу.

fail. ты ещё скажи, что обратный квадратный корень про алгоритм Ньютона из движка Quake //you not supposed to understand this неинтересно.

битхаки же. ничего сложного. распиши на бумажке, станет нагляднее.

anonymous
()
Ответ на: комментарий от anonymous

про алгоритм Ньютона из движка Quake

Я даж разочарован. Метод ньютона не является самым быстрым алгоритмом. Приблизительный подсчет через "(1 + a) * (1 << (n >> 1)) >> 1" (где n — позиция старшего бита, a — результат деления на 2^2n) с таблицами коррекции будет пошустрее и безо всяких делений, которые необходимы с алгоритмом ньютона и которые ни разу не быстрые. Ровно как небыстрое и само аппаратное извлечение корня. По сути метод ньютона превращает аппаратное деление в извлечение корня.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от anonymous

Делить? А на 0,5 домножить не судьба?

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

byko3y ★★★★
()

fLastMoveToIndex ^= ~fLastMoveToIndex >> (8 * sizeof(fLastMoveToIndex) - 1);

Вопрос: что мешало написать банальный if, или хотя бы оставить комментарий? Типичное сишное какерство?

Для таких сишников есть отдельный этаж в аду. А может царь писал и мы не доросли, чтобы легко читать подобное

Тред не читал: автор кода сам выдернул откуда-то и вот получили

I-Love-Microsoft ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.