| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| Distributed cross-compilation http://mcu-bg.com/mcu_site/viewtopic.php?f=14&t=18096 |
Страница 1 от 1 |
| Автор: | HCL [ Чет Ное 11, 2021 9:15 pm ] |
| Заглавие: | Distributed cross-compilation |
Или иначе казано как бихте ускорили компилирането на масивен ембедед проект (как звучи само) върху линукс клъстер? Предполагам bazel и distcc няма да имат някакви трудности с GNU toolchain-a. Дали ще е ARM или х86 би трябвало да им е все едно, или? А някакви надеждни гледна точка на сигурността cloud услуги в тази насока? |
|
| Автор: | gicho [ Чет Ное 11, 2021 9:35 pm ] |
| Заглавие: | Re: Distributed cross-compilation |
Incredibuild? Не знам колко е голям проекта, за който говориш, но има бенчове за билдване на големи проекти на яки машини - https://openbenchmarking.org/test/pts/build-gcc Има и разни 128 ядрени машини сега. Но е примамливо да изчешеш няколко десетки дремещи i7-ци да чукулят по кода. Въпросът е че при умерено големи проекти овърхеда от мрежата ще почне да влияе. Отделно зависимостите вътре в проекта няма как да се прескочат. Друга посока за "инвестиране" е изчистване на билд процеса - на теория, инкременалния билд трябва да успее да поеме капацитета за бълване на код на малко индийско градче... Мога силно да препоръчам "tup build" поне като идеология. |
|
| Автор: | HCL [ Чет Ное 11, 2021 10:19 pm ] |
| Заглавие: | Re: Distributed cross-compilation |
Маке инкрементални билдове са единственото, което бях виждал досега, но когато компилацията за дневната регресия въпректи това стигне половин час не е оптимално. Но може и да има проблем в зависимостите, прав си. Това трябва да се провери на първо място. |
|
| Автор: | gicho [ Пет Ное 12, 2021 9:53 pm ] |
| Заглавие: | Re: Distributed cross-compilation |
Make е класика, но има много алтернативи. За мен най-доброто е този "tup build" - http://gittup.org/tup/ - не е много за учене, но да се мигрира към него голям наличен проект е силно нереалистично. Аз съм го ползвал за дребни проектчета, и то по-скоро на ниво експерименти. Всъщност освен големината на проектите, размера на екипа може да е голям проблем - трудно се прокарват такива промени. Всички обичат да вдигнат краката на масата и да кажат "чакам да се компилира". Якото на туп-а е че водещата им цел е безкомпромисно точен билд - в смисъл детекция на промените и следене на зависимостите. Феноменално бързите инкрементални билдове са "страничен ефект" ... Колкото до скоростта - модерна машина (5950x - 16 ядра/32 треда) мачка пълен билд на кърнела на линукс за минута. Това е за 1.5К евро. За няколко пъти отгоре може да се свали наполовина - ако има кой да инвестира. И не е необходимо да се бориш с дистрибуция на билда. Приличен фирмуер за ембедед устройство дето излиза 500К бинари го мачка за 2 секунди - пълен ребилд. Други проекти не успяват да се забързат толкова - хвърчи първите 100-тина файла и запецва за 5-6 секунди - идва един голям дейта C файл, дето е нужен за останалите файлове... Ако се поработи и върху сториджа (на горната машина е екпрес 4.0 самсунг 980 про) може би ще стане още по-добре - не съм изследвал много, но поне визуално според htop-а 32-те треда си стоят пълни през цялото време. В тая машина ссд-тата са 2 броя, ама засега не ми се занимава със второто (предвид резулататите с едно). Другото, което може да помогне, е ccache - никога не съм го ползвал в мои проекти, но често е идвал с външни такива - примерно yocto и buildroot bsp-та. |
|
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|