Нашел " хотя современные компиляторы оптимизируют код гораздо хуже, чем это может сделать программист вручную "

Ты идиот.

Instruction selection - это NP-полная задача. Ты никогда не справишься с ней лучше, чем компилятор, твоей жизни не хватит даже по тупым эвристикам перебрать все варианты для чего-либо хоть немного сложного.

Сдвиги со знаковыми - UB.

Сдвиг отрицательного знакового, Вы, наверное, хотели сказать. Потому что сдвиг положительного знакового - не UB.

Где ты был в 1992ом?

в первом классе

Вы, похоже, не прочитали и не осознали что я написал.

Ценящие своё время люди не разбирают выхлоп компилятора.

Когда-то делал эксперименты по сравнению скорости memcpy и у меня получалось, что прямая реализация на Си

void* memcpy(void* b, const void* a, int n){
    char *s1 = b;
    const char *s2 = a;
    for(; 0<n; --n)*s1++ = *s2++;
    return b;
}

была быстрее, чем реализация и glibc, и libc из openBSD. Такие дела.

О, анонимус знает умные слова и ругательства.

Иди скажи это авторам glibc про то как компилятор cоптимизирует memcpy.

Иди скажи это авторам glibc про то как компилятор cоптимизирует memcpy.

Им это только ленивый не говорил еще. Так же как придуркам, которые весь X11 засрали копиями duff device. То, что имело смысл во времена PDP-11, сегодня давно уже не более чем дебилизм.

Годы идут, анонимные аналитики не меняются.))

Анонимус, если у тебя есть реализация memcpy на Си, которая работает быстрее текущей, кинь им патч. Ну или хотя бы тут выложи, а мы посмотрим и потестируем.

Выше я написал реализацию memcpy, которая у меня работала быстрее glibc'шной.

Быстрее на копировании 4х байт? Твоя примитивная реализация эффективна в копировании не больших кусков, когда в глибцшной на расчёты выравнивания уходит больше времени чем на копирование. Нормальные реализации используют многобитовые регистры(mmx например) копируя за такт 16(mmx) байт. Сравни их при копировании 1гига рамы, например.

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

В таком случае, почему же противники Gentoo говорят о малоэффективности или даже бесполезности пересборки сорцов под свой ЦП?

Почему любая твоя тема скатывается в многостраничный срач? Я тоже так хочу.

Почему любая твоя тема скатывается в многостраничный срач? Я тоже так хочу.

Ахахах)) А я думал тут у всех такое, но похоже это уже закономерность)

Учитывая, что у меня отображается треда процентов 20, здесь батти дискутирует сам с собой. И в других похожая ситуация.

У меня glibc работает всё таки быстрее примерно в 20 раз в тесте из 200 тыс копирований по 16К с -O2.

Если твой пример собрать с -O3, то работает сравнимо с glibc но не надо забывать, что у компилятора есть возможность сделать inline для собственной реализации или хотя бы вызывать её напрямую, в то время как glibc memcpy вызывается из .so по указателю. Да и c -O3 слишком опасно всё подряд собирать.

Вам надо было ассемблерный код посмотреть. Потому что в зависимости от параметров оптимизации и степени примитивности тестового кода gcc мог либо просто выкинуть код вашего цикла (вместе с массивом и с вызовом Вашей функции) за ненадобностью, либо проинициализировать его заранее значениями исходного массива.

Зато весело!

Вот сейчас попробовал сам еще раз и мне не удалось повторить результат.

Но если у тебя 20 лет опыта на асме и ты наизусть знаешь даташиты по ЦПУ

интересно, в каком НИИ ты изучал 20 лет даташит по процессору 2013го года?

в первом классе

ну а я школу заканчивал. В те годы это было общепринятое мнение. ЕМНИП i80486 от AMD был полностью идентичен intel по системе команд и таймингам. Т.е. если ты писал на асме, ты мог быть _уверен_ в том, что твой код будет работать где угодно точно также. И если у тебя XOR даёт профит, то он везде даёт профит. А вот с пней начились разночтения, что привело к анальной боли старпёров, и к широкому распространению(в узких кругах) твоей любимой Gentoo. Которая выдавала реальный профит на новых камнях благодаря оптимизации _старого_ кода под _новый_ камень.

Сейчас история опять пожрала свой хвост…

Ценящие своё время люди не разбирают выхлоп компилятора.

потому в их выхлопе сплошное говно.

что прямая реализация на Си была быстрее, чем реализация и glibc, и libc из openBSD. Такие дела.

возможно это случилось потому, что твоя glibc была собрана для совместимости с i486, а твой CPU был способен на большее. Потому даже прямая реализация после оптимизации gcc -mcpu=native дала лучший результат, нежели i486.

Иди скажи это авторам glibc про то как компилятор cоптимизирует memcpy.

авторы в курсе, но не у всех Gentoo, и многие юзают другие дистры.

Выше я написал реализацию memcpy, которая у меня работала быстрее glibc'шной.

сначала пересобери свою glibc под native, а то мегабакс тебя с говном смешает.

В таком случае, почему же противники Gentoo говорят о малоэффективности или даже бесполезности пересборки сорцов под свой ЦП?

причин две:

1. в критичных местах программисты всё равно ставят НЕ glibc'шную реализацию, а свой велосипед.

2. amd64 появилась недавно, и самые новые CPU не слишком отличаются от самых старых. Т.ч. в 64х битах можно сегодня под самый старый затачивать. Пока ещё.

А я разве сказал, что 20 лет нужно изучать даташиты?

И при чем тут генту? Что нельзя один сишный код собрать несколько раз для разных процессоров?

нет, не сказал. Но твой двадцатилетний опыт почти ничего не значит для процессора, который сделан недавно(в смысле обмазывания тактами). Причём даташит там обширный, вызубрить его не получится за неделю. А вот вбить семантику в компилятор — можно. Оно конечно похуже будет чем с опытным человеком, но опытного человека надо 20 лет готовить, а писать код надо СЕЙЧАС.

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

Ситуация на сегодня такая: компьютер не может пройти тест Тьюринга, его спалит любой школьник. Это с одной стороны. С другой: человек не может пройти тест Тьюринга наоборот — скажем вычислить 17842387312⁷. Даже если ты и научишься вычислять такое в уме, существующий интерфейс не позволит тебе ЭТО быстро и безошибочно вбить. Попробуй: 575666209306007130695275465348138326857314443252611681749205674211934208.

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

И при чем тут генту? Что нельзя один сишный код собрать несколько раз для разных процессоров?

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

Нет, не собираю. Я спрашиваю, почему файл memcpy.c нельзя собрать 5 раз под 5 моделей процессора и запихать всё в одну либу и вызывать в зависимости от модели нужную функцию.

Оно конечно похуже будет чем с опытным человеком, но опытного человека надо 20 лет готовить, а писать код надо СЕЙЧАС.

Я примерно это и пытался донести.

Прекрати, пожалуйста, позориться.

Позор - это ваша истерия.

Выучи разницу между implementation defined и UB

Для приложения, претендующего на кроссплатформенность, это одно и тоже.

Хотя вижу, что ты исправился. Предъявы отозваны.

Поздно, я вам уже на спину плюнул.

Сдвиг отрицательного знакового, Вы, наверное, хотели сказать. Потому что сдвиг положительного знакового - не UB.

А кто знает, что в знаковом целом будет только положительное значение?

Вот негодяй!

Вот негодяй!

Да, я такой :)

В таком случае, почему же противники Gentoo говорят о малоэффективности или даже бесполезности пересборки сорцов под свой ЦП?

каким образом это пересекается с тем что я написал? кого вообще волнует мнение сторонников и противников генты, кроме них самих?

Нет, не собираю.

Твои проблемы.

почему файл memcpy.c

Поясню - мемкопи на сишке никто не пишит - это слишком непереносимо и тормазно. Никакая сборка под «модель» ничего не даёт.

Глибц так и работает - там десятки функций, который в рантайме биндятся в зависимости от «фичей» камня.

Я спрашиваю, почему файл memcpy.c нельзя собрать 5 раз под 5 моделей процессора и запихать всё в одну либу и вызывать в зависимости от модели нужную функцию.

glibc и так большая и раздутая. Если её ещё для всех Over9000 CPU размножить, то она будет занимать больше, чем жрёт современный браузер.

К тому же, остаётся вопрос, как БЫСТРО выбрать нужную функцию, что-бы перебросить пару байт? Вы точно уверены, что будет профит от выбора?

Выучи разницу между implementation defined и UB

Для приложения, претендующего на кроссплатформенность, это одно и тоже.

тут я с тобой согласен, в остальном вы куда-то не туда ушли. Морду только друг другу не разбейте ☺

Поясню - мемкопи на сишке никто не пишит

а я о чем говорю?

также как и сейчас, по указателю. LD_PRELOAD примерно так и работает.

К тому же, остаётся вопрос, как БЫСТРО выбрать нужную функцию, что-бы перебросить пару байт?

jit

по вашему машина решает NP полные задачи лучше человеческого мозга? интересно, продолжайте публикации

по вашему машина решает NP полные задачи лучше человеческого мозга?

А ты не знал? Ну теперь знаешь.

по вашему машина решает NP полные задачи лучше человеческого мозга?

это очевидно. SAT возьми например.

Ну во-первых, невозможно формально приписать человеку такое понятие как NP. Во-вторых TSP мозгом можно решить довольно быстро. И в шахматах люди всетаки выигрывают машины.

И в шахматах люди всетаки выигрывают машины.

Ты отстал от жизни.

Ты удивишься.