'Apple past system-level-geheugen A16-soc aan ten opzichte van A15'

Er zijn beelden verschenen van de Apple A16-soc. Het L2-cachegeheugen van de performance cores zou 16MB groot zijn, dat is 33 procent meer dan bij de A15. Het system-level-cachegeheugen van de soc zou 24MB bedragen, terwijl dat bij de A15-soc nog 32MB was.

De redactie van techsite Angstronomics zag een video van TechanaLye op Twitter verschijnen met daarin naar eigen zeggen de A16-soc van Apple. De redactie voerde vervolgens een eigen die-analyse van de chip uit door de architectuur te vergelijken met die van de A15-soc.

Die architectuur bleef volgens Angstronomics grotendeels gelijk, maar er zijn volgens de redactie wel enkele verschillen. Angstronomics stelt dat het L2-cache van de zogenaamde high-efficiency cores op de A16 met 4MB even groot is gebleven. Het L2-cache van de zogenaamde high-performance cores zou 16MB bedragen in plaats van 12MB bij de A15. Bij de A14 was het L2-cachegeheugen nog 8MB groot.

Het system-level-cachegeheugen bedraagt volgens Angstronomics dan weer 24MB, terwijl dat bij de A15 32MB was. Bij de A14 was dat geheugen 16MB groot. Apple zou met de A16 ook zijn overgeschakeld op Lpddr5-6400-geheugen in plaats van nog langer lpddr4x-4266-geheugen te gebruiken. Dat ligt in lijn met eerdere lekken over de A16. De A16 zou iets groter uitvallen dan bij de A15, maar exacte afmetingen kon Angstronomics niet meegeven.

Apple introduceerde de A16-soc begin september tijdens zijn iPhone-evenement. De mobiele soc wordt enkel voor de nieuwe iPhone 14 Pro en 14 Pro Max gebruikt. De chipset wordt gebakken op het N4P-procédé van TSMC. Dat is een verbeterde versie van het 5nm-procédé waar de A15 op wordt gebakken. De A16 bevat twee high-performances cores en vier high-efficiency cores. De high-performances cores zouden volgens Apple 20 procent minder energie verbruiken in vergelijking met de A15. Een directe prestatievergelijking met de A15 gaf echter Apple niet.

Update, 14u20: Extra informatie toegevoegd over de A16 in de laatste alinea.

Analyse Apple A16-soc (links) tegenover Apple A15-soc (rechts)

Reacties (59)

[jmvdkolk]

Ik vind CPU cache optimalisatie een heel interessant domein. Apple denkt blijkbaar dat de grotere L2 cache for de P-cores voldoende performance winst oplevert dat ze tegelijk de L3 cache kleiner kunnen maken. Ik ben benieuwd of dit betekent dat software anders geoptimaliseerd moet worden. Ik zit professioneel in de wereld van de mainframes (z/OS) en daar speelt dit soort vragen nu voor de nieuwe IBM z16 processor. IBM heeft L2 cache groter gemaakt, en tegelijk L3 en L4 cache verwijderd. L3 en L4 cache zijn nu "virtueel", en wel door stukjes L2 van andere processoren te gebruiken. Wij zijn nu samen met klanten de performance veranderingen van de z16 t.o.v. de z14 en z15 in kaart aan het brengen. Er zijn situaties waar het totale werk met veel minder CPU belasting draait, en ook situaties waar de CPU juist extra belast is door alle wait cycles.

Ik ben heel benieuwd wat real world getallen zullen laten zien voor de A16 processor.

[Guru Evi]

Ik denk dat er deels ook een probleem met ruimte op de die is. Cache neemt enorm veel plaats op, dus moeten ze ofwel dingen kleiner maken ofwel een voor het ander vervangen.

Daarnaast is het ook waar dat het onderhoud van geheugen energie kost. De efficiëntie cores die oa dingen in de achtergrond draaien (als het scherm af is) hebben meestal niet zoveel geheugen nodig. Om dan bij elke notificatie L2+L3 cache volledig inschakelen hebben ze waarschijnlijk onnodig geacht en dus nog eens een paar microWatt uitsparen, op eerste zicht misschien een beetje overboord (vooral als je achtergrond van Intel, AMD en Android komt) maar ik ontvang nu dagelijks enkele honderd notificaties, komt al snel op een paar minuten batterij erbij.

[Xander2]

Ik denk eerder dat ze erachter gekomen zijn dat de L3 (TLB) minder benut wordt dan voorspeld omdat een hoop van de 6G RAM statisch gevuld is en L2 meer benut wordt door throttling tussen P/E cores.

[Frank-L]

'System-level-geheugen Apple A16-soc is minder groot dan bij A15' is wel een heel misleidende titel. Het gaat namelijk alleen om het L3 cache geheugen, L2 is zelfs groter geworden. Je zou ook kunnen stellen dat een deel van het L3 cache vervangen is door extra L2 cache, wat de chip sneller kan maken. De titel lijkt 1 parameter die toevallig lager is geworden als clickbait te gebruiken.

[Zezura]

Ik denk dat het een click-bait titel is.
En daar erger ik me aan. Want het doet voorkomen alsof de SOC slechter is geworden maar als je kijkt naar alle specs bij elkaar dan is A16 echter wel weer beter dan A15

[bamboe]

Ja dat is het ook gewoon, anders hadden ze wel een titel gemaakt in de trent van Apple nieuwe A16 soc is ondanks kleiner L3 cache sneller dan voorganger A15.

[SquareOne]

@JayStout wellicht een paragraaf toevoegen wat de implicaties zijn? In welke use cases merkt een gebruiker hier iets van?

Ik denk nu alleen maar “so what”.

[Reactie gewijzigd door SquareOne op 25 juli 2024 00:03]

[Pieter_621]

Het is wel heel erg so what, inderdaad. Het zijn ontwerpkeuzes en afwegingen tijdens het chipontwerp.

De latency van cache-geheugen is lager dan van het normale geheugen, dus er is kans op dat de chip wat minder presteert omdat er vaker data niet in de cache zit en de chip terug moet vallen op langzamer gewoon geheugen. Maar tegelijk wordt er sneller normaal geheugen gebruikt dan in de vorige versie, en zijn er andere wijzigingen doorgevoerd aan de chip. En misschien is het cache-geheugen dat gebruikt wordt ook wel anders. Wat de implicaties zijn kan je op basis van deze summiere informatie niet voorspellen. Daar zijn benchmarks voor.

[Aaargh!]

De latency van cache-geheugen is lager dan van het normale geheugen, dus er is kans op dat de chip wat minder presteert omdat er vaker data niet in de cache zit en de chip terug moet vallen op langzamer gewoon geheugen.

De L3 cache is kleiner, maar de L2 cache is groter (voor de performance cores), Er lijkt dus gekozen te zijn om wat te schuiven tussen de caches, Een grotere L2 ten koste van een kleinere L3 kan alsnog performance opleveren, L2 is immers sneller dan L3.

[Pieter_621]

Ah, ik had de grotere L2-cache gemist bij de performance cores - dat kan inderdaad wel uitmaken.

[avlt]

De optimale hoeveelheid cache-geheugen is afhankelijk van een heleboel factoren, kun je eigenlijk alleen met benchmarks of simulatie voorspellen. Een 10% grotere cache betekent niet automatisch 10% betere prestaties. De soort code (lokaliteit) is enorm van invloed op de prestaties van een cache. Er zijn zelfs situaties denkbaar waarbij een grotere cache juist slechtere prestaties oplevert.

[jmvdkolk]

Kan je een voorbeeld geven van een situatie / werklast waarbij een grotere cache slechtere prestaties oplevert (uitgaande van even snelle cache en even snelle paden tussen de CPU en de cache)?

[Groningerkoek]

Een grotere cache verhoogt de kans dat wat je nodig hebt in je cache zit, maar een grotere cache kan ook de tijd verhogen voordat datgene wat je nodig hebt gevonden is in je cache.

Heel simplistisch stel je zou 10TB cache hebben, dan moet de computer eerst een lange lijst af met waar wat je nodig hebt zit, maar bij 1MB cache zal zo goed als nooit dat wat je nodig hebt in je cache zitten.

Uiteindelijk zoals met veel van dit soort dingen is er in samenhang met de prijs een balans die voor de meeste doeleinden het beste is.

[jmvdkolk]

Ik ben helaas niet op de hoogte van hoe de juiste data uit de cache gehaald wordt. Ik mag hopen dat het veel slimmer is dan een lange lijst afgaan. Maar uiteindelijk is er natuurlijk een prijs, maar die is als het goed is nog steeds veel lager dan de prijs voor de data uit main memory halen. Ik denk dat de 10 TB cache daarom weliswaar langzamer is met ophalen van data dan de 1 MB cache, maar dat data uit de 10 TB cache halen nog steeds sneller zal zijn dan data uit het main memory halen. En omdat er minder uit main memory gehaald moet worden, zou de processor met een 10 TB cache nog steeds sneller kunnen zijn dan dezelfde processor met een kleinere cache.

[TJ Roelsma]

Cachegeheugen werkt op basis van stacking, dus de data wordt serieel weggeschreven in de cache.
Dat is geweldig als de CPU met een constante datastroom bezig is en de voorspelbare volgende data alvast in de cache klaargezet kan worden (branche-prediction).

Zodra je datastroom meer willekeurig wordt werkt dit principe echter averechts, omdat in het geval van een verkeerde branche-prediction de cache eerst geleegd en daarna opnieuw gevuld moet worden, hetgeen relatief veel tijd kost.

[Donstil]

Maar niet als je data niet in die 10TB, dan heeft de cpu dat helemaal moeten doorlopen om vervolgens toch het lokale memory aan te spreken, met minder cache weet de cpu sneller en kan daardoor sneller “verder kijken”

[Xander2]

Je hebt maar een constant aantal lijntjes van CPU naar cache, van daaruit moet geschakeld worden naar geheugenlocaties.

Bij 10TB zijn veel meer beslislagen nodig voor addressering.

Een 1MB cache zal altijd sneller werken (waarvan CPU met een redelijk getal als 64bits) dan 10TB omdat de 1MB een veel kleinere adresruimte/adreslengte heeft dan de 10TB, ophalen/opslag kost simpelweg veel minder tijd

[NoobishPro]

Het is in principe een hele simpele correlatie; Meer opslag = trager. Dit staat (vanaf een bepaald punt) los van de prijs.

Denk er maar eens over na waarom harde schijven (goedkoopste, maar hoogste opslag) zo traag zijn waar SSD's enorm veel sneller zijn (aanzienlijk minder opslag), wat dan weer voorbij wordt gegaan door RAM, wat wéér een hele slag kleiner is in opslag. Pas dan ga je naar de CPU, waar meerdere lagen cache (en dus effectief opslag) zijn. Met regelmaat, de traagste cache ook als de grootste.

Een (bits-gebaseerde) computer zal nooit een magische 'slimme' manier hebben om opslag uit te lezen. Deze zal altijd iets uit moeten lezen, bit voor bit. Één slimme truuk welke we al erg lang gebruiken, is het opslaan van de locatie van data dmv identificatie nummertjes, waardoor je dus snel kunt identificeren "Waar moet ik zoeken?", maar deze route opslag kan ook maar zó klein worden gezien dit om triljoenen(?) adresjes gaat.

Als je het even ziet als een warenhuis, is dit misschien het makkelijkst.

Je hebt een warenhuis vol met 100 bakjes. In ieder bakje zit iets wat jij nodig hebt voor de binnenkomende orders. Jij wil niet voor iedere order welke je binnen krijgt, bij ieder bakje kijken wat erin zit, maar direct weten naar welk bakje je toe moet. Prima, dus je maakt een soort plattegrond. Een route kaart. So far, so good, right?

Maar beeld je nu in dat dit warenhuis van 100 artikelen, naar 100.000.000.000 artikelen gaat. Dan kun jij wel een routekaart hebben, maar het gaat je toch écht wel even kosten om dit uit te lezen.

Daarom bevat je PC als het ware meerdere warenhuisjes met een prioriteitensysteem.
Het eerste warenhuis is (vaak, maar niet altijd) het kleinst; de L1 cache van je CPU. Dit is jouw kleine warenhuisje letterlijk direct voor de deur van je klant. Dit warenhuis heeft alleen wat altijd met spoed nodig is en het gewoon niet kan veroorloven om mensen erop te laten wachten.

De L2 cache is net één kleine prioriteit lager. Ietsje groter, ietsje trager, één straatje verderop, maar nog steeds enorm belangrijk. L3 cache ongeveer hetzelfde verhaal.

Dan heb je je RAM, dat is gewoon een gigantisch nationaal warenhuis welke ook heel veel belangrijk spul bewaart, maar gewoon simpelweg te groot is of niet genoeg spoed heeft om even direct beschikbaar te zijn als wat er in die vorige 3 warenhuisjes ligt.

tl;dr
Dit om te zeggen;

Ik mag hopen dat het veel slimmer is dan een lange lijst afgaan.

Je hoopt in principe dus helemaal goed, maar deze verschillende lagen van cache (3 levels) + ram + opslag, is dus precies dat "slimmere systeem" waardoor een klein gedeelte van de cache sneller kan werken (omdat het kleine prioriteitenlijstjes/telefoonboekjes zijn ipv die éne hele grote lijst)

Kleine edit to clarify: Er zit natuurlijk wel net wat meer verschil tussen de verschillende opslag mediums dan enkel formaat en afstand, maar het doel hiervan was het prioriteitensysteem.

[Reactie gewijzigd door NoobishPro op 25 juli 2024 00:03]

[avlt]

b.v. als de data in één cache gebruikt wordt door een andere processor/core, moet de data in de ene cache geinvalideerd worden.Als meerdere cores in dezelfde data onderweg zijn kan dit cache-pinging behoorlijk desastreus uitpakken.

[BikkelZ]

Volgens mij gaan we helemaal niks interessants meer zien op het gebied van mobile SoC's van Apple de komende jaren, ze kunnen dit nog heel lang uitmelken met wat tweaks en procesverbeteringen voordat de concurrentie ze heeft ingehaald en de transitie van x86 naar de M-reeks voor de macOS devices is nog steeds niet afgerond dus daar gaat alle energie naar toe.

Maar ik kan me ook voorstellen dat bepaalde SoC ontwerpers zich gaan vervelen en iets leuks bij de concurrent gaan doen.

[Fucitol]

Gezien de plaatjes van de die-analyze zie ik een behoorlijk redesign? Ook de tekst (dus niet de titel) spreekt over enkele best grote wijzigingen in ontwerp en wanneer alles al voldoende snel is is zorgen voor efficiëntie natuurlijk een goede insteek. In dit geval, redelijk wat meer performance én 20% zuiniger voor de performance-cores.

[Halo_Master]

Ik denk dat ze, zeker voor een smartphone, gewoon tegen limieten aanlopen. Om daar weer echte verbeteringen te kunnen laten zien, zullen ze eerst naar de 3nm moeten gaan ipv de verbeterde 5 nm die ze nu gebruiken (en 4nm) noemen. Hetzelfde geldt voor laptop processor’s . Ik verwacht dat de socs van de nieuwe MacBook pro’ s wel op 3nm zullen worden gemaakt, en dat er dan ook waarschijnlijk een nieuwe Mac Pro zal worden uitgebracht , waarna de iPad en de iphones ook over zullen gaan.

[Rumpelstiltskin]

Ik ben benieuwd naar de benchmarks. Ik type dit nu van een 14 pro Max en ik moet zeggen hij is heel heel snel. Verschil ten opzichte van m’n vorige toestel is minimaal (13 pro Max). Ik hoop dat het toestel zuiniger is met behulp van de a16. 2 dagen is nog te kort om er echt iets van te zeggen.

Wat voor app zou ik kunnen gebruiken voor een benchmark?

[Snowfall]

GeekBench, GFX Bench, Antutu.

[Rumpelstiltskin]

Hmm single core benchmark wijst uit dat de a16 beter presteert dan de m1 in de iPad Pro. Multicore daarentegen is een ander verhaal, 7215 voor de m1 vs 5370 van de a16. Ik vind het lastig om de cijfers goed te interpreteren. Voor een telefoon zijn de cijfers heel goed, maar heb je dit ook echt nodig?

Vreemde is dat in geek bench vergeleken wordt met de iPhone 12 Pro en lager maar de 13 pro niet…..

[RAAF12]

Bij mijn iPhone 13 Pro Max: single core score is 1725 en multi-core is 4713.
Scoort hoger dan de vergelijking met de andere iPhone 13,12,11 bij GeekBench. Altijd leuk zo'n tooltje weet je wat je hebt.....

[Rumpelstiltskin]

Single core is 1870 op de mijne. Verschil is dus niet zo heel groot. Ik heb de 128 Gb versie. Zal Apple kennende wel hoger scoren als je meer opslag hebt.

[ikweethetbeter]

Wat voor app zou ik kunnen gebruiken voor een benchmark?

Geen app maar je gezond verstand. Koop niet elk jaar een nieuwe telefoon, maar elke 3 jaar, dan merk je zelf de verbeteringen.

[Rumpelstiltskin]

Ik heb de mazzel dat ik elk jaar van m’n werkgever de “oude” telefoon mag inruilen voor een nieuwe.

Maar voorheen vond ik de specbump om de 2/3 jaar is heel fijn!

[Reactie gewijzigd door Rumpelstiltskin op 25 juli 2024 00:03]

[Transistortje]

Voor wie dit, net als ik, op zou moeten zoeken: de A16 is wat in de recent uitgebrachte iPhone 14 Pro modellen zit.

Het artikel is hier onduidelijk over en de laatste alinea klopt gewoon niet.

[Reactie gewijzigd door Transistortje op 25 juli 2024 00:03]

[JayStout]

Inderdaad, het betreft natuurlijk de A16 die in september werd geïntroduceerd. De fout is aangepast.

[number1]

Is slechts een lichte verbetering tegenover de A15 lijkt me, enkel de ddr5 dan. Zou het prijsverschil dan ook iets te maken hebben met te kiezen voor het duurdere ddr5 ?

[jabwd]

N4P zal ook niet goedkoop zijn. Ik verwacht verder dat het ook gewoon een supply-chain dingetje is. Ik ga er beetje vanuit dat de M2 in de macbook air een soort M2-'Light' is en de rest van de wafer supply gebruikt zal worden voor A16 gebaseerde macs. Simpelweg, wrss te weinig supply-chain ruimte en reden om een A16 in een iphone 14 te duwen.

[ikweethetbeter]

De titel lijkt me een gevalletje click bait. De L3 cache is kleiner, maar de L2 cache is groter. Ik gok dat Apple dat heeft gedaan omdat het gros van de applicaties daarmee sneller wordt.

Met andere woorden, leuk feitje maar de titel is onnodig suggestief negatief.

[DePruus]

Waarom een benzinetank van 200 liter, als een tank van 50 liter voldoet. Apple rekent alles goed uit. Meer investering is een langere terugverdienperiode. En als de gebruiker niet of nauwelijks iets merkt, dan snap ik die optimalisatie. Doet elk merk. Als Apple nu gezegd had, wij kunnen met een kleiner hoeveelheid uitkomen, dan is er het open.

[ikweethetbeter]

Slecht voorbeeld! Er is in totaal meer cache, maar die zit een stukje dichter bij de processor.

En de analogie gaat ook mank. Zoals bijna elke analogie overigens... Om een benzinetank 4 keer zo groot te maken, heeft deze ook 4 keer zoveel ruimte nodig. Kies maar, geen achterbak of geen achterbank?

[Fucitol]

Slecht voorbeeld vanwege een slechte titel; er is geschoven met de cache groottes, meer snel cache (L2) en minder ‘trager’ cache (L3).
Veel reacties hier hadden voorkomen kunnen worden zonder de clickbait titel.

[ikweethetbeter]

Dat is inderdaad exact wat ik gisteren om 18:07 heb geschreven...

De titel is onnodig negatief, zodat er massaal op geklikt gaat worden. Tweakers wordt minder...

[Baet]

Slecht voorbeeld😬. Ik zou zelf maar wat blij zijn met een 200 liter tank. Lekker om de 3000km tanken ipv die karige 600km nu.

[MN-Power]

En dus gemiddeld een kilo of 120kg teveel mee en daardoor hoger verbruik, langere remweg, slechter weggedrag, hogere slijtage aan remmen, banden maar ook andere onderdelen. Het kost je ook nog ruimte. Ook heeft het eventueel nog gevolgen voor het gewicht wat je mee kan nemen.

Dan toch liever een zuinigere motor. Te beginnen met eindelijk eens wat doen met al die warmte die de uitlaat uit gaat(het is geen verlies zolang je het niet weg laat waaien).

Tanken bij een onbemand station is bovendien iets wat erg weinig tijd kost. Totaal geen probleem mee. En als je een keer met guur rotweer je 200 liter moet tanken ben je ook een behoorlijke tijd bezig.

[Reactie gewijzigd door MN-Power op 25 juli 2024 00:03]

[avlt]

Nog even afgezien van de veiligheids aspecten; 200 liter brandstof geeft een aardige knal. (400 liter als je tegen een collega aanrijdt).

[The Third Man]

De kans dat brandstof explodeert is minimaal (Hollywood overdrijft dat natuurlijk), je krijgt hooguit een grotere brand.

[Nol_NL]

Blijft bijzonder hoe men bepaalde producten vaak één op één weet te vergelijken met een automobiel. Vergelijkingen die vaak kant nog wal raken. Het gaat hier over een chip mensen.

[Frame164]

Het gaat over optimalisatie van een systeem. En dat kan je overal op toepassen. Of het nu een CPU, een auto of een boekenkast is.

[P. vd Loo]

Exact. Vergelijkingen zijn in 99% van de gevallen complete onzin.

[avlt]

En wat dacht je van de "klotseffecten" van 200kilo vloeistof in je tank?

[klonic]

De oplossing is het plaatsen van tussenschotten in je tank. Deze oplossing wordt ook bij tankwagens en schepen toegepast.

[Bomberman71]

En ook in de caterpan van een beetje auto ....

[Snake]

Auto verbruikt tussen de 12 en 20 liter / 100km. Of tussen 8.3333km / l en 5km / l.

100 liter zou al beter zijn als 53 wat ik nu heb.

[Groningerkoek]

Waarom koop je dan ook zo'n slurper met een kleine tank?

Mijn vorige zat ook op zulks verbruik maar wel met een 67 liter tank. Wat voor auto heb jij met zo'n verbruik en zo'n kleine tank?

[Snake]

M240i Convertible xDrive. Omdat het hier zo vaak sneeuwt.

[MN-Power]

Dat is behoorlijk stevig inderdaad. Ik heb een 3 liter 6-pitter die bij ritjes in de bebouwde kom rond de 1:10 hangt(winter net wat slechter) en snelweg rond de 1:12,5. En overdag (100) is dat nog beduidend beter. Dus mijn tank van 63 liter(geloof ik) is voor mij ruim voldoende. Zelfs binnen de bebouwde kom haal ik jouw verbruik niet.

[Reactie gewijzigd door MN-Power op 25 juli 2024 00:03]

[Bomberman71]

Erg benieuwd welke motor dat is ... Met een M54 3L ga je dat in ieder geval gewoon NIET redden met normaal rijgedrag binnen de bebouwde kom.
Mischien conform de 'boordcomputer' maar niet in het echie.

[Reactie gewijzigd door Bomberman71 op 25 juli 2024 00:03]

[MN-Power]

Een 2002 e46 330i touring met M54 idd. Met anticiperend rijgedrag(dat is wat ik normaal noem) en een beetje rekening houden wanneer je gaat rijden kom je al een heel eind. Dus als het even kan buiten de spits bijvoorbeeld. En alle kleine dingen helpen zoals je auto achterstevoren parkeren. Verbruik en slijtage is hoog bij koude motor, dus dan wil je met dat verbruik liefst zoveel mogelijk afstand maken ipv een paar meter. En het grootste deel van mijn route is ring(70 en goede doorstroming) of wijkring(50 en overal voorrang), het 30km deel van mijn wijk ben ik in een meter of 500 door. En als allerlaatste, mijn meeste ritten zijn een km of 6 of langer.

Ik ben ook zeker geen trage rijder. Ik zorg alleen wel dat ik zoveel mogelijk(en veilig) vaart kan houden door bijvoorbeeld voldoende afstand te houden, zeker als je (ik noem maar wat) weet dat iemand af gaat slaan. Effectief kan ik dus ook eerder weer op snelheid zijn dan iemand die op 5 meter afstand blijft. Wellicht dat het ook nog uitmaakt dat ik mijn airco eigenlijk nooit gebruik(nooit wat mee gehad).

Ik zet mijn teller altijd op nul na een tankbeurt en heb hem nog nooit binnen 500km móeten vullen, zelfs niet in hartje winter. En dan wil ik hem ook nog zo nu en dan een klein beetje warm laat draaien voor vertrek. Zomer zit voor mij op ca 1/9.5(met goed weer 10) winter ca 1/8.5 als ik in beide gevallen de gehele tank amper de bebouwde kom uit kom.

Op sprit monitor zit overigens de bulk tussen de 1/9 en 1/11(ik schat bijna 80%)
https://www.spritmonitor....actmodel=330i&powerunit=2

Wat me wel opvalt is dat juist bij de zuinigste veel tourings zitten. Andere mindset denk ik. Oh ja last but not least, de rolomtrek van mijn banden is iets groter(afwijkende bandenmaat), dus mijn eindoverbrenging is effectief wat langer. Dus draait ie lagere toeren, echter betekent dat ook dat de auto dus net iets verder rijdt dan hij zelf aangeeft(en dus ook het verbruik daarop berekent).

[Reactie gewijzigd door MN-Power op 25 juli 2024 00:03]

[Bomberman71]

Ben verbaasd, maar als ik zo jouw routines lees dan heb ik daar wel beeld bij.
Afstandhouden en idd anticiperen schelen enorm, net als het uitlaten rollen bij een afrit en dan amper te hoeven remmen.

Heb zelf de M54B25 en die houd het al 430.000 km ... Als hij er ooit mee stopt dan tracht ik hem wel te vervangen door een M54B30 want ik vind met name het koppel erg mager van die lijn 6 (Heb jaren turbo 4 en 5 cilinder gereden).

In weze zijn het bullitproof blokken en ik lees verhalen van 750.000+ km !

Ben zelf ook een touring man maar helaas kon ik deze goed overnemen en het is helaas een Sedan.
Heb erg weinig met een Sedan want ik vind hem onpractisch en met name die van BMW vind ik waardeloos met 0 toegang tot de koffer vanaf de achterbank, niet eens een skiluik.
Enige voordeel is dat hij wel stil is en na mijn jonge jaren met sportuitlaten enzo mis ik die resonantie echt niet. Echt een duidelijk voordeel van een Sedan.

Maar goed, zelf zal ik niet snel meer een Sedan kiezen, Altijd dan een station/touring of een hatchback.

[MN-Power]

E46 sedans(en volgens mij ook coupé's) waren leverbaar met neerklapbare achterbank en zeer waarschijnlijk ook met alleen skiluik. Ombouwen naar de compleet neerklapbare achterbank is alleen waarschijnlijk geen doen aangezien je dan plaatwerk weg moet zagen(dus eigenlijk ook veer verstevigen) én je het vergendelmechanisme dan ook in moet bouwen. Skiluik zou misschien nog te doen zijn aangezien je daarvoor slechts een klein deel plaatwerk hoeft te verwijderen en het klikmechanisme volgens mij aan de bank vastzit. Als je dit wil doen neem dit niet van mij aan, laat je informeren, ik kan het zomaar verkeerd hebben.

Wat ik nog vergeten was, mijn banden zijn 'slechts' 215 breed. Tevens heb ik er 5-spaaks 530xi Style 138 velgen onder(staan 4mm verder naar buiten). Dit idee dus, maar dan op een touring:
https://www.e46fanatics.c...38-on-an-e46-pics.771446/

Dit is één van de lichtste 17" OEM velgen, dat helpt óók met verbruik. Roterend gewicht telt harder mee dan 'dood' gewicht bij acceleratie, remmen en verbruik. Banden schijnen ook een vrij lage rolweerstand te hebben(Cross Climates). Stil zijn ze in elk geval wel en erg fijne allrounders.

Het is inderdaad een heel fijn blok, die van mij heeft ook al bijna 330k ervaring. Elke keer weer een plezier als je hem start. Ben er over het algemeen ook zuinig op, wat zich dus ook vertaalt in laag verbruik, Het is ook een blok wat ondanks zijn vermogen(en idd mede dankzij zijn koppel) uitnodigt tot onthaasten.... Meestal

[Reactie gewijzigd door MN-Power op 25 juli 2024 00:03]

[lolly]

"Apple introduceerde de A15... etc. Dat is een verbeterde versie van de A15...".
Wat wordt hier precies mee bedoeld?

Oh, is al aangepast. thanks

[Reactie gewijzigd door lolly op 25 juli 2024 00:03]