Простите за не скромный вопрос.
В чем преимущество или удобство для сборки, если используешь различные пОрты такие как mingw или WSL ubuntu?
Чем так плох гнутый линукс?
Там нет Visual Studio и прочего хлама, да всё что производиться программного потребляется потребителями на Windows.
Как факт - все процессоры Ryzen у AMD идут с браком - не работают с GCC в Linux. Но это такой малый сегмент пользователей (менее 1%), что AMD не отзывает их и походу даже не собирается разбираться с причиной ошибки там (моё мнение - ошибки в ПО GCC Linux, которые старательно теперь выдают за глюки CPU. На других процах тоже имеются сбои при больших сборках на много потоков в GCC уже много лет.).
В WSL проще, чем в виртуалке. Ничего "пробрасывать" не надо и работают любые *.exe совместно с linux утилитами (хоть в одном sh, make и т.д.).
Т.е. Linux не умеет пользовать кеш диска в RAM? Отложенная запись и всё такое...
Пробовал на m.2 PCIE x4 с трафиком 2.4Gbytes/sec запись-чтение - всё те-же единицы выходят.
(До около 10 секунд сборки MP3 на RTL"A" и базовой "AT" на RTL"B")
Arduino ещё не ставил... да и не выбрал что будет базовым компом (Ryzen7 или Threadripper)
В тестах участвовали
1. ubuntu 16.04 + HDD
2. ubuntu 16.04 SSD btrfs + lzo
но почему-то ramdisk не рассматривался,
я к сожалению быстро не нашел сравнений производительности SSD btrfs и tmpfs, может на ram-е быстрее получится?
видел кучу статей как снять нагрузку с SSD увеличить производительности за счет кеширования на ram-e, может стоит попробовать (если не жалко времени )
tmpfs в Win10 WSL ставится так Виртуальный диск в памяти: как создать ramdisk в Linux? - Записки дебианщика
Копируем туда SDK и все остальное...
Создаем configure.sh: python waf configure
и build.sh: time python waf -j 32 clean
time python waf -j 32 build
и запускаем его из build.cmd хоть из эксплорера : bash configure.sh bash build.sh
pause
Получаем (Ryzen 7 1700X, чипсет X370, RAM: Dual DDR4-3017 14-15-15-34 CR1, разгонов нет, все установки в Биос - Auto,
Win10 WSL, проект RTL MP3, arm-none-eabi-gcc (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)):
Код:
user@Ryzen1700x:/mnt/tmpfs/magres-wafmeba$ ./configure.sh
invalid lock file in /mnt/tmpfs/magres-wafmeba
Setting top to : /mnt/tmpfs/magres-wafmeba
Setting out to : /mnt/tmpfs/magres-wafmeba/build
arm-none-eabi-gcc is not in env or doesn't exists
Checking for program 'arm-none-eabi-gcc' : /usr/bin/arm-none-eabi-gcc
arm-none-eabi-nm is not in env or doesn't exists
Checking for program 'arm-none-eabi-nm' : /usr/bin/arm-none-eabi-nm
arm-none-eabi-objcopy is not in env or doesn't exists
Checking for program 'arm-none-eabi-objcopy' : /usr/bin/arm-none-eabi-objcopy
'configure' finished successfully (0.020s)
user@Ryzen1700x:/mnt/tmpfs/magres-wafmeba$ ./build.sh
__INCLUDES : ../inc not found
'clean' finished successfully (0.259s)
real 0m0.518s
user 0m0.109s
sys 0m0.375s
Waf: Entering directory `/mnt/tmpfs/magres-wafmeba/build'
__INCLUDES : ../inc not found
[ 1/162] Compiling project/src/user/main.c
[ 2/162] Compiling project/src/user/wifi_console.c
[ 3/162] Compiling project/src/user/atcmd_user.c
[ 4/162] Compiling project/src/user/spiram_fifo.c
[ 5/162] Compiling project/src/mad/mad_version.c
[ 6/162] Compiling project/src/mad/mpg12/layer12.c
[ 7/162] Compiling project/src/mad/frame.c
[ 8/162] Compiling project/src/mad/layer3.c
[ 9/162] Compiling project/src/mad/align.c
[ 10/162] Compiling project/src/mad/decoder.c
[ 11/162] Compiling project/src/mad/huffman.c
[ 12/162] Compiling project/src/mad/fixed.c
[ 13/162] Compiling project/src/mad/bit.c
[ 14/162] Compiling project/src/mad/synth.c
[ 15/162] Compiling project/src/mad/timer.c
[ 16/162] Compiling project/src/mad/stream.c
[ 17/162] Compiling project/src/driver/i2s_freertos.c
[ 18/162] Compiling RTL00_SDKV35a/component/soc/realtek/8195a/fwlib/ram_lib/rtl_bios_data.c
.....
[150/162] Processing ameba_ld: build/project/src/user/main.o build/project/src/user/wifi_console.o build/project/src/user/atcmd_user.o build/project/src/user/spiram_fifo.o
.....
build/RTL00_SDKV35a/component/soc/realtek/8195a/fwlib/ram_lib/rtl_boot.o -> build/app.axf
[151/162] Compiling build/app.axf
[152/162] Compiling build/app.axf
[153/162] Compiling build/app.axf
[154/162] Compiling build/app.axf
[155/162] Compiling build/app.axf
[156/162] Compiling build/sdram.bin.raw
[157/162] Compiling build/ram_2.ota.bin.raw
[158/162] Compiling build/ram_1.bin.raw
[159/162] Compiling build/ram_2.bin.raw
[160/162] Compiling build/ram_1.bin
[161/162] Processing ameba_combine_task: build/ram_2.ota.bin build/sdram.bin -> build/ram_ota.bin
[162/162] Processing ameba_combine_task: build/ram_1.bin.padded build/ram_2.bin build/sdram.bin -> build/ram_all.bin
Waf: Leaving directory `/mnt/tmpfs/magres-wafmeba/build'
'build' finished successfully (5.323s)
real 0m5.592s
user 0m4.359s
sys 0m0.734s
Т.е. вместо 10 +- 1 сек на HDD (или NVMe) выходит 5+ сек + время копирования с m.2 PCIE x4 на скорости к 2 GB/sec. Средняя загрузка проца при сборке ~50%. Антивирусы и другие активные приложения пачками в системе дают тормоз этому делу до 5..7%.
WSL в Win10 сама медлительнее оригинального Linux, но серьезного выигрыша с ramdisk не выходит - его надо записывать и сохранять, писать всякое...
Т.е. могло бы быстрее, но что-то там не так в GCC и 180 Ваттный Ryzen за сотню тыр.руб тоже не ускоряет, относительно простого Ryzen7 1700X за малую цену... Разницы между NVMe на PCIE с древним HDD WD20EARS тоже нет - все вокруг 10+-1 сек и загрузка CPU к 50%. Не научили ещё системы загружать NVMe на полный трафик... и в wind-е успешно работает кэширование дисков.
Что не понятно? WSL транслирует запросы к драйверам windows. Всё что идет аппаратно в nix - нафиг.
Вся система linux/ubuntu то в NTFS, в папочке X:\Users\ИмяПользователя\Local Settings\Packages\CanonicalGroupLimited.UbuntuonWindows_xxxxxxx\LocalState\rootfs.
А когда в RAM в tmpfs - то ей винда выделяет кусок памяти и ubuntu там сама копошиться как хочет. От этого немного быстрее запросы туда в ней.
Писано же Микромягкими про WSL - это не виртуалка, а транслятор запросов.
Кому сдалась ещё одна виртуальная машина со своей песочницей? Их и так много для wind-ы.
Или вам не ясно как работает кэширование дисков в windows? Что неиспользуемая RAM используется для кэша дисков и операции с дисками всего в пару раз медленнее чем с RAM (т.к. надо время на разбор с самой организацией файловой структуры)?
Что не понятно? WSL транслирует запросы к драйверам windows. Всё что идет аппаратно в nix - нафиг.
Вся система linux/ubuntu то в NTFS, в папочке X:\Users\ИмяПользователя\Local Settings\Packages\CanonicalGroupLimited.UbuntuonWindows_xxxxxxx\LocalState\rootfs.
Да при чем тут это, я хотел просто узнать как смонтировался /mnt/tmpfs
я смонтировал рам-диск в 1G и замапил как у Вас на /mnt/tmpfs
и просил только вывести mount | grep '/mnt/tmpfs'
ожидал увидеть tmpfs on /mnt/tmpfs type tmpfs (rw,relatime,size=1048576k)
если это так, то как понимать wsl-file-system-support ведь говорят
VFS defines several file system plugins: VolFs and DrvFs are used to represent files on disk, and the remainder are the in-memory file system TmpFs and pseudo file systems such as ProcFs, SysFs, and CgroupFs.
русским по белому TmpFs и псевдо-фс в памяти, VolFs и DrvFs на диске.
Не понятно почему нет прироста в производительности.
Как это нет - 50% есть.
Остальное уходит на системные вызовы у GCC и всякую кривописанную фигню. Наверно просто задержек в GCC понаставили
Даже тест, который якобы вызывает ошибки у Ryzen7 при длительной нагрузке в Linux не может загрузить его на 100%. И падает по причине кривописи по привилегиям процессов и нарушения последовательности исполнения в самой GCC vs Linux. Там даже контроль питания мамки говорит что нагрузка не более 30% от номинального TDP.
У WSL ещё хуже с атрибутами файлов и прочими расстановками разрешений. Но она пока ещё в стадии беты Там тоже часто есть сбои на вполне работавших ранее программах от Linux в начале, после загрузки. Проходит со временем, видимо после каких-то манипуляций с системой WSL... Вполне это всё может оказаться из-за кривизны дров NVMe и дисков в самой windows для систем Ryzen...
Для Linux про это и говорить пока не о чем - там ещё старые подходы и дрова...
В общем, для "многоядер" пока всё сыро... "на своей шкуре" = испытание на пользователях, и т.д.
Это устаревшее описание для бета версии WSL начала года.
Win10 после этого уже обновилась, совместно с WSL. По общему смыслу совпадает, но частности другие...
видимо зорг лукавит и выдает желаемое за действительное
я проверял на обычном 4ядерном ноутбучном цпу, результаты выше.
а в ваши скрипты и ваши 100500 ядерники лезть не буду
видимо зорг лукавит и выдает желаемое за действительное
я проверял на обычном 4ядерном ноутбучном цпу, результаты выше.
а в ваши скрипты и ваши 100500 ядерники лезть не буду
А зачем мне что-то выдумывать (?) - могу дать все исходные файлы маке с SDK4.0 для "B" серии и сами убедитесь (это не сикретно ). Я тут выбираю какой комп будет основным дома и на какую концепцию переходить... Говорят надо на VS 2017. Вот счас запустил сборку на ней arm-none-eabi-... в среде WSL... Надо ещё попробовать как будет дружить Eclipse с WSL.
Последние результаты на подгруженном всякими антивирусами и мониторами Ryzen1700x в WSL в tmpfs выходят:
На маке - 5..5.5 сек
На Waf - 6.1..6.5 сек.
Waf-у не запустить 32 потока (по умолчанию у него 16)? Или что там у него?
Могу дать табличку сравнений с 16 по 128 протоков... 32 выходит оптимальнее.
И где у вас результат выше? Сами пишите 14 сек. Проекты практически одинаковы, в "AT" серии "B" файлов больше - там трансляция SSL либы и всей помойки SDK.
Вы думаете на этом будет сильно быстрее? Процессор Qualcomm Centriq 2400: 48 ядер, 18 млрд транзисторов, частота 2,6 ГГц и TDP в 120 Вт
Для меня пока выбор определяется экономичностью и бесшумностью совместно с производительностью, т.к. он будет работать непрерывно. И к "энтузиастам" для закупки самых крутых комплектующих в комп - фанатам 3D игр не отношусь, возраст наверно уже не тот
@Neov - что подскажите? :
Запускаем bash и в нем [inline]time python waf build[/inline], получаем сплошные ошибки:
Код:
user@wsl:/mnt/c/00/magres-wafmeba$ time python waf build
Waf: Entering directory `/mnt/c/00/magres-wafmeba/build'
[ 1/162] Compiling project/src/user/main.c
[ 2/162] Compiling project/src/user/wifi_console.c
[ 3/162] Compiling project/src/user/atcmd_user.c
[ 4/162] Compiling project/src/user/spiram_fifo.c
[ 5/162] Compiling project/src/mad/mad_version.c
In file included from /mnt/c/00/magres-wafmeba/project/src/user/atcmd_user.c:5:0:
/mnt/c/00/magres-wafmeba/RTL00_SDKV35a/component/os/freertos/freertos_v9.0.0/source/include/FreeRTOS.h:76:20: fatal error: /mnt/c/00/magres-wafmeba/RTL00_SDKV35a/component/common/api/wifi/rtw_wpa_supplicant/src/stddef.h: Invalid argument
#include <stddef.h>
^
compilation terminated.
и так далее.... стерто - слишком много ошибок
и такие ошибки:
/usr/include/newlib/stdint.h:64:19: error: missing binary operator before token "("
#elif __STDINT_EXP(INT_MAX) >= 0x7fff
^
In file included from /mnt/c/00/magres-wafmeba/RTL00_SDKV35a/component/soc/realtek/8195a/misc/rtl_std_lib/include/rt_lib_rom.h:12:0,
from /mnt/c/00/magres-wafmeba/RTL00_SDKV35a/component/common/api/platform/platform_stdlib.h:23,
from /mnt/c/00/magres-wafmeba/project/inc/mad/global.h:54,
from /mnt/c/00/magres-wafmeba/project/src/mad/mad_version.c:26:
/mnt/c/00/magres-wafmeba/RTL00_SDKV35a/component/soc/realtek/8195a/cmsis/device/diag.h:16:37: fatal error: /mnt/c/00/magres-wafmeba/RTL00_SDKV35a/component/common/mbed/api/stddef.h: Invalid argument
#include <stddef.h> /* for size_t */
^
compilation terminated.
Итог понятен:
Build failed
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/user/atcmd_user.o'
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/user/wifi_console.o'
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/mad/mad_version.o'
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/mad/frame.o'
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/user/main.o'
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/user/spiram_fifo.o'
-> missing file: '/mnt/c/00/magres-wafmeba/build/project/src/mad/mpg12/layer12.o'
real 0m1.117s
user 0m0.391s
sys 0m0.609s
Не хочет - одни ошибки.
Тогда запускаем так: [inline]time python waf -j 1 build[/inline], всё собирается:
Код:
user@wsl:/mnt/c/00/magres-wafmeba$ time python waf -j 1 build
Waf: Entering directory `/mnt/c/00/magres-wafmeba/build'
[ 1/162] Compiling project/src/user/main.c
[ 2/162] Compiling project/src/user/wifi_console.c
... Тут часть стерта, чтобы влезло в сообщение - ошибок нет ...
[151/162] Compiling build/app.axf
[152/162] Compiling build/app.axf
[153/162] Compiling build/ram_1.bin.raw
[154/162] Compiling build/app.axf
[155/162] Compiling build/ram_2.bin.raw
[156/162] Compiling build/app.axf
[157/162] Compiling build/ram_2.ota.bin.raw
[158/162] Compiling build/app.axf
[159/162] Compiling build/sdram.bin.raw
[160/162] Compiling build/ram_1.bin
[161/162] Processing ameba_combine_task: build/ram_1.bin.padded build/ram_2.bin build/sdram.bin -> build/ram_all.bin
[162/162] Processing ameba_combine_task: build/ram_2.ota.bin build/sdram.bin -> build/ram_ota.bin
Waf: Leaving directory `/mnt/c/00/magres-wafmeba/build'
'build' finished successfully (53.582s)
real 0m53.682s
user 0m3.203s
sys 0m1.109s
Если скопировать все файлы SDK в среде WSL в новую директорию, то сборка в режиме нескольких потоков (-j 32) проходит.
По этой причине есть намек Do not change Linux files using Windows apps and tools
Что можете подсказать, что-бы waf заработал в WSL в Win10x64 ?
Проблема кажется схожей с ошибками в Linux с gcc у Ryzen CPU, т.к. никто из Linux так и не взялся за получение доп. документации (c NDA?) на проц от AMD, кроме Microsoft Windows (в ней расписанных на многих сайтах ошибок с Ryzen нет). Но описанное здесь странное поведение gcc, проявляется на любом CPU в среде WSL c программами от ubuntu...
