Компания Google опубликовала (http://opensource.googleblog.com/2018/02/cpu-features-librar... библиотеку cpu_features (https://github.com/google/cpu_features), предназначенную для определения возможностей, поддерживаемых текущим CPU, таких как тип микроархитектуры и расширенные наборы инструкций AES, FMA (https://en.wikipedia.org/wiki/Multiply%E2%80%... BMI, SSE, AVX и NEON. Поддерживается работа с процессорами на базе архитектур x86, ARM/AArch64 и MIPS. Код поставляется (https://github.com/google/cpu_features) под лицензией Apache 2.0.
Библиотека преподносится как удобный способ на лету определить возможность использования той или иной расширенной функциональности, или принять решение по применению запасных обработчиков для устаревших систем. Недостающая функциональность библиотеки, необходимая для поддержки новых архитектур и определения возможностей CPU, может наращиваться через подключение расширений. Код написан в соответствии со спецификацией С89, что позволяет охватить большинство современных и устаревших компиляторов.
Библиотека также включает минимальный набор зависимостей и поддерживает разные стратегии определения функциональности CPU, что позволяет использовать её на разных платформах, в изолированных sandbox-окружениях и даже в условиях без возможности выполнить инструкцию cpuid (https://ru.wikipedia.org/wiki/CPUID).
Более того, в библиотеке не выполняются операции выделения памяти и не генерируются исключения, что даёт возможность использовать её в реализациях таких функций, как malloc, memcpy и memcmp.
Среди поддерживаемых методов определения функциональности отмечается инструкция cpuid, glibc-функция getauxval, /proc/self/auxv и /proc/cpuinfo.URL: http://opensource.googleblog.com/2018/02/cpu-features-librar...
Новость: http://www.opennet.me/opennews/art.shtml?num=48034
Ждём версии на javascript, тогда сайты никогда не ошибутся!
Доступа к этой информации через WebAPI не получить.
> Доступа к этой информации через WebAPI не получить.Насмешил. Спокойно получается id процессора, операционная система, разрешение монитора, платформа. Кстати, некоторые вещи даже без js получаются, а некоторые даже без scss.
id процессора - это не cpu_features.
Наверно вы имели ввиду css? Ибо scss это препроцессор css, он не обрабатывается браузером вообще никак.
> static bool HasXmmOsXSave()
> int GetX86FeaturesEnumValue(const X86Features* features, X86FeaturesEnum value)На С так не пишут!
В Google всё-таки лучше знают, как писать на C.
> как писать на C чтоб все перешли на go
#define bool intТоже мне, нашёл проблему.
А со второй строчкой что не так? Вполне себе C.
stdbool.h уже 18 лет как в стандарте.
С89, написано жеж
Какой-то интересный у них c89:https://github.com/google/cpu_features/blob/8e58ef0d2b1720d1...
А во второй строче ключевое слово enum пропущено. Если, конечно, они не сделали typedef
А с чего ты взял что там enum пропущено, а не struсt, union,...?
> На С так не пишут!показал бы что ли свой код, чтобы мы узнали как надо писать на Си
>о даёт возможность использовать её в реализациях таких функций, как malloc, memcpy и memcmp.А зачем внутри malloc определять процессор. Ну еще какой malloc вызывать и то один раз, но внутри?
Советую заглянуть в исходники той же либс - сразу станет понятно.
>>о даёт возможность использовать её в реализациях таких функций, как malloc, memcpy и memcmp.
> А зачем внутри malloc определять процессор.Ну например не все процы умеют PDPE1GB
https://github.com/google/cpu_features/blob/master/src/list_...А это вообще-то C++.
верно аноним подметил, половина проекта на плюсах написана
На с++ написана не сама библеотека, а исоплняемый list_cpu_features.
https://github.com/google/cpu_features/issues/11
То есть,cat /proc/cpuinfo
lshw | grep cpu
dmidecode -t 4уже недостаточно?
Да, и еще inxi
>Features revealed from Linux. We gather data from several sources depending on availability:
>from glibc's getauxval
>by parsing /proc/self/auxv
>by parsing /proc/cpuinfoЯсно, понятно.
>>Features revealed from Linux. We gather data from several sources depending on availability:
>>from glibc's getauxval
>>by parsing /proc/self/auxv
>>by parsing /proc/cpuinfo
> Ясно, понятно.что тебе ясно-понятно, там же нет qt
>> Ясно, понятно.
> что тебе ясно-понятно, там же нет qtгде твой пул-реквест?
>>> Ясно, понятно.
>> что тебе ясно-понятно, там же нет qt
> где твой пул-реквест?В ядро? И нафига вообще qt, если мне, например, на сервере надо псмотреть?
> В ядро?в ядро, наверное, не примут. Но в гугля попробовать можно - все равно они еще не знают, зачем они эту хрень придумали.
> И нафига вообще qt
ну как же - стильно, модно, молодежно, отраслевой стандарт, что-нибудь еще про "миссию гугль" вверни. Это ж каждый дурак grep по cpuinfo может, а тут - библиотека!
ещё одна сопля научилась комитить и возомнила себя линусом торвальдсом..
Приятная штука. Подумал что хорошо бы ее в Буст включить, но потом понял что это Си а не С++. А кстати для Си есть что-то подобное бусту?
Буст, это который сомнительная библиотека для горе-разработчиков?
> Буст, это который сомнительная библиотека для горе-разработчиков?Это который активно добавляют в std. Может вы ещё и std не пользуетесь?
>> Буст, это который сомнительная библиотека для горе-разработчиков?
> Это который активно добавляют в std. Может вы ещё и std не
> пользуетесь?при программировании на си? Нет, не пользуется.
>>> Буст, это который сомнительная библиотека для горе-разработчиков?
>> Это который активно добавляют в std. Может вы ещё и std не
>> пользуетесь?
> при программировании на си? Нет, не пользуется.Словестный аквилибрист вы. Кстати, в новом стандарте C таки есть std. http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3631.pdf
>> при программировании на си? Нет, не пользуется.
> Словестный аквилибрист вы.просто умею читать не на одно сообщение вверх. С точки зрения программиста на C (особенно - периодически сталкивающегося с проектами, использующими boost, и с удовольствием наблюдавшим за чехардой их проблем на ровном месте - "хорошо, очень хорошо, просто замечательно... что не у меня!") это именно как написано - вредный и неуклюжий костыль для кое-какеров. Если тебе понадобилось что-то из предоставляемого boost - ты либо можешь сделать как минимум не хуже (для конкретной своей мелкой задачи), заодно избавившись от лишней зависимости, либо не стоило и браться.
> Кстати, в новом стандарте C таки есть std.
тем хуже для нового стандарта. Впрочем, непосредственно по ссылке ничего такого не видно (но это и беллетристика, а не документ).
и даже Boost.Asio? Большинство остального уже есть в C++11
И где там std?
Это кроссплатформенный велосипед большого размера. Если проект - прототип, то буст подойдет. Иначе лучше сделать свой маленький велосипед.
> Это кроссплатформенный велосипед большого размера. Если проект - прототип, то буст подойдет.а при пожарном переходе от прототипа к коммерческому развертыванию, ты, конечно же, тут же переделаешь на что-то другое?
(у тебя ж именно в этот момент будет дофига свободного времени и возможностей все ломать по десять раз в день)
в общем, механику появления boost в жизни проекта ты описал правильно, но вывод сделал неверный.
Оно будет жить в проекте вечно, а через год разные его части будут требовать трех несовместимых версий одновременно.
> Приятная штука. Подумал что хорошо бы ее в Буст включить, но потом понял что это Си а не С++. А кстати для Си есть что-то подобное бусту?Да, в boost'e только этого не хватает. Хотя навалено уже много.
> А кстати для Си есть что-то подобное бусту?Нет. И за это мы его и любим (среди прочего).
Если вам нужен бюст, берите плюсы и не портите малину другим.
> /proc/cpuinfoБиблиотека, которая выводит /proc/cpuinfo? Я аж смузи на кадиган чуть пролил.
Это не пользовательская библиотека, что вам непонятно-то.
> Это не пользовательская библиотека, что вам непонятно-то.нам непонятно, откуда берутся "программисты", которым нужна специальная библиотека, чтобы парсить /proc/сpuinfo. Возможно, в какой-то биолаборатории пора навести порядок, и проверить, какие именно предметные стеклышки дают лизать жабам.
> Си-библиотекуПредлагаю объединить до "сиблиотеку". С остальными языками так же:
Go - гоблиотека;
Java - яблиотека.
> яблиотекачто-то Apple повеяло. Лучше это слово оставить для них.
Ну тогда Java - джаблиотека.
Ага, засудят :)
Растоблиотека, как-то сложно получилось
Раблиотека
Удавоблиотека
Рублиотека
Пыхотека
ПерлоткаНо всех делает D
Дискотека!
Почему не на ASM? хипстота очередная!
Для всех архитектур?
> Для всех архитектур?всех трех на которых есть /proc/cpuinfo, что-тотам в sys и команда cpuid ? Ахренеть сложная задача.
А на альфе оно работать и не будет.
>> Для всех архитектур?
> всех трех на которых есть /proc/cpuinfo, что-тотам в sys и команда cpuid
> ? Ахренеть сложная задача.
> А на альфе оно работать и не будет.Компилировать будешь для каждого процессора и подгонять под каждый? Ну раз тебе так легко...
>>> Для всех архитектур?
>> всех трех на которых есть /proc/cpuinfo, что-тотам в sys и команда cpuid
>> ? Ахренеть сложная задача.
>> А на альфе оно работать и не будет.
> Компилировать будешь для каждого процессора и подгонять под каждый? Ну раз тебеА что, на си комилировать уже не надо?
Подгонять под каждый, разумеется, нет, это тебе не си, где -march=atom не позволяет запустить на xeon'ах - никто не мешает (в рамках одной общей системы команд) сперва проверять, доступна ли команда/регистр/биты.
Для альфы, разумеется, придется писать полностью отдельно, ну так эта штука на ней все равно не работает. Даром что "компилировать" можно.> так легко...
да в общем обычная такая задачка для студента курса этак 3го, на курсовой проект, пожалуй, не потянет.
Для зачета курсового придется еще написать ту программу, ради которой понадобилась вообще runtime cpu detection. Не поверишь - скорее всего и это придется делать если и не целиком на ассемблере, то с asm вставками, компиляторы пока на такое не способны.
> А на альфе оно работать и не будет.Альфа сдохла 18 лет назад, разобрали на запчасти и винтики.
> Для всех архитектур?А вот кстати да, была бы тема. Кусок машинного кода для множества архитектур который процессорозависимо джампает на нужную ветку внутри себя, соответственно знает тип процессора, и далее делает "диагностику" по возможностям такового.
Основная проблема написания подобной штуки - надо подобрать команды переходов так, чтобы они джампали на определённом проце, а все "чужие" команды переходов на других процах выполнялись, как какая-нибудь обратимая хрень.
Дабы понимать, о чём я, простой пример18 7E - эта команда прыгает на 128 байт вперёд от самой команды на Z80 и совместимых.
EB 3E - эта команда прыгает на 64 байта вперёд от самой команды на x86 (в любом режиме, 16/32/64).К сожалению, команда 18 7E на x86 превращается в опасную sbb byte ptr [si/esi/rsi+xx],bh, а поэтому нам надо записать её несколько иначе.
Итоговая запись такова:
2C 18 7E 40 EB 3E
Поток выполнения для Z80 будет:
2C - INC L, то есть для восстановления регистра нам будет достаточно сделать DEC L
18 7E - JR на 0x7E (126) байт вперёд от адреса следующей команды (то есть в итоге на 128 байт)Поток выполнения для x86 будет:
2C 18 - SUB AL, 0x18, то есть для восстановления регистра нам достаточно будет ADD AL,0x18
7E 40 - JLE на 0x40 (64) байта вперёд от адреса следующей команды (то есть в итоге на 66 байт)
EB 3E - JMP на 0x3E (62 байта, в итоге на 64) вперёд, что является тем же самым адресом, что и в предыдущей команде), эту команду мы дописываем потому, что JLE зависит от результата вычитания, а нам надо прыгнуть железноЧто мы имеем в итоге:
На Z80 этот код прыгнет по адресу +129 байт от начала кода. На x86 этот код прыгнет по адресу +68 байт от начала кода. По этим адресам мы размещаем прочие детекторы для соответствующих CPU, и вуаля :)Естественно, для 3-4 разных процессоров задача усложняется настолько, что без цели даже пытаться подобрать последовательность лениво - надо писать собственно подборщик вариантов.
На том же x86 ещё придётся детектить режим исполнения, по стэку детектить актуальный call convention, детектить операционку, etc, etc. Но в целом всё реально.
> Но в целом всё реально.Нед.
>> Для всех архитектур?
> А вот кстати да, была бы тема.Была, лет 30 назад. Ищи код тут http://www.ioccc.org/
> Почему не на ASM? хипстота очередная!ASM для хипстеров! Настоящие программисты пишут в двоичном коде!
Эх молодежь, уже и не помнит как программировать проводками. :)
я бы тоже не отказался получать больше $100к в гугле, что бы писать такую откровенно скажем хрень
Так не отказывайтесь
Так не предлагают :)
Все равно не отказывайтесь. ;-)
эээ... так кто тебе мешает то? у нас что, железный занавес? Перестань комплексовать уже от своих нищенских доходов - слезами горю не поможешь.
> эээ... так кто тебе мешает то? у нас что, железный занавес?железный занавес уже много лет как не у нас, а у них.
Уехать работать в гугль, умея только "библиотеку для определения возможностей cpu" у него не получится.> Перестань
> комплексовать уже от своих нищенских доходов - слезами горю не поможешь.если ты не понял, он не о доходах, а о том, какую херню эти люди делают.
Зависть неосилянта
> Зависть неосилянтаСвои проекты ф студию. Только профы не забудь.
> я бы тоже не отказался получать больше $100к в гугле,
> что бы писать такую откровенно скажем хреньбольшая часть гугля тем и занимается, что делает всякую откровенную хрень. Уже лет десять как. Иногда сложную хрень, иногда вот такую.
Проблема только в том, что на самом деле им вешали лапшу на уши, что они - избранные, и будут улучшать мир. Те, кто эту лапшу принял всерьез - свалили, им неинтересно парсить proc. Те кто изначально на #@ю вертел - в пролете, не прошли интервью, "надо верить!" или хотя бы очень умело делать вид.
Угадай, какие остались?Если ты можешь пройти все уровни интервью в гугле - я уверен, ты можешь найти себе нормальную работу.
https://geektimes.ru/company/dataart/blog/268274/ - вот тебе интервью с инсайдером. "успешным", кому нужны лузеры.
> вот тебе интервью с инсайдером.
> "успешным", кому нужны лузеры.Что такое для тебя успех? Для меня заниматься тем, что я хочу, а не тем, где больше платят или вася пупкин сказал это круто работать в гугеле\M$\аппл или где ещё там.
... ниЧЧо, и ты когда то женишься и ребетёнков заведёшь :-)
$100k в Сан-Франциско — это как жить на 8к рублей в Москве. А удалённые кодеры Гуглу не нужны, в Bay Area под мостом отличные кадры бомжуют, можно даже не думать о том, чтобы нанять опеннетчика из Мордора.
бомжа в гей-ареа нанимать дорого, наймут бангалорского. Через год переедет туда - для них-то нет проблем с квотами h1b.
>$100k в Сан-Франциско — это как жить на 8к рублей в Москве.Бре-е-е-е-хня-я-я! (С)
Но с чего ты вдруг решило что тебе этот стольник дадут? Они умные ребята о отлично понимают твою ситуацию ==> будут доить так что 8-о
Она давно была в поставке Android NDK, теперь просто переехала
У меня когнитивный диссонанс: если программа, написанная на C/C++, откомпилирована и работает на [i386], то она точно не запустится на [arm64] без специальных ухищрений, поскольку это "шитый машиный код" и от переносимого в исходных кодах Си в бинарнике ровным счётом ничего не осталось (если не включены отладочные символы и другая неоптимизация, но в релизе от этого избавляются). А что уж там проверять - есть ли SSE/3DNow! или нет на [arm64] - это вторичная глупость.ЧТО они запихнули в свою CpuInfo, что она может на лету определять архитектуру процессора и его фичи, мультизагрузчик, компилятор и генератор тестового машкода под кучу процессоров для выполнения в реальном времени что ли?
оно не для переносимости бинарников на разных семействах, а внутри одного. например amd64. так что бы без пересборки бинарника можно было заюзать как все новейшие плюшки sse9999, так и на атлоне 10-летней давности запустить.
> так что бы без пересборки бинарника можно было заюзать как все новейшие плюшки sse9999Так все новейшие плюшки, так и общий код в бинарнике включаются ещё на этапе компиляции компилятором опциями компиляции исходного текста на C/C++. Зачем ещё что-то довыяснять на этапе выполнения специальным кодом, если компилятор сам уже ДОБАВИЛ эту возможность в бинарик? Используйте современные версии компиляторов, чтобы не нужно было определять фичи CPU, на котором выполняется код.
Тогда этот бинарник перестанет запускаться на древнем Атлоне. А с помощью библиотеки можно сделать, чтобы работал везде и использовал максиму фич имеющегося процессора.
В любом случае вы не сможете запустить бинарник для [amd64] на [i386] без добавления 32-битного кода, дублирующего основной. А вот код для [i386] вполне можно запустить на [amd64] при условии присутствия поддержки выполнеия этого кода. И довыяснять в нём о том, что он на самом деле запускается в 64-битном окружении, не имеет смысла без соответствующей возможности генерации 64-битных частей и передачи им управления.Хорошо, запустили 32-битный код для древнего Athlo'а XP на 64-битном Athlon X2 и узнали об этом во время выполнения. Ваши дальнейшие действия? Что дальше?
> Ваши дальнейшие действия? Что дальше?Ты начни с начала.
Есть у тебя программа пускач и плюгины к ней.
Плюгин №1 считает на чистом FPU, два на SSE, три на AVX-512.
Задача пускача узнать какой загружать. Надо все их проверить на пригодность здесь и сейчас.Ну или ты пишешь jit компилятор для своего скриптового языка.
И т.д. и т.п.
> Задача пускача узнать какой загружать. Надо все их проверить на пригодность здесь и сейчас.Это задача компилятора - вставить в результирующий бинарный код, оптимизирующие инструкции из расширенного набора. Если они поддерживаются процессором, использовать их, в противном случае будет задействован код, работающий с базовым набором регистров.
> Это задача компилятора - вставить в результирующий бинарный код, оптимизирующие инструкции
> из расширенного набора. Если они поддерживаются процессором, использовать их, в противном
> случае будет задействован код, работающий с базовым набором регистров.Обычно компилятор не способен оптимизировать код лучше, чем (грамотный) разработчик. Поэтому в критичных местах векторный код пишут руками.
Современные компиляторы способны выдавать лучше оптимизированный код, чем средний разработчик.
>Это задача компилятора - вставить в результирующий бинарный код, оптимизирующие инструкции из расширенного набораПроверять перед каждой инструкцией есть или нет в рантайме убивать идею (овчинка выделки будет не стоить).
Один раз проверил и перешел на тот вариант кода который оптимален для платформы. Компилятор должен подготавливать эти варианты.Ну и Вы пропустили задачу с собственным JIT компилятором - ему то надо знать, что можно, а что нельзя делать.
> Так все новейшие плюшки, так и общий код в бинарнике включаются ещё
> на этапе компиляции компилятором опциями компиляции исходного текста на C/C++. Зачем
> ещё что-то довыяснять на этапе выполнения специальным кодом, если компилятор сам
> уже ДОБАВИЛ эту возможность в бинарик? Используйте современные версии компиляторов, чтобы
> не нужно было определять фичи CPU, на котором выполняется код.Компилятор, в общем случае, сам ничего не добавляет. Если ты в коде явно заюзал, скажем, AVX, то никто за тебя не будет проверять, есть ли в CPU этот самый AVX. И если его нет, то твоя программа тупо навернется.
Некоторые новые компиляторы предоставляют средства, чтобы проверить наличие фич CPU в runtime. Но это непортируемо и не везде поддерживается. Так что либо надо использовать библиотеки вроде сабжа, либо писать что-то своё.
Д-е-б-и-л. Изучи код libc поуниверсальнее, которая умеет оптимизироваться под разные архитектуры (glibc пойдёт). В зависимости от доступных фич процессора она может обрабатывать стринги по старинке, может задействовать MMX, а может SSE. Можно скомпилировать, оставив только одну подпрограмму, а можно, чтобы таскала их все и выбирала в рантайме.
он, похоже, даже не в курсе, что процессоры различаются не только битностью.
куда ему там, glibc...ну и "компилятор генерит код лучше чем разработчик" - видимо, он прочитал в какой-то книжке начала 90х, времен хайпа риск-процессоров. Сегодня, чтобы компилятор сгенерил таки sse/ssse/avx код, надо ТАКУЮ хрень написать в исходнике, что глаза на лоб лезут. "зато переносимо". Ага, если не думать о том, КАК оно работает если компилятору таки не удалось опознать в этой вермишели свертываемость в sse инструкции, или на этой платформе оно устроено немного иначе.
> не генерируются исключенияисключения?
в Си?
фуф! пронесло.. не генерируются :-D :-D :-D
Вообще-то, сишный интерфейс не гарантирует, что внутри тоже C.
А такие фичи, как поддержку мелтдауна, оно детектит?
> А такие фичи, как поддержку мелтдауна, оно детектит?Нет.
> Код написан в соответствии со спецификацией С89, что позволяет
> охватить большинство современных и устаревших компиляторов.Неа.
> We target gnu89 and not c89.https://github.com/google/cpu_features/issues/11#issuecommen...
>> Код написан в соответствии со спецификацией С89, что позволяет
>> охватить большинство современных и устаревших компиляторов.
> Неа.
>> We target gnu89 and not c89.ффсе нормально, это gcc версий чуть поновее 2.7.2 и clang (если ключик не забыть) = "большинство", что не так?
При запуске на "Байкале" выдает ошибку ERR_CPU_NOT_FOUND
Ты б ещё на эльбрусе запустил, выдало бы ERR_TRANSISTORS_NOT_FOUND.
ERR_MONEY_NOT_FOUND_BUT_YOU_HOLD_ON
О! How-much-watch-и пожаловали :-)
попробуй "... but you stay strong!" глядишь на второй год не оставят :-)))