Challenge - Výpis času

peterple
Příspěvky: 50
Registrován: 22 zář 2021, 20:20
Reputation: 0

Re: Challenge

Příspěvek od peterple » 24 lis 2021, 22:43

Ja som ho len ohodnotil z môjho pohľadu. Vracať hodnoty vo funkcii je samozrejme OK. Lenže ak sú to objekty tak to koštuje pamäť a čas, lebo sa to musí kopírovať. Ak ti ani jedno nerobí problém nech sa páči. Ak máš CPU so 4kiBy tak už máš problém s pamäťou.

Či použiješ += alebo concat je v podstate fuk. v prípade AVR to vedie na to isté
https://github.com/arduino/ArduinoCore- ... String.cpp

Kód: Vybrat vše

StringSumHelper & operator + (const StringSumHelper &lhs, const String &rhs)
{
	StringSumHelper &a = const_cast<StringSumHelper&>(lhs);
	if (!a.concat(rhs.buffer, rhs.len)) a.invalidate();
	return a;
}
Je to len taký syntaxický cukor. Pri ESP to robia funciou insert čo je inak pomenovaná concat
https://github.com/esp8266/Arduino/blob ... String.cpp

To či použiješ makro F(" ") alebo nie má zase hovadský význam ak budeš mať AVR s 4kiBy SRAM.

Ak myslíš vyžitím pamäte to čo píše kompiler na konci tak macro F by si pocítiť mal. V mojej funkcii to bolo 12 byte dole z globálnej alokácie. To čo sa deje na heape tam samozrejme vidieť nie je. A to je ten problém. Ak nevieš ako heap pracuje tak si myslím že je to časovaná bomba

toľkoto o tom píšu napríklad v MISRA
The use of dynamic memory can lead to out-of-storage run-time failures, which are undesirable.

The built-in new and delete operators, other than the placement versions, use dynamic heap memory. The functions calloc, malloc, realloc and free also use dynamic heap memory.

There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap memory allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-deterministic behaviour, etc.

Note that some implementations may use dynamic heap memory allocation to implement other functions (for example, functions in the library cstring). If this is the case, then these functions shall also be avoided.
Tiež nie som programátor. Programujem síce od 15 rokov ale nikdy som sa tým profesionálne neživil. Našťastie. Inak by som bol dnes asi totálne vyhoretý. Ale zase na druhej strane ma zaujíma ako to pracuje úplne na najnižšej úrovni.

Caster
Příspěvky: 207
Registrován: 11 zář 2019, 09:02
Reputation: 0

Re: Challenge

Příspěvek od Caster » 25 lis 2021, 09:35

Při optimalizaci programů by měla být jedním z hlavních kritérií velikost programu tj. kolik bytů zabírá program a kolik bytů data ;) .

jankop
Příspěvky: 880
Registrován: 06 zář 2017, 20:04
Reputation: 0
Bydliště: Brno
Kontaktovat uživatele:

Re: Challenge

Příspěvek od jankop » 25 lis 2021, 11:10

Rozhodně nesouhlasím. Když budeš dělat FFT analýzu v reálném čase, potřebuješ rychlost a velikost programu není hlavním kritériem. Optimalizovat můžeš program i na "blbuvzdornost" apod. A velikost paměti pro data je taky ošemetná, protože lokální proměnné se často mění dynamicky. Když jsem si koupil svůj první počítač, tak ten měl 1kB paměti a ta sloužila zároveň jako videopaměť. Jak člověk psal program, tak VRAM postupně ubývala. V tomto případě tvoje kritérium optimalizace bylo hodně aktuální. :D

Uživatelský avatar
kiRRow
Příspěvky: 710
Registrován: 07 kvě 2019, 07:03
Reputation: 0
Bydliště: Opava

Re: Challenge - Výpis času

Příspěvek od kiRRow » 25 lis 2021, 11:47

Dovolil jsem si to rozdělit - menší chybka se vloudila, tak snad jsem to dokonal správně.

Uživatelský avatar
kiRRow
Příspěvky: 710
Registrován: 07 kvě 2019, 07:03
Reputation: 0
Bydliště: Opava

Re: Challenge - Výpis času

Příspěvek od kiRRow » 25 lis 2021, 12:04

nejsem u arduina, ale když to tak vemu a popřemýšlím o tom ...
v podstatě chceme objekt dejme tomu lifeTime , který po zavolání metody getStringTime provede svou privátní metodu update, při které nejprve překontroluje, zda není millis menší než poslední čas, pokud ne - vypočte rozdíl na čas a uloží si ho do své paměti, pokud ano - je millis přeteklý tzn od největšího možného unsigned long odečtu poslední čas a přičtu millis a tím jsem ošetřil přetečení. Pak už je jen třeba obsah vnitřní paměti vrátit jako String formátu d:hh:mm:ss - chápu to správně ?

Uživatelský avatar
kiRRow
Příspěvky: 710
Registrován: 07 kvě 2019, 07:03
Reputation: 0
Bydliště: Opava

Re: Challenge - Výpis času

Příspěvek od kiRRow » 25 lis 2021, 14:02

Globální versus Lokální proměnné - věčný souboj názorů atd.

Můj názor je takový : Obojí existuje, protože obojí má svůj význam a uplatnění. Obojí by se tedy mělo používat. Otázkou je kdy a jak je to správně.

Globální proměnné mají výhodu v tom, že jsou pevně na svém místě v paměti. Díky tomu je umí kompilátor naskládat za sebe,do sebe a přes sebe skoro jako tetris. Nevýhoda je v tom, že kdokoliv odkudkoliv může tuto proměnnou přepsat a tím způsobit havárii programu. Pokud jsem tvůrcem pouze já sám, tak se dá tato záležitost velmi lehce ohlídat.

Lokální proměnné mají výhodu v tom, že existují jen po určitou dobu. Zabírají si jakékoliv dostatečně dlouhé a spojité!! místo hned po globálních proměnných. V tom je právě občas kámen úrazu. Člověk ztrácí kontrolu nad tím, co kde je umístěno v paměti a může dojít k rozfragmentování paměti. Mám sice volno 50%, ale ty jsou rozkouskovány tak, že co druhý volný bajt přes celou paměť a nikde nejsem schopen lokálně vytvořit float. Vytvořím obrovský string, zapíšu si nějaký int1, vymažu obrovský string, zapíšu si nějaký int2, pokud znovu založím obrovský string začne zabírat místo až za int1, protože se mezi ně už nevleze - a může nabourat do dat ve "spodní části" paměti a tam si program ukládá na které adrese byl, než odskočil dělat nějakou rutinu. Prostě lepší mít v programu napevno vybrán kus paměti přesně jen pro tento obrovský string. Samozřejmě mít pro každý cyklus v programu svou globální proměnou je totálně na palici.

A objekty. Ty si jasně ukousnou kus paměti pro své globální proměnné v momentě kdy je zavolán konstruktor, uvolní ji až po zavolání destruktoru a zabírají ji po celou dobu existence a ještě k tomu žerou další paměť lokálními proměnnými jednotlivých metod. Jejich velkou výhodou je schopnost bránit si svá vnitřní data a své vnitřní metody před ostatními programátory. Další velkou výhodou je že více instancí objektů jedné třídy se dělí v metodě o jeden kus kódu, jenom do něj vkládají jiná data. Nevýhodou je delší časová náročnost.

Mno a o tom tak nějak to amatérské programování je. Analýza, návrh řešení, realizace, chyba, analýza, návrh řešení, realizace ....
Optimalizace je o nalezení zlaté střední cesty. Mít co nejmenší program a nechat 95% volné paměti na úkor výpočetního času dle mne není optimální. Ta paměť tam je, proč ji nepoužít.
Někdy ani není možné něco optimalizovat pro všechny. Je třeba mít pak více optimálních verzí pro konkrétní účely.

Odpovědět

Kdo je online

Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 2 hosti