Stupid C++ question.
What should return scanf_s("%s", s, 1) for input "asdf" ?
0 or -1?
What should return scanf_s("%s", s, 1) for input "asdf" ?
0 or -1?
Tfw иерархия QGraphicsShapeItem так продумана, что для генерализации установки центра Item'а в нужное место пришлось написать шаблон. Не знаю win это или fail.
— Спасибо. Интересно, а есть ли какой-то сборник всех UB в одном месте?
— конечно, в стандарте всё и собрано
twitter.com
— конечно, в стандарте всё и собрано
twitter.com
корутины позволяют писать в С++ красиво, без callback hell
но отнимают у тебя:
* call stacks
* local variables debug info
* compile time speed
* и (немного) уверенность (баги в конпеляторе, например даже вот в clang10).
речь идет об использовани корутин для async/await, см. для примера cppcoro: это либа то ли от автора драфта, то ли где-то рядом.
но отнимают у тебя:
* call stacks
* local variables debug info
* compile time speed
* и (немного) уверенность (баги в конпеляторе, например даже вот в clang10).
речь идет об использовани корутин для async/await, см. для примера cppcoro: это либа то ли от автора драфта, то ли где-то рядом.
Стрим про портирование непланарного слайсинга в slic3r будет сегодня в 21:00 GMT+3. Буду продолжать подтирать жопу за гениальным академическим программистом. В этом эпизоде вероятно будет правка GUI для корректного отображения трёхмерных путей, настройка ctags для крестов, копошение в перловой билд-системе и многое другое. Ежели придумаете чем рисовать чятик в иксах поверх всех окон с прозрачным фоном, как у Карины, будет здорово!
goodgame.ru
bitcoin:bc1qkjj2q8v555fje2evcxzqa2nh8h8te03r3h07nr
goodgame.ru
bitcoin:bc1qkjj2q8v555fje2evcxzqa2nh8h8te03r3h07nr
Стрим про портирование непланарного слайсинга в slic3r будет сегодня в 22:00 GMT+3. Буду подтирать жопу за гениальным академическим программистом, нахачившим функциональность так, что её ни один вменяемый меинтейнер не примет.
goodgame.ru
bitcoin:bc1qkjj2q8v555fje2evcxzqa2nh8h8te03r3h07nr
goodgame.ru
bitcoin:bc1qkjj2q8v555fje2evcxzqa2nh8h8te03r3h07nr
ccache рулит!
Открыл для себя vcpkg применительно к linux/cmake. Доволен деликатностью интеграции (кто-то скажет: костыль).
Корутины в плюсы завезли, а в gdb/lldb — забыли завести срецтва отладки. Back to printf.
Я перевел свой проект на асинхронные корутины, с асинхронных promises/futures/callbacks (всяких .then)
Теперь можно потихоньку выкидывать шаред пойнтеры КОЕ ГДЕ, а вместо них старое доброе RAII, потому что код по структуре теперь как синхронный, и не нужно ничего передавать в continuations, референсы каунтить итп.
Процентов на 15 медленнее стало, разве. Но шаред пойнтеры тормозят все 30.
Цифры приблизительные.
Теперь можно потихоньку выкидывать шаред пойнтеры КОЕ ГДЕ, а вместо них старое доброе RAII, потому что код по структуре теперь как синхронный, и не нужно ничего передавать в continuations, референсы каунтить итп.
Процентов на 15 медленнее стало, разве. Но шаред пойнтеры тормозят все 30.
Цифры приблизительные.
Самая привередливая из всех dependencies для текущего проекта — это плюсовая либа GRPC, с ней постоянно что-то не так, она резко выделяется из остального зоопарка. Из гита скрипт ее сборки идет с "treat warnings как errors", и это означает, что изначально есть настрой на победу — она наверняка не будет работать с твоим компилятором или дистром. Приходится патчить отключать эту опцию, варнинги потом норм, совершенно безобидные, все собирается, работает.
Из последнего: текущий релиз (1.23.0) не собирается на убунте 19.10, потому что переопределяет функцию из системных инклудов, в ранних убунтах, арчах итд этого не было.
Поэтому фиксировать в билд скриптах версию в GRPC и подобных СТРАННО написанных пакетов — бессмысленно, потому что через год все равно не соберется.
И самое жеж удивительно, все эти глюки со сборкой — НЕ оттого, что там, в GRPC, они выжимают последний миллиметр оптимизации ради, задействуя недокументированные или нестабильные фичи — это бы я понял. В совершенно тупых местах нежданчики. То ли горе от ума, то ли еще какой-то фактор.
Из последнего: текущий релиз (1.23.0) не собирается на убунте 19.10, потому что переопределяет функцию из системных инклудов, в ранних убунтах, арчах итд этого не было.
Поэтому фиксировать в билд скриптах версию в GRPC и подобных СТРАННО написанных пакетов — бессмысленно, потому что через год все равно не соберется.
И самое жеж удивительно, все эти глюки со сборкой — НЕ оттого, что там, в GRPC, они выжимают последний миллиметр оптимизации ради, задействуя недокументированные или нестабильные фичи — это бы я понял. В совершенно тупых местах нежданчики. То ли горе от ума, то ли еще какой-то фактор.
В CLion мейк и gdb отладчик делают программу компиляться-запускаться 23 секунд до выполнения кода (1 c++ файл поменялся). Хочется открыть reddit и читать туда, покуда оно чухается.
в Qt Creator ninja и gdb отладчик делают это за 11 секунд. Можно только почесать бок и поковыряться в носу, и снова работа.
Я знаю, что есть места, где пишут гамезы например, или деплоят на борды, там с меня будут ржать, но у меня просто лапки, мне нужно править и запускать.
в Qt Creator ninja и gdb отладчик делают это за 11 секунд. Можно только почесать бок и поковыряться в носу, и снова работа.
Я знаю, что есть места, где пишут гамезы например, или деплоят на борды, там с меня будут ржать, но у меня просто лапки, мне нужно править и запускать.
std::shared_ptr<bool> …
…когда очень надо захватить переменную в замыкание.
…когда очень надо захватить переменную в замыкание.
Правило SFINAE гласит: Если не получается рассчитать окончательные типы аргументов (провести подстановку шаблонных параметров) перегруженной шаблонной функции, компилятор не выбрасывает ошибку, а ищет другую подходящую перегрузку.
Правило существовало ещё в C++98, и было придумано, чтобы программа не выдавала ошибок, если где-то в заголовочных файлах оказался одноимённый шаблон, далёкий от контекста. Но впоследствии оно оказалось удобно для рефлексии при компиляции — в зависимости от свойств типа компиляция идёт по тому или другому пути.
hsto.org
4 байта на тег варианата перечисления. Прямо как в Haskell'е. Нет, я понимаю, IRL всё выравняют до машинного слова, но… вдруг там будет char и uint8_t.
4 байта на тег варианата перечисления. Прямо как в Haskell'е. Нет, я понимаю, IRL всё выравняют до машинного слова, но… вдруг там будет char и uint8_t.
Открыл для себя LLD.
set(CMAKE_SHARED_LINKER_FLAGS "-fuse-ld=lld")
set(CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld")
Вместо 6 секунд линковки стало 0.5
Не стоит благодарности. Не забываем также zapcc !
set(CMAKE_SHARED_LINKER_FLAGS "-fuse-ld=lld")
set(CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld")
Вместо 6 секунд линковки стало 0.5
Не стоит благодарности. Не забываем также zapcc !
Внезапно сообщаю, что грустная тема из псто #2944954 (как писать на плюсах под вендой если ты основательно сидишь на jetbrains IDE) имеет продолжение.
Во-первых в последней бете отладчик завезли, отлаживается через lldb, да вроде основные функции работают, всякие ушлые условные брекпойнты итп еще не допилили.
Во-вторых, нашел параллельный билд для CL (ms c++ compiler) (раньше не было), называется он jom, и притворяется nmake, и написан отчего-то на qt core, да пусть хоть на питоне.
Короче, проделал бенчмарки как конпелится мой проект, активный кусок который я пилю (36 compilation units, сильно не без templates), thirdparty и холодные куски не перекомпиляются, debug build:
28 sec = msvc 2019, jom instead of cmake, win
19.3 sec = cl /mp, visual studio 2019 (msbuild?), win
11.5 sec = zapcc(implements clang-7), linux
18.904 = clang8, linux
23.785 = gcc9, linux
такие дела. Говорят, clang умеет притворяться CL, осталось собрать zapcc под вендой и проверить его в этой роли.
почему мне не пофигу? потому что у меня жабовский склад ума, и я люблю когда оно быстро конпелит.
А вся эта байда с вендой потому что линукс не вышел у меня из слипа однажды недавно, скотино. В этой области конечно против гейбуков слова не скажешь.
Clion + MS Compiler — нету отладчика
Во-первых в последней бете отладчик завезли, отлаживается через lldb, да вроде основные функции работают, всякие ушлые условные брекпойнты итп еще не допилили.
Во-вторых, нашел параллельный билд для CL (ms c++ compiler) (раньше не было), называется он jom, и притворяется nmake, и написан отчего-то на qt core, да пусть хоть на питоне.
Короче, проделал бенчмарки как конпелится мой проект, активный кусок который я пилю (36 compilation units, сильно не без templates), thirdparty и холодные куски не перекомпиляются, debug build:
28 sec = msvc 2019, jom instead of cmake, win
19.3 sec = cl /mp, visual studio 2019 (msbuild?), win
11.5 sec = zapcc(implements clang-7), linux
18.904 = clang8, linux
23.785 = gcc9, linux
такие дела. Говорят, clang умеет притворяться CL, осталось собрать zapcc под вендой и проверить его в этой роли.
почему мне не пофигу? потому что у меня жабовский склад ума, и я люблю когда оно быстро конпелит.
А вся эта байда с вендой потому что линукс не вышел у меня из слипа однажды недавно, скотино. В этой области конечно против гейбуков слова не скажешь.
По результатам усилий, сообщаю, что перелезть на С++ девелопмент под венду с линукса не получилось. Причина венды вообще: предполагалось, что под вендой ноут лучше себя ведет (не оправдалось — разве шо хибернейт легче заенаблить) во время путешествий и переключений между видяхами (не оправдалось — если пользовал с 2 мониторами, то только ребут позволяет уйти в экономный режим, без дискретной видяхи).
Далее, достигнут следующий прогресс:
CLion + WSL — работает, но гуевые аппы гонять через X геморройно, т.к. плохая интеграция. Нету нормальных XServer чтобы интегрировался в виндовый window manager, а не фулскрин. X-Win32 — глючит на hi-dpi.
Clion + Mingw — линкует проект по 3 часа, не лечится
Clion + MS Compiler — нету отладчика
MS Visual Studio 2019 — иногда теряет шорткаты между запусками, некоторые невозможно пользовать в принципе (например Ctrl+F8) — достаточно отстойная IDE, чувствуется многолетний пофигизм на разработчиков, вынужденно конечно меняется, но без огонька.
MS Visual Studio 2017 — старый С++, и вроде как 2019 в остальном. Clang под ним — не пробовал.
VS Code — расширенный ноутпад, не нужна, но может когда-нибудь мы созреем друг для друга.
Всякие code-blocks итп — не пробовал, думаю, что 19 век.
Eclipse CDT — вгоняет в депрессию.
Объявляю, что сезон 2019-го года открытой души и сердца к современной Индусской версии Виндовз 10 за сим закрывается.
Далее, достигнут следующий прогресс:
CLion + WSL — работает, но гуевые аппы гонять через X геморройно, т.к. плохая интеграция. Нету нормальных XServer чтобы интегрировался в виндовый window manager, а не фулскрин. X-Win32 — глючит на hi-dpi.
Clion + Mingw — линкует проект по 3 часа, не лечится
Clion + MS Compiler — нету отладчика
MS Visual Studio 2019 — иногда теряет шорткаты между запусками, некоторые невозможно пользовать в принципе (например Ctrl+F8) — достаточно отстойная IDE, чувствуется многолетний пофигизм на разработчиков, вынужденно конечно меняется, но без огонька.
MS Visual Studio 2017 — старый С++, и вроде как 2019 в остальном. Clang под ним — не пробовал.
VS Code — расширенный ноутпад, не нужна, но может когда-нибудь мы созреем друг для друга.
Всякие code-blocks итп — не пробовал, думаю, что 19 век.
Eclipse CDT — вгоняет в депрессию.
Объявляю, что сезон 2019-го года открытой души и сердца к современной Индусской версии Виндовз 10 за сим закрывается.
Небольшой спор со знакомым наркоманом:
// кить=учить. Очепятался.
// И ещё привёл ссылку: ravesli.com
Вопрос с пограмистам: сколько у вас ушло на ваш язык и на сколько вы в нём шарите?
[11:25:04] <*@gmail.com > Я не говорил что с++легкий, Я говорил то его кить.не десять лет как ты это утверждал
// кить=учить. Очепятался.
// И ещё привёл ссылку: ravesli.com
Вопрос с пограмистам: сколько у вас ушло на ваш язык и на сколько вы в нём шарите?
По поводу #2932127 2 месяца спустя:
написал себе протобуф кодеген в Ц++ в функциональные структуры для немутабельного использоварния с шаред пойнтерами.
Дефайны инлайны темплейты auto c++17 — уже норм.
Человек привыкает ко всему.
(Зато теперь у меня запуск в отладке qt тестового клиента занимает 12 секунд — в отладчик грузятся 100 шлиб, в 1 поток, можно отдохнуть перед тем как прога начнет работать)
половину функций не вызвать в evaluation окошкевернулся обратно к gdb, оказывается можно компилить шлангом, отлаживать гдб, не знаю чего я тупил, теперь евалюейтится все
минус скорость компиляцииzapcc !!! плюс скорость компиляции!
минус удобные немутабельные структуры
написал себе протобуф кодеген в Ц++ в функциональные структуры для немутабельного использоварния с шаред пойнтерами.
минус лаконичность
Дефайны инлайны темплейты auto c++17 — уже норм.
Человек привыкает ко всему.
(Зато теперь у меня запуск в отладке qt тестового клиента занимает 12 секунд — в отладчик грузятся 100 шлиб, в 1 поток, можно отдохнуть перед тем как прога начнет работать)
закончилось тем, что я переписал под себя cf (composable futures), точнее, я их выкинул и написал свое future/promise/when_all и все такое. Почему? Потому что те что были, как мне показалось, глючили в одном случае. Пока переписывал, оказалось мой баг был в моем коде, но дописал все равно.
Работает в несколько раз быстрее: копирует меньше, аллокаций делает меньше, и, стало быть, занимает меньшую долю общей нагрузки на мультицпу, кучу итп, я доволен. То шо было раньше, для моих нужд overengineered.
Работает в несколько раз быстрее: копирует меньше, аллокаций делает меньше, и, стало быть, занимает меньшую долю общей нагрузки на мультицпу, кучу итп, я доволен. То шо было раньше, для моих нужд overengineered.
"плюсы в игрострое это анриал"
Программирование дата процессинга на современных плюсах с STL на быстрой тачке подобно программированию на жабе на средней тачке,
минус удобство отладки (аццкие шаблоны не посмотреть нормально значения в окошке, половину функций не вызвать в evaluation окошке)
минус скорость компиляции
минус удобные немутабельные структуры (ибо аллок в жабе != аллок в плюсах) отсюда минус скорость выполнения потому что выходит больше copy by value (маленьких данных, в основном куски parse tree, не больших) чем хотелось бы (sic!)
минус лаконичность
ну а так уже почти привык.
минус удобство отладки (аццкие шаблоны не посмотреть нормально значения в окошке, половину функций не вызвать в evaluation окошке)
минус скорость компиляции
минус удобные немутабельные структуры (ибо аллок в жабе != аллок в плюсах) отсюда минус скорость выполнения потому что выходит больше copy by value (маленьких данных, в основном куски parse tree, не больших) чем хотелось бы (sic!)
минус лаконичность
ну а так уже почти привык.
Регулярно в плюсах пишу println, а в скале printf. А на этой неделе вообще получилось printlnf.
Я правильно понимаю что QtCreator кладёт болт на поле sysroot в настройке kit'ов и будет использовать sysroot из ndk?
Написал немножечко на плюсцах native функций для kdb+, каких-то жалких 45кб сорцов, уже насобиралось 41килобайт кода:
11 .text 0000a250 0000000000001680 0000000000001680 00001680 2**4
Правда я там злоупотребляю жеж темплейтами для специализации по разным типам 8-)
Заглянул внутрь, а там — мама мия! Как далеко мы(они) ушли от z80 и от x86!
2199: 49 8d b2 c0 00 00 00 lea 0xc0(%r10),%rsi
21a0: 41 83 c0 04 add $0x4,%r8d
21a4: 62 11 7e 48 6f 44 17 vmovdqu32 0x80(%r15,%r10,1),%zmm8
21ab: 02
21ac: 62 f3 7d 48 3b c2 01 vextracti32x8 $0x1,%zmm0,%ymm2
21b3: 62 11 7e 48 6f 64 17 vmovdqu32 0xc0(%r15,%r10,1),%zmm12
21ba: 03
21bb: 62 f3 7d 48 3b e6 01 vextracti32x8 $0x1,%zmm4,%ymm6
21c2: 62 53 7d 48 3b c2 01 vextracti32x8 $0x1,%zmm8,%ymm10
21c9: 62 f2 7d 48 25 c8 vpmovsxdq %ymm0,%zmm1
21cf: 62 53 7d 48 3b e6 01 vextracti32x8 $0x1,%zmm12,%ymm14
21d6: 62 f2 7d 48 25 da vpmovsxdq %ymm2,%zmm3
21dc: 62 f2 7d 48 25 ec vpmovsxdq %ymm4,%zmm5
21e2: 62 f2 7d 48 25 fe vpmovsxdq %ymm6,%zmm7
21e8: 62 b1 fd 48 7f 0c 52 vmovdqa64 %zmm1,(%rdx,%r10,2)
21ef: 62 52 7d 48 25 c8 vpmovsxdq %ymm8,%zmm9
21f5: 62 52 7d 48 25 da vpmovsxdq %ymm10,%zmm11
21fb: 62 b1 fd 48 7f 5c 52 vmovdqa64 %zmm3,0x40(%rdx,%r10,2)
2202: 01
2203: 62 52 7d 48 25 ec vpmovsxdq %ymm12,%zmm13
2209: 62 52 7d 48 25 fe vpmovsxdq %ymm14,%zmm15
220f: 49 81 c2 00 01 00 00 add $0x100,%r10
2216: 45 39 c3 cmp %r8d,%r11d
2219: 62 f1 fd 48 7f 2c 7a vmovdqa64 %zmm5,(%rdx,%rdi,2)
2220: 62 f1 fd 48 7f 7c 7a vmovdqa64 %zmm7,0x40(%rdx,%rdi,2)
2227: 01
2228: 62 71 fd 48 7f 0c 42 vmovdqa64 %zmm9,(%rdx,%rax,2)
222f: 62 71 fd 48 7f 5c 42 vmovdqa64 %zmm11,0x40(%rdx,%rax,2)
2236: 01
2237: 62 71 fd 48 7f 2c 72 vmovdqa64 %zmm13,(%rdx,%rsi,2)
223e: 62 71 fd 48 7f 7c 72 vmovdqa64 %zmm15,0x40(%rdx,%rsi,2)
И еще loop unrolling там есть, типа если на входе от нуля до 8, то прыгается прямо на нужное место, в котором развернут частный случай, а иначе оно кусками по 8 элементов фигачит. Это так потому что AVX512.
Современная сишечка меня пугает и завораживает одновременно.
11 .text 0000a250 0000000000001680 0000000000001680 00001680 2**4
Правда я там злоупотребляю жеж темплейтами для специализации по разным типам 8-)
Заглянул внутрь, а там — мама мия! Как далеко мы(они) ушли от z80 и от x86!
2199: 49 8d b2 c0 00 00 00 lea 0xc0(%r10),%rsi
21a0: 41 83 c0 04 add $0x4,%r8d
21a4: 62 11 7e 48 6f 44 17 vmovdqu32 0x80(%r15,%r10,1),%zmm8
21ab: 02
21ac: 62 f3 7d 48 3b c2 01 vextracti32x8 $0x1,%zmm0,%ymm2
21b3: 62 11 7e 48 6f 64 17 vmovdqu32 0xc0(%r15,%r10,1),%zmm12
21ba: 03
21bb: 62 f3 7d 48 3b e6 01 vextracti32x8 $0x1,%zmm4,%ymm6
21c2: 62 53 7d 48 3b c2 01 vextracti32x8 $0x1,%zmm8,%ymm10
21c9: 62 f2 7d 48 25 c8 vpmovsxdq %ymm0,%zmm1
21cf: 62 53 7d 48 3b e6 01 vextracti32x8 $0x1,%zmm12,%ymm14
21d6: 62 f2 7d 48 25 da vpmovsxdq %ymm2,%zmm3
21dc: 62 f2 7d 48 25 ec vpmovsxdq %ymm4,%zmm5
21e2: 62 f2 7d 48 25 fe vpmovsxdq %ymm6,%zmm7
21e8: 62 b1 fd 48 7f 0c 52 vmovdqa64 %zmm1,(%rdx,%r10,2)
21ef: 62 52 7d 48 25 c8 vpmovsxdq %ymm8,%zmm9
21f5: 62 52 7d 48 25 da vpmovsxdq %ymm10,%zmm11
21fb: 62 b1 fd 48 7f 5c 52 vmovdqa64 %zmm3,0x40(%rdx,%r10,2)
2202: 01
2203: 62 52 7d 48 25 ec vpmovsxdq %ymm12,%zmm13
2209: 62 52 7d 48 25 fe vpmovsxdq %ymm14,%zmm15
220f: 49 81 c2 00 01 00 00 add $0x100,%r10
2216: 45 39 c3 cmp %r8d,%r11d
2219: 62 f1 fd 48 7f 2c 7a vmovdqa64 %zmm5,(%rdx,%rdi,2)
2220: 62 f1 fd 48 7f 7c 7a vmovdqa64 %zmm7,0x40(%rdx,%rdi,2)
2227: 01
2228: 62 71 fd 48 7f 0c 42 vmovdqa64 %zmm9,(%rdx,%rax,2)
222f: 62 71 fd 48 7f 5c 42 vmovdqa64 %zmm11,0x40(%rdx,%rax,2)
2236: 01
2237: 62 71 fd 48 7f 2c 72 vmovdqa64 %zmm13,(%rdx,%rsi,2)
223e: 62 71 fd 48 7f 7c 72 vmovdqa64 %zmm15,0x40(%rdx,%rsi,2)
И еще loop unrolling там есть, типа если на входе от нуля до 8, то прыгается прямо на нужное место, в котором развернут частный случай, а иначе оно кусками по 8 элементов фигачит. Это так потому что AVX512.
Современная сишечка меня пугает и завораживает одновременно.
Невозможно долго обманывать всех: systemd пишут скрипт-бои. blog.erratasec.com
Вот у меня есть функция, параметризуемая каким-то n, в ней есть цикл по n, и массив внутре есть.
я хочу наделать шаблонов(templates), для n от единицы до пяти, чтобы во время template instantiation это n становилось compile-time константой, а для остальных n пусть будет generic функция, в которой n будет переменной. А функцию я буду вызывать из switch/case соответственно разные специализации шаблона.
С шаблонами в принципе я уже тут кой-чо накидал, но все примеры нахожу только такие, что для специализаций по конкретному числу (от 1 до 5) тут можно написать везде свою реализацию, а для неспециализированной версии (остальных N) еще одну реализацию. Для меня же главное, чтобы КОД ФУНКЦИИ РЕЮЗАЛСЯ для специализированной и неспециализированной версии, то есть в одном случае n будет параметром шаблона, в другом параметром функции.
Может кто-то решал такую задачу, или есть идеи? Понимаю, что прямых путей нет, и еще, что все можно сделать препроцессором, но все-таки неохота препроцессором.
я хочу наделать шаблонов(templates), для n от единицы до пяти, чтобы во время template instantiation это n становилось compile-time константой, а для остальных n пусть будет generic функция, в которой n будет переменной. А функцию я буду вызывать из switch/case соответственно разные специализации шаблона.
С шаблонами в принципе я уже тут кой-чо накидал, но все примеры нахожу только такие, что для специализаций по конкретному числу (от 1 до 5) тут можно написать везде свою реализацию, а для неспециализированной версии (остальных N) еще одну реализацию. Для меня же главное, чтобы КОД ФУНКЦИИ РЕЮЗАЛСЯ для специализированной и неспециализированной версии, то есть в одном случае n будет параметром шаблона, в другом параметром функции.
Может кто-то решал такую задачу, или есть идеи? Понимаю, что прямых путей нет, и еще, что все можно сделать препроцессором, но все-таки неохота препроцессором.
Не векторизует гцц мои лупы, штук 5 разных, все не векторизует, пишет страшные логи.
Скачал интеловский конпелятор, ICC, тот тоже не векторизует, но логи пишет уже понятнее чуток, но все равно не могу понять почему нет.
for(int i=0; i<limit; i++, hs++,ls++,dda++) {
*dda=hm[*hs]*lo+((*ls)-slo);
}
вероятно просто не мой ворклоад? (avx512 enabled если шо). Ну и вероятно я просто не понимаю, ну и фиг с ним.
Скачал интеловский конпелятор, ICC, тот тоже не векторизует, но логи пишет уже понятнее чуток, но все равно не могу понять почему нет.
for(int i=0; i<limit; i++, hs++,ls++,dda++) {
*dda=hm[*hs]*lo+((*ls)-slo);
}
вероятно просто не мой ворклоад? (avx512 enabled если шо). Ну и вероятно я просто не понимаю, ну и фиг с ним.
А еще я ковырял ZFS vs ext4 на таком себе рейдике из 8 SSD, там трансфер суммарный за 4ГБ/сек переваливает на ext4, а вот ZFS максимум 1.5Г/сек выдавал, чисто чтение больших файлов.
Откровение: то, что тормозит на чтении 100000 мелких файлов на ext4 даже когда они все в буферах закешированы, тормозит так же точно и на рамдиске, если эти файлы туда засунуть. Директории в процессе не сканируются еслишо, прямо опен делается внутре.
cpu sys 12%, user 5% например (одно ядро)
С какого это бодуна?
cpu sys 12%, user 5% например (одно ядро)
С какого это бодуна?
*programming
Одолел на гейбуке FFMpeg, OpenGL, OpenCL, OpenCV, SDL и VideoToolbox hardware decoding, писал на плюсах.
Короче, FFMpeg через RTSP получает кусочек фрейма с IP камеры.
Затем это скармливается в VideoToolbox. Он мне в GPU дает буфер.
Потом это я из этого делаю OpenGL текстуру, из нее делаю OpenCL mem_obj.
Потом таки GPU->GPU копирую в OpenCV UMat (GPU-based матрицу) для алгоритмов всяческих.
Потом делаю алгоритмы
Потом стало быть беру из SDL тот SDL_Surface который рисую, и маплю его на другой mem_obj
Потом копирую из OpenCV матрицы (GPU->GPU) в етот surface/texture.
И потом тут же его рисую снова через SDL не вылазя в host RAM. Наверняка, если потрахаться с форматами текстуры, можно и не копировать, миллисекунду-другую выигрываешь.
Короче, выходит, что все быстро декодируется, весь процессинг и отображение происходит не покидая GPU, с дыркой куда вставить OpenCV/OpenCL вызовы для графических алгоритмов.
Все это дело занимает 7% CPU и чуток GPU на 25 кадрах Full HD, около 7 мсек на кадр выходит (в основном декодирование 5 мсек). У меня на гейбуке устроен Intel IRIS 6100, это подобие GPU.
Когда я стал затем прикручивать OpenCV процессинг на тамошних матрицах, оно занимает по 4-5 мсек на проход одной матрицы кернелом, просто чтобы хотя бы сложить 2 такие матрицы. Потому что Full HD и интел. А целиком весь мой задуманный процессинг получается 100 Мсек на кадр, потому что куча матричных операций. Это неинтересно. Полез смотреть как оно устроено, увидел там как выглядит голый OpenCL kernel (и не один), чей исходник они препроцессором допиливают под конкретные типы прежде чем запускать.
Решил, а чем мы хуже. Взял переписал весь свой алгоритм на OpenCL на тамошней сишечке, OpenCV предоставляет простой API. 18 миллисекунд на кадр, братие! Из говенного интела! Туда еще столько влезет!
Короче, прикольно-то как! Чувство глубокого удовлетворения.
Одолел на гейбуке FFMpeg, OpenGL, OpenCL, OpenCV, SDL и VideoToolbox hardware decoding, писал на плюсах.
Короче, FFMpeg через RTSP получает кусочек фрейма с IP камеры.
Затем это скармливается в VideoToolbox. Он мне в GPU дает буфер.
Потом это я из этого делаю OpenGL текстуру, из нее делаю OpenCL mem_obj.
Потом таки GPU->GPU копирую в OpenCV UMat (GPU-based матрицу) для алгоритмов всяческих.
Потом делаю алгоритмы
Потом стало быть беру из SDL тот SDL_Surface который рисую, и маплю его на другой mem_obj
Потом копирую из OpenCV матрицы (GPU->GPU) в етот surface/texture.
И потом тут же его рисую снова через SDL не вылазя в host RAM. Наверняка, если потрахаться с форматами текстуры, можно и не копировать, миллисекунду-другую выигрываешь.
Короче, выходит, что все быстро декодируется, весь процессинг и отображение происходит не покидая GPU, с дыркой куда вставить OpenCV/OpenCL вызовы для графических алгоритмов.
Все это дело занимает 7% CPU и чуток GPU на 25 кадрах Full HD, около 7 мсек на кадр выходит (в основном декодирование 5 мсек). У меня на гейбуке устроен Intel IRIS 6100, это подобие GPU.
Когда я стал затем прикручивать OpenCV процессинг на тамошних матрицах, оно занимает по 4-5 мсек на проход одной матрицы кернелом, просто чтобы хотя бы сложить 2 такие матрицы. Потому что Full HD и интел. А целиком весь мой задуманный процессинг получается 100 Мсек на кадр, потому что куча матричных операций. Это неинтересно. Полез смотреть как оно устроено, увидел там как выглядит голый OpenCL kernel (и не один), чей исходник они препроцессором допиливают под конкретные типы прежде чем запускать.
Решил, а чем мы хуже. Взял переписал весь свой алгоритм на OpenCL на тамошней сишечке, OpenCV предоставляет простой API. 18 миллисекунд на кадр, братие! Из говенного интела! Туда еще столько влезет!
Короче, прикольно-то как! Чувство глубокого удовлетворения.
