Ctrl4Dkn: ESP32 (Floor) Heat Controller With Daikin (Heatpump) Support - https://github.com/arnova/ctrl4dkn
Verwijderd
Je zal nooit het onderste uit de kan halen met zo'n standaard kernel.
Die heeft gewoon geen ondersteuning voor instructies zoals SSE2 etc.
Waarom maak je niet gewoon een aantal configs met als enige variabele het CPU type?
Je moet dan alsnog X keer compilen, maar de 2e, 3e, 4e etc keer zal een stuk sneller gaan omdat je niet alle files opnieuw compiled. (alhoewel ik dat niet zeker weet als je het CPU type aanpast.
)
Die heeft gewoon geen ondersteuning voor instructies zoals SSE2 etc.
Waarom maak je niet gewoon een aantal configs met als enige variabele het CPU type?
Je moet dan alsnog X keer compilen, maar de 2e, 3e, 4e etc keer zal een stuk sneller gaan omdat je niet alle files opnieuw compiled. (alhoewel ik dat niet zeker weet als je het CPU type aanpast.
)
Dit is pure gemakzucht. En 1 kernel vind ik op zich goed genoeg, ik hoef niet het onderste uit de kan te hebben.:
Je zal nooit het onderste uit de kan halen met zo'n standaard kernel.
Die heeft gewoon geen ondersteuning voor instructies zoals SSE2 etc.
Waarom maak je niet gewoon een aantal configs met als enige variabele het CPU type?
Je moet dan alsnog X keer compilen, maar de 2e, 3e, 4e etc keer zal een stuk sneller gaan omdat je niet alle files opnieuw compiled. (alhoewel ik dat niet zeker weet als je het CPU type aanpast.
Ik heb zo ie zo wel eens begrepen dat al die optimalisaties voor je kernel niet super veel uitmaken, klopt dat?
Ctrl4Dkn: ESP32 (Floor) Heat Controller With Daikin (Heatpump) Support - https://github.com/arnova/ctrl4dkn
/u/26742/000000751.png?f=community)
Pentium-MMX lijkt me een slechte keuze (verkeerde optimalisatie-tactieken voor moderne CPU's die wat meer op de ppro lijken). De Pentium-Pro lijkt me een veilige keuze, maar ik denk dat de Pentium-III ook wel werkt, en die is dan beter.
Maar, zie ook verderop.
De kernel gebruikt geen SSE2, dus dat maakt helemaal niks uit.
Waarom gebruik je dan niet distro-kernels? Die bieden vaak ook nog een aantal kernels die voor bepaalde processorfamilies geoptimaliseerd zijn, zodat je op elke machine een kernel kunt kiezen die zo dicht mogelijk bij die CPU in de buurt komt.
Een grote reden om een kernel voor bepaalde CPU's te compilen is om (correct) gebruik te kunnen maken van instructies die alleen op die CPU's voorkomen. Hierbij kun je denken aan wat snellere 'gewone' instructies, maar ook bijvoorbeeld instructies om snel systemcalls naar de kernel te kunnen doen (zoals SYSENTER van Intel, en SYSCALL van AMD).
Concrete snelheidswinst weet ik niet, maar ik vermoed dat dit in bepaalde scenario's wel het een en ander uit kan maken (zou wel interessant zijn om eens te benchmarken...). Het feit dat de kernel een van de weinig dingen is waar distributies de moeite voor doen om verschillende packages voor verschillende CPU's te maken geeft ook te denken.
/u/12038/crop69547035714ff_cropped.png?f=community)
Ga je alleen de kernel compileren of ook andere dingen 
Als Gentoo gebruiker denk ik gelijk aan CFLAGS (variabele in make.conf) - daar kun je door middel van -march exclusief optimaliseren voor een CPU archtectuur en door middel van -mcpu optimaliseren maar wel compatible blijven met andere CPUs. In dit geval zou ik de grootste gemene deler pakken en daarop -mcpu richten.
Als ik dat lijstje bekijk kom je uit op 1x pentium4 (of nocona), 1x nocona, 1x amd64, 1x athlon-xp
Grootste gemene deler is i686, mmx en SSE. Dat klinkt als een P3
Ik zou dus kiezen voor -mcpu=pentium3
Daarmee is ook gelijk de CHOST bepaald - i686
Overigens is er wel een punt waar je flink snelheid inboekt hier. De Athlon CPUs hebben een ijzersterke FPU en een relatief zwakkere SSE implementatie. De P4-derivaten hebben een vrij lichte FPU en een sterke SSE. Het is dan ook voor P4 doorgaans aan te bevelen om floating point getallen via SSE ipv FPU te laten berekenen. Dat kun je hier niet doen, dus moet je ze op hun FPU laten terugvallen
Wat dat betreft zou ik serieus overwegen om minstens twee kernels te bakken - eentje voor de AthlonXP/64 (-mcpu=athlon-xp) en eentje voor de D/Xeon (-mcpu=pentium4 -mfpmath=sse als de Xeon geen EMT64 ondersteunt, indien weldan -mcpu=nocona -mfpmath=sse)
Maar eigenlijk zie ik niet waarom het bakken van de kernels zo lang hoeft te duren - grootste snelheidswinst haal je door gewoon de kernels uit te kleden naar wat je echt nodig hebt. Zeker bij Debian kan dat letterlijk een factor tien schelen in de tijd die je kwijt bent voor die onnoemelijke modules (m'n vriendin doet dat niet, is rustig 2u bezig met haar Duron 1600, ik doe dat wel, ben zelden in meer dan 10 minuten klaar op mijn AthlonXP 1800+ - dat verschil komt niet door die 128kB L2 die ik meer heb)
Als Gentoo gebruiker denk ik gelijk aan CFLAGS (variabele in make.conf) - daar kun je door middel van -march exclusief optimaliseren voor een CPU archtectuur en door middel van -mcpu optimaliseren maar wel compatible blijven met andere CPUs. In dit geval zou ik de grootste gemene deler pakken en daarop -mcpu richten.
Als ik dat lijstje bekijk kom je uit op 1x pentium4 (of nocona), 1x nocona, 1x amd64, 1x athlon-xp
Grootste gemene deler is i686, mmx en SSE. Dat klinkt als een P3
Ik zou dus kiezen voor -mcpu=pentium3
Daarmee is ook gelijk de CHOST bepaald - i686
Overigens is er wel een punt waar je flink snelheid inboekt hier. De Athlon CPUs hebben een ijzersterke FPU en een relatief zwakkere SSE implementatie. De P4-derivaten hebben een vrij lichte FPU en een sterke SSE. Het is dan ook voor P4 doorgaans aan te bevelen om floating point getallen via SSE ipv FPU te laten berekenen. Dat kun je hier niet doen, dus moet je ze op hun FPU laten terugvallen
Wat dat betreft zou ik serieus overwegen om minstens twee kernels te bakken - eentje voor de AthlonXP/64 (-mcpu=athlon-xp) en eentje voor de D/Xeon (-mcpu=pentium4 -mfpmath=sse als de Xeon geen EMT64 ondersteunt, indien weldan -mcpu=nocona -mfpmath=sse)
Maar eigenlijk zie ik niet waarom het bakken van de kernels zo lang hoeft te duren - grootste snelheidswinst haal je door gewoon de kernels uit te kleden naar wat je echt nodig hebt. Zeker bij Debian kan dat letterlijk een factor tien schelen in de tijd die je kwijt bent voor die onnoemelijke modules (m'n vriendin doet dat niet, is rustig 2u bezig met haar Duron 1600, ik doe dat wel, ben zelden in meer dan 10 minuten klaar op mijn AthlonXP 1800+ - dat verschil komt niet door die 128kB L2 die ik meer heb
)
Oslik blyat! Oslik!
:strip_icc():strip_exif()/u/32232/laupro60x60.jpg?f=community)
Ik neem aan dat je een netwerk boot doen oid? Als je alles gewoon op i586 compileert moet het goed komen. De snelheidsverschillen zijn meestal minimaal. Al hoewel het op snelle processoren wel kan oplopen tot over 40% in sommige benchmarks (dus i386 vs amd64 oid). Maar ook dan heb je het vaak over timings waar je als je bijvoorbeeld een thin client hebt die alleen X draait vrijwel niets van gaat merken.
Zelf heb ik voor een boot from network config de kernel gewoon op i386 staan vaak, incl de userspace software. Dan kan je booten van 486'er tot laatste spul. Zeker als het alleen om booten+laden van X gaat, dan win je er nauwelijks wat mee. Als je echt met 3D oid aan de slag gaat (workstation) dan is het zeker aan te raden. Maar als je veel clients hebt zou ik het meer op safe spelen dan die 2 seconde minder boottime oid. De echte apps worden dan op de server gedraaid, die dan natuurlijk wel helemaal getuned is. Al hoewel je met O2/O3 al zo gigantisch veel snelheids/betrouwbaarheidsverschil kan halen dat het echt gerommel in de marge is soms. En als je 20 parameters aan gcc mee geeft maakt dat de zaak er ook niet bepaald sneller op natuurlijk.
Kernel compileren duurt meestal 4-5 minuten hier, probeer zo min mogelijk gebruik te maken van modules, dat zorgt namelijk voor behoorlijk wat overhead (zowel bij compileren als het extra initiëren/laden). Tenzij je een USB-driver aan het devven bent oid, dan is het wel eens handig om je usbcore als module te hebben mocht die crashen en je wil niet meteen heel je systeem down hebben oid
. En vaak heb ik ook wat PATA/SATA-controllers als module zodat ik zeker weet dat de volgorde (sda, sdb etc) goed staat bij het laden van software-arrays.
Zelf heb ik voor een boot from network config de kernel gewoon op i386 staan vaak, incl de userspace software. Dan kan je booten van 486'er tot laatste spul. Zeker als het alleen om booten+laden van X gaat, dan win je er nauwelijks wat mee. Als je echt met 3D oid aan de slag gaat (workstation) dan is het zeker aan te raden. Maar als je veel clients hebt zou ik het meer op safe spelen dan die 2 seconde minder boottime oid. De echte apps worden dan op de server gedraaid, die dan natuurlijk wel helemaal getuned is. Al hoewel je met O2/O3 al zo gigantisch veel snelheids/betrouwbaarheidsverschil kan halen dat het echt gerommel in de marge is soms. En als je 20 parameters aan gcc mee geeft maakt dat de zaak er ook niet bepaald sneller op natuurlijk.
Kernel compileren duurt meestal 4-5 minuten hier, probeer zo min mogelijk gebruik te maken van modules, dat zorgt namelijk voor behoorlijk wat overhead (zowel bij compileren als het extra initiëren/laden). Tenzij je een USB-driver aan het devven bent oid, dan is het wel eens handig om je usbcore als module te hebben mocht die crashen en je wil niet meteen heel je systeem down hebben oid
. En vaak heb ik ook wat PATA/SATA-controllers als module zodat ik zeker weet dat de volgorde (sda, sdb etc) goed staat bij het laden van software-arrays.
Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!
Pagina: 1