Re: Deep learning development stick for embedded AI applicat
Не знам дали някой се е замислял какъв процент от кода в едно устройство, било то и ембедед, има някаква зависимост от хардуер. Имам предвид че има един слой на обслужване на хардуера, да го кажем HAL, и оттам насетне има вече подготвени/типизирани данни и изчислителни алгоритми, протоколи и други хардуерно незасивими слоеве. Ако видя накой в примерно в модбъс протокола да слага арм или пик специфични неща направо е на борсата.
Всички опити да се оправдаят разни мазаници в кода с това че на еди кой си хардуер така ще е по-добре са индикация на неправилно разпределение на задачите и непознаване на проблемите.
А там където свършва I/O-то и почва приложението е логично да търсиш удобен начин да изразиш идеите си - т.е. език и стил в който да пишеш малко а да казваш много. Там C/C++ все още куцат и искат още работа, но май е мисия невъзможна без счупване на обратната съвсемстимост. Питон, JS, arduino - все примери как се прави по-изразителен език, при който не само че тракаш по-малко по клавиатурата, ами по-лесно променят (рефакторираш), както и все по-малко се месиш на компилатора/интерпретатора/рънтайма да прецени как най-добре да свърши нещо. Докато на C все още ползването на for е по-често от обхождане на списък (поради липсата на такъв в стандарната библиотека примерно).
В питон/js работата с данните е по-лесна, ясна, изразителна и води до по-малко бъгове. В зависимост от реализациата на интерпретатора може да има забавяне в изпълнението, ама може и да няма - щото един на C обикаля масива от 0 до MAX_ITEMS, което примерно е 1024, докато на другия език някой ползва свързан списък и обхожда активните към момента 3 нода, вместо 1024.
За пример да кажем че на питон съм ползвал map(fn, list) за да обработя тия 1024 елемента, на C си е пак фор до 1024. И да кажем че и 1024-те вече са активни. На 8-кора/16 треда питона спокойно може да сцепи 1024 на 16 зони по 64 елемента и ги пуска на отделните ядра, На C 15 ядра спят/бичат фейсбук, а едното дъни последователно 1024 елемента...
И ако обработката от ниско ниво на един от тия елементи примерно е на C, т.е. питоня я ползва компилирана, не знам дали C няма да пуши нервно в ъгъла...
Точно в подобен стил е смисълът на "скриптирането" на разните големи приложения - да можеш лесно да накараш аутокада да извърти и обработи 1024 детайла, описани в едно csv примерно. Там потребителят не иска да се бори с ansi c за да си парсира csv или json, че да извърти един фор - предпочита нещо в стила на foreach най-малкото. Със сигурност обработката им ще е по-бърза, ако писачите на аутокада вкарат меню "csv/json to render" или нещо такова, в смисъл да кодират точно use case-а на тоя потребител. Само дето едното ще го направи стажант на половин работен ден, а другото ... няма да се случи щото само времето да ти дадат quote колко ще искат няма да можеш да си го позволиш.
Не бива да се оценяват езиците само по това какво е постигнато в съществуващите интерпретатори, а доколко самия синтаксис на езика позволява в бъдеще един по-качествен интерпретатор или що не компилатор да разбере смисъла на писанията и да генерира ефективен код. Т.е. до колко всички аспекти на задачата имат формално описание в сорс кода. При Си обикновено трябва една хубава камара документация, за да може някой да разбере какво прави тоя код. При питонЯ и js според мен има дупка в смисъла на липсата на типове - което е решено в typescript примерно. И нямам предвид на всеки ред да трябва да пишеш типове - силните езици има "магическата сила" да проследяват йерархията на типовете, предаването на данни и викане на функции и да се усещат сами какво е това, дето се движи по веригата и къде се опитваш да шмекериш. Там типовете се описват по-детайлно, но само веднъж.
Всъщност не съм се ровил дали някой не е направил "питон с типове"?
В тая посока rust се опитва да покрие голяма част от аспектите на проблема. Другото са чисто функционалните езици.
Представи си своето приложение като библиотека, която се опитваш да продадеш - т.е. колкото повече потребители я ползват, толкова по-добре? Не смяташ ли че от маркетингова гледна точка ще е ценно да кажеш че твоето приложение може да се командва от питон/js през скриптинг интерфейс?
То това няма общо с питон или Си дебат - много от качествените опън сорс проекти на Си се предлагат като библиотека и приложение - обикновено приложението е съвсем прост wrapper който вика библиотеката.