Мой сборщик и флешер

[pvvx]

Простите за не скромный вопрос.
В чем преимущество или удобство для сборки, если используешь различные пОрты такие как mingw или WSL ubuntu?
Чем так плох гнутый линукс?

Там нет Visual Studio и прочего хлама, да всё что производиться программного потребляется потребителями на Windows.
Как факт - все процессоры Ryzen у AMD идут с браком - не работают с GCC в Linux. Но это такой малый сегмент пользователей (менее 1%), что AMD не отзывает их и походу даже не собирается разбираться с причиной ошибки там (моё мнение - ошибки в ПО GCC Linux, которые старательно теперь выдают за глюки CPU. На других процах тоже имеются сбои при больших сборках на много потоков в GCC уже много лет.).
В WSL проще, чем в виртуалке. Ничего "пробрасывать" не надо и работают любые *.exe совместно с linux утилитами (хоть в одном sh, make и т.д.).

 

[pvvx]

и тут многопоточность ускоряет в 2 раза, но по сравнению с HDD в 3 раза быстрей

Т.е. 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, может стоит попробовать (если не жалко времени )

 

[pvvx]

но почему-то ramdisk не рассматривался

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)):

Спойлер: Ryzen7 1700x RamDisk

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-е успешно работает кэширование дисков.

 

[Алексей.]

Ерунда какая то, msdn говорит что поддерживают реально, а не мапят на hdd.
а как смонтировался сам /mnt/tmpfs
mount | grep '/mnt/tmpfs'
что говорит?

 

[pvvx]

Ерунда какая то, msdn говорит что поддерживают реально, а не мапят на hdd.
а как смонтировался сам /mnt/tmpfs
mount | grep '/mnt/tmpfs'
что говорит?

Что не понятно? 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 на диске.
Не понятно почему нет прироста в производительности.

 

[pvvx]

TmpFs и псевдо-фс в памяти, VolFs и DrvFs на диске.
Не понятно почему нет прироста в производительности.

Как это нет - 50% есть.
Остальное уходит на системные вызовы у GCC и всякую кривописанную фигню. Наверно просто задержек в GCC понаставили
Даже тест, который якобы вызывает ошибки у Ryzen7 при длительной нагрузке в Linux не может загрузить его на 100%. И падает по причине кривописи по привилегиям процессов и нарушения последовательности исполнения в самой GCC vs Linux. Там даже контроль питания мамки говорит что нагрузка не более 30% от номинального TDP.
У WSL ещё хуже с атрибутами файлов и прочими расстановками разрешений. Но она пока ещё в стадии беты Там тоже часто есть сбои на вполне работавших ранее прогр