Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Простите за не скромный вопрос.
В чем преимущество или удобство для сборки, если используешь различные пОрты такие как 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...
