C# beter een int gebruiken dan een byte ?

[Verwijderd]

ik heb een tijd geleden een stukje gelezen dat een processor tegenwoordig sneller een int kan verwerken dan
dat hij een byte - char kan verwerken.
een int in C# is een int 32bits terwijl een byte er 8 is dus het zou logischer zijn dat een cpu 8 bits sneller kan verwerken dan de 32bits van een int
Ik kan helaas de bron niet weer vinden.

zie bv in c# dat serialPort.ReadByte() een int als return waarde geeft ipv de "verwachte" byte

Hoe denken jullie hier over?

[ Voor 19% gewijzigd door Verwijderd op 19-03-2009 22:30 ]

[Verwijderd]

Waarom zou een byte geen integer zijn? Of andersom? Een byte is niet meer of minder dan een verzameling bits die samen te representeren zijn als een integer en vice versa. Intern werkt een CPU toch alleen maar met groupjes bits die wij bytes noemen maar die allerlei soorten data kunnen bevatten. Op CPU niveau maakt het echter niet veel uit wat die data precies moet voorstellen.

[RobIII]

Verwijderd schreef op donderdag 19 maart 2009 @ 22:21:
Hoe denken jullie hier over?

Tja... ik vind de stelling een beetje karig Wat wil je nou horen? Dat een int sneller is dan een byte? En wat versta je onder een int? Misschien kan een CPU wel heel snel 4 bytes tegelijk verwerken...oh, wacht. Da's een int (althans, even uitgaande van een int32 ).

Ik zie verder, zeker zonder bronnen, weinig discussiewaarde in dit topic. Het is behoorlijk afhankelijk van context en ik zie al helemaal niet waarom je in je titel C# hebt gezet; waar ligt de link daarmee? De readbyte is gewoon een method van de serialport uit het .Net framework; dat is dus net zo goed van toepassing op bijv. VB.Net.

Bij deze dus het vriendelijke verzoek even je bronnen er bij te zetten en je topicstart wat uit te breiden naar iets discussiewaardigs; je vraag is nu namelijk heel breed en weinig concreet.

Als je wil weten hoe wij er over denken: Groen! Nee, dinsdag! Of toch... 42!

[ Voor 44% gewijzigd door RobIII op 19-03-2009 22:31 ]

[Data-base]

zoiets boeit in een taal als c# totaal niet om twee redenen:
- Als het enige verschil zou maken, zal de jit-compiler dit voor jou optimaliseren.
- Als het enige verschil zou maken, dan zal dat ruim genomen 5ns(berekening hieronder) schelen en als dat je bottleneck is...tja

uitgaande van 2ghz duurt 1 cycle 0,5ns (als ik me niet vergis in het feit dat 1 cycle = 1 klokslag). Dan zal je ruim genomen 10 extra klokslagen (natte vinger werk) nodig hebben om 3 bytes (int32) meer te kunnen verwerken.

Micronano-optimalisaties....

[Woy]

Verwijderd schreef op donderdag 19 maart 2009 @ 22:21:
ik heb een tijd geleden een stukje gelezen dat een processor tegenwoordig sneller een int kan verwerken dan
dat hij een byte - char kan verwerken.
een int in C# is een int 32bits terwijl een byte er 8 is dus het zou logischer zijn dat een cpu 8 bits sneller kan verwerken dan de 32bits van een int
Ik kan helaas de bron niet weer vinden.

MS geeft zelf aan dat er inderdaad voor een Int32 geoptimaliseerd is, maar of dat sneller is, is afhankelijk van wat je er mee doet. Neem als globale regel maar dat het verschil bijna niet te merken is. Als je tegen performance problemen aanloopt, en je komt er d.m.v. profiling achter dat de performance bij het gebruik van int/byte ligt kan je het altijd nog veranderen.

zie bv in c# dat serialPort.ReadByte() een int als return waarde geeft ipv de "verwachte" byte

Dat heeft een andere reden, namenlijk dat ReadByte ook -1 kan returnen, dat is niet mogenlijk met een byte. Aangezien een int zowel alle values van een byte kan bevatten en ook -1 word er een int terug gegeven.

[YopY]

Qua performance moet je je geen zorgen maken over het gebruiken van een byte of een int, tenzij je software aan het bouwen bent die zeer veel intensieve berekeningen doet. Je kunt je beter druk maken over het ontwerp van je programma - dwz, welke cijfers komen er in je variabele - en ook dan niet gaan beknibbelen op de waarden omdat je een byte oid wilt gebruiken. Ook zul je, wanneer je drie verschillende types voor je cijfervariabelen gebruikt, vaak conversies moeten doen - ook als je programma ineens verandert. Ik zou gewoon een int gebruiken, die is overal toepasbaar, flexibel, en retesnel voor de meeste toepassingen.

Bovenstaand verhaal is niet op een specifieke taal gericht, maar geldt voor alle talen met types.

[Matis]

Een processor heeft toch een ALU, en die is toch 32 bits breed? Wat daarme gebeurt kun je weinig aan doen. Ik zal je er niet zo druk over maken. Idd maakt de compiler/optimiser er zelf een zo efficient stukje code van.

En de tijds *winst* zal minimaal zijn. Het tikken van een karakter in dit forum zal al langer duren dan de tijdswinst die het oplevert in de rest van het leven van de applicatie.

Je gebruikt c# en geheugengebruik zal ook geen bottleneck zijn. Wanneer je C schrijf op een uC dan kan je soms beter een byte gebruiken ivm geheugen.

Een goede vraag, maar het antwoord zal weinig tot niets uitmaken

[bomberboy]

Ik weet niet hoe het exact in C# zit, maar in Java (toch voor een groot stuk vergelijkbaar) is het in ieder geval ook zo dat bij berekeningen een byte steeds naar een int gepromoveerd wordt. Dus indien je twee bytes optelt wordend ie intern voorgesteld als een integer, opgeteld en daarna gereduceerd tot een byte.

Dus ook als je ergens in je code

Java:

byte blah;
int bleh;

staan hebt, dan worden deze binnen de JVM beiden als een int voorgesteld.

Een blangrijker verschil is echter wanneer er arrays van ints of bytes opgeslagen worden.

Java:

byte[] blah = new byte[4];
int bleh = new int[4];

In dit geval is de ruimte die in het geheugen opgenomen wordt door deze arrays wel verschillend. In dat geval is de bovenstaande byte-array ook effectief 32 bits (dus vier bytes) en de int-array 128bit (of 4 ints of 16bytes lang). Dat kan dan wel een verschil in performance betekenen indien je die array heel vaak moet kopiëren bijvoorbeeld. Maar nog steeds geld dat op het moment dat je een berekening doet met een element uit de byte-array dat dit eigenlijk eerst naar een int wordt gepromoveerd en na de berekening terug naar een byte wordt gereduceerd.

Ik vermoed dat in .NET met C# gelijkaardige dingen zullen gebeuren.

[Hydra]

bomberboy schreef op vrijdag 20 maart 2009 @ 09:53:
Ik weet niet hoe het exact in C# zit, maar in Java (toch voor een groot stuk vergelijkbaar) is het in ieder geval ook zo dat bij berekeningen een byte steeds naar een int gepromoveerd wordt. Dus indien je twee bytes optelt wordend ie intern voorgesteld als een integer, opgeteld en daarna gereduceerd tot een byte.

Sterker nog:

Java:

    public void testByte()
    {
        byte a, b, c;
        a = (byte)1;
        b = (byte)1;
        c = a + b;
    }

Dit compileert gewoon niet. "Type mismatch, cannot convert from int to byte".

Edit: ook grappig trouwens:

Java:

public class Test
{
    public void testInt()
    {
        int a, b, c;
        a = 1;
        b = 1;
        c = a + b;
    }
    
    public void testByte()
    {
        byte a, b, c;
        a = (byte)1;
        b = (byte)1;
        c = (byte)(a + b);
    }
}

Gecompiled dan gedecompiled met javap:

code:

Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
  Code:
   0:   aload_0
   1:   invokespecial   #8; //Method java/lang/Object."<init>":()V
   4:   return

public void testInt();
  Code:
   0:   iconst_1
   1:   istore_1
   2:   iconst_1
   3:   istore_2
   4:   iload_1
   5:   iload_2
   6:   iadd
   7:   istore_3
   8:   return

public void testByte();
  Code:
   0:   iconst_1
   1:   istore_1
   2:   iconst_1
   3:   istore_2
   4:   iload_1
   5:   iload_2
   6:   iadd
   7:   i2b
   8:   istore_3
   9:   return
}

Wel 1 instructie verschil, i2b, oftewel int2byte. In testByte() worden de bytes gewoon gealloceerd als ints (iconst maakt een int aan, lconst een long, fconst een float, bconst bestaat gewoon niet). In Java heeft het dus 0 nut om voor enkele bytes een byte type te gebruiken; daar wordt gewoon botweg een int van gemaakt.

[ Voor 48% gewijzigd door Hydra op 20-03-2009 15:55 ]

[farlane]

Voor zover ik kan beoordelen is de aanname dat het gebruik van een datatype kleiner dan de native grootte op de CPU niet sneller is dan gebruik van de native grootte.

Natuurlijk zijn er uitzonderingen, een 8051 bijv heeft instructies voor een bitadressable geheugenbereik die sneller zijn dan het maskeren van een bit in een octet.

[RobIII]

Ik vind het vooral jammer dat we niets meer horen van TS...

[Phyxion]

Ik denk niet dat het aan performance iets scheelt, het zal misschien wel in geheugen schelen, ik denk niet dat C# alles intern omzet naar een int32 of hoger.
Heb ook MSDN hier op afgezocht maar kon er eigenlijk niks over vinden.

[Jrz]

farlane schreef op zondag 22 maart 2009 @ 13:08:
Voor zover ik kan beoordelen is de aanname dat het gebruik van een datatype kleiner dan de native grootte op de CPU niet sneller is dan gebruik van de native grootte.

Natuurlijk zijn er uitzonderingen, een 8051 bijv heeft instructies voor een bitadressable geheugenbereik die sneller zijn dan het maskeren van een bit in een octet.

Yup. Maar voor size optimalisatie heeft het wel voordelen om een byte te gebruiken natuurlijk

[TheGhostInc]

farlane schreef op zondag 22 maart 2009 @ 13:08:
Voor zover ik kan beoordelen is de aanname dat het gebruik van een datatype kleiner dan de native grootte op de CPU niet sneller is dan gebruik van de native grootte.

Natuurlijk zijn er uitzonderingen, een 8051 bijv heeft instructies voor een bitadressable geheugenbereik die sneller zijn dan het maskeren van een bit in een octet.

Hierbij ben je aan het werk met assembly en al niet meer met een hogere taal.
De talen die hierboven worden genoemd zijn allemaal (flink) hogere talen, waarbij er meer dan alleen een compiler aan het werk is. De instructies die Java gebruikt voor INT zouden (theoretisch) in de VM naar bytes omgezet kunnen worden, daarna verwerkt, en weer terug naar INT vertaald kunnen worden.

Elke generatie processoren/ontwikkeltalen verder is de kans dat je nog iets zinnigs kunt maken van wat de processor intern doet een stapje minder. Want het woord brancheprediction is hier nog niet gevallen, en met de huidige pipeline lengtes van 12 of meer, is de penalty voor een foute voorspelling al fors groter dan de enkele instructie extra die hier wordt genoemd.
Aangezien je vaak iets doet met de uitkomst van je byte berekeningen, zou je de branchepredictor weleens volledig op het verkeerde been kunnen zetten door bytes ipv integers te gebruiken. Voorbeeldje:

code:

byte a = 129
byte b =  64
a = a + a (= 258 -> 2)
intern komt er nu een stap van integer naar byte, dus a gaat van 258 naar 2
if (a > b) (=FALSE)

De branchepredictor had a waarschijnlijk gegokt op de uitkomst uit de integer vergelijking, wat 258 was (=TRUE), maar door het omzetten naar een byte klapt de if statement om.
Afhankelijk hoe de omzetting van integer naar byte wordt gedaan, kan de branchepredictor dit mogelijk niet aan zien komen (bijvoorbeeld als de laatste 3 bytes van de integer naar 0 worden gezet).
Bespaar je misschien 3 bytes, maar is de code 10-100x langzamer.

RobIII schreef op zondag 22 maart 2009 @ 13:21:
Ik vind het vooral jammer dat we niets meer horen van TS...

Als wij ons maar vermaken
De vraag is al dusdanig complex dat het eigenlijk niet gesteld kan worden in 8 regels, hierboven geef ik een (mogelijk) extra aspect aan van de problemen die het zou kunnen geven. Iemand met meer inzicht in compilers zal er nog wel een paar kunnen geven.

[bomberboy]

TheGhostInc schreef op zondag 22 maart 2009 @ 13:59:
Elke generatie processoren/ontwikkeltalen verder is de kans dat je nog iets zinnigs kunt maken van wat de processor intern doet een stapje minder. Want het woord brancheprediction is hier nog niet gevallen, en met de huidige pipeline lengtes van 12 of meer, is de penalty voor een foute voorspelling al fors groter dan de enkele instructie extra die hier wordt genoemd.

Akkoord dat door alle extra abstractielagen het moeilijker wordt om in alle situaties te gaan voorspellen wat er intern gebeurd. Gooi daar ook nog de Just-in-time compiler bij en het wordt zeker moeilijk.
Het zou me echter wel heel sterk verwonderen dat dit voor de branchpredictor ook maar iets uitmaakt.

Aangezien je vaak iets doet met de uitkomst van je byte berekeningen, zou je de branchepredictor weleens volledig op het verkeerde been kunnen zetten door bytes ipv integers te gebruiken. Voorbeeldje:

code:

byte a = 129
byte b =  64
a = a + a (= 258 -> 2)
intern komt er nu een stap van integer naar byte, dus a gaat van 258 naar 2
if (a > b) (=FALSE)

De branchepredictor had a waarschijnlijk gegokt op de uitkomst uit de integer vergelijking, wat 258 was (=TRUE), maar door het omzetten naar een byte klapt de if statement om.

Ik moet toegeven dat ik niet perfect op de hoogte ben van hoe alle moderne branch-predictors werken, maar vziw gebruiken ze allemaal een soort van geschiedenis. (Behalve de heel simpele die gezoon altijd true veronderstellen.)

Welke conditie er dan ook geëvalueerd wordt, de predictor maakt zijn beslissing gebaseerd op vorige beslissingen. Het maakt dus doorgaans niets uit welke parameters er juist geëvalueerd worden, wel de geheugenadressen waarop die parameters staan en de voorgaande beslissingen die op basis daarvan genomen worden. Typisch op basis van een waarde in een tabel, en die waarde wordt aangepast bij de branch zelf.

Het voorbeeld dat je geeft suggereert ergens dat de branchpredictor weet welke logica juist uitgevoerd wordt en met welke parameters, maar meestal heeft dat geen betekenis voor de branchpredictor. Die rekent zelf immers niets uit. Indien die dat wel zou doen kan je bijna net zo goed geen branch-prediction doen.
Maar indien je hier meer van weet leer ik graag bij

Afhankelijk hoe de omzetting van integer naar byte wordt gedaan, kan de branchepredictor dit mogelijk niet aan zien komen (bijvoorbeeld als de laatste 3 bytes van de integer naar 0 worden gezet).
Bespaar je misschien 3 bytes, maar is de code 10-100x langzamer.

Zelfs indien het toch zo zo zijn dat dit een invloed heeft, dan wil dit nog steeds niet zeggen dat de code veel langzamer wordt, dat hangt te sterk af van de code in kwestie. Typisch wanneer je met bytes werkt zijn de getallen waarmee je werkt ook kleiner dan 256 of 127 indien signed. Vertrouwen op overflow-gedrag lijkt me zowiezo een beetje verkeerd want het maakt de code er niet duidelijker op.
Maar zelfs al maakt je branch-predictor in dit geval iedere keer de verkeerde beslissing, als je in dat geval van die byte-array telkens 1000 keer een kopie maakt zal het wel degelijk veel sneller zijn dan wanneer je al die data in een int-array zou stoppen.

Maar het blijft natuurlijk onmogelijk om er in het algemene geval uitspraken over te doen, want het is al redelijk low level performance tuning. De laatste keer dat ik zelf voordeel gehaald heb uit deze details was bij de GoT programming contest

[TheGhostInc]

bomberboy schreef op zondag 22 maart 2009 @ 14:58:
[...]
Ik moet toegeven dat ik niet perfect op de hoogte ben van hoe alle moderne branch-predictors werken, maar vziw gebruiken ze allemaal een soort van geschiedenis. (Behalve de heel simpele die gezoon altijd true veronderstellen.)

Welke conditie er dan ook geëvalueerd wordt, de predictor maakt zijn beslissing gebaseerd op vorige beslissingen. Het maakt dus doorgaans niets uit welke parameters er juist geëvalueerd worden, wel de geheugenadressen waarop die parameters staan en de voorgaande beslissingen die op basis daarvan genomen worden. Typisch op basis van een waarde in een tabel, en die waarde wordt aangepast bij de branch zelf.

Het voorbeeld dat je geeft suggereert ergens dat de branchpredictor weet welke logica juist uitgevoerd wordt en met welke parameters, maar meestal heeft dat geen betekenis voor de branchpredictor. Die rekent zelf immers niets uit. Indien die dat wel zou doen kan je bijna net zo goed geen branch-prediction doen.
Maar indien je hier meer van weet leer ik graag bij
[...]

Je gaat voor mij nu ver over de grens tussen weten en "ergens gehoord hebben", dus pin me hier niet op vast

Een branch predictor zal de logica voor een voorwaardelijke geheugensprong wel (gedeeltelijk) moeten bezitten om aan de hand daarvan een keuze te maken. Hoe het evalueren van de voorwaarden precies gebeurd, dat weet ik niet, en dan kom je op het terrein waar de mannen van AMD en Intel de hele dag mee bezig zijn. Overigens is de pipeline ook niet voor niks zo lang, zodat een branchepredictor de tijd heeft om er wat mee te doen.

Je hebt volgens mij wel gelijk dat het ding eerder evalueert dan echt rekent, maar zeker als je een if statement hebt dat vrij random aan het wisselen is, dan kan de branchepredictor er ook niks meer mee, maar gelukkig zijn de meeste programma's makkelijker te voorspellen. Soms staat er weleens iets over cache hits and branchepredictor hits bij nieuwe architecturen, dan zit je midden in deze materie te rommelen (Cache hits gaat ook over de voorspelbaarheid van voorwaardelijke geheugensprongen).

Over het stukje over je byte array, je kunt gelijk hebben, maar aan de andere kant kan het zijn dat de CPU voor elke write toch 32bits verplaatst, doordat de busgrootte niks anders toestaat. Of je komt misschien in de legacy x86 code terecht die wel met bytes ipv integers om kan gaan (dit hangt af van de compiler btw.). Leuke discussie, maar misschien dat iemand een linkje naar een mooi artikel heeft, want we gaan nu hard naar koffiedik kijken toe.

[Edit]
Met de nieuwe instructiesets als MMX, SSE en x64 zie je dat je flinke performance winst kunt halen tov de "normale" instructiesets. Vooral bij handelingen op grote datasets. Dit geeft ook wel aan dat onderin de range, bij de bitjes, bytjes en integers/floats de rek er wel een beetje uit is. Door van 32bit -> 8bit te gaan ga je tegen de ontwikkeling in, die meer van 32bit -> (64) 128/256bit is. Grotere geheugenbereiken uitlezen gaat ook fors sneller dan per locatie.

[ Voor 8% gewijzigd door TheGhostInc op 22-03-2009 16:40 . Reden: MMX, SSE & x84 ]

[Phyxion]

TheGhostInc schreef op zondag 22 maart 2009 @ 13:59:
[...]

Hierbij ben je aan het werk met assembly en al niet meer met een hogere taal.
De talen die hierboven worden genoemd zijn allemaal (flink) hogere talen, waarbij er meer dan alleen een compiler aan het werk is. De instructies die Java gebruikt voor INT zouden (theoretisch) in de VM naar bytes omgezet kunnen worden, daarna verwerkt, en weer terug naar INT vertaald kunnen worden.

Elke generatie processoren/ontwikkeltalen verder is de kans dat je nog iets zinnigs kunt maken van wat de processor intern doet een stapje minder. Want het woord brancheprediction is hier nog niet gevallen, en met de huidige pipeline lengtes van 12 of meer, is de penalty voor een foute voorspelling al fors groter dan de enkele instructie extra die hier wordt genoemd.
Aangezien je vaak iets doet met de uitkomst van je byte berekeningen, zou je de branchepredictor weleens volledig op het verkeerde been kunnen zetten door bytes ipv integers te gebruiken. Voorbeeldje:

code:

byte a = 129
byte b =  64
a = a + a (= 258 -> 2)
intern komt er nu een stap van integer naar byte, dus a gaat van 258 naar 2
if (a > b) (=FALSE)

De branchepredictor had a waarschijnlijk gegokt op de uitkomst uit de integer vergelijking, wat 258 was (=TRUE), maar door het omzetten naar een byte klapt de if statement om.
Afhankelijk hoe de omzetting van integer naar byte wordt gedaan, kan de branchepredictor dit mogelijk niet aan zien komen (bijvoorbeeld als de laatste 3 bytes van de integer naar 0 worden gezet).
Bespaar je misschien 3 bytes, maar is de code 10-100x langzamer.


[...]

Als wij ons maar vermaken
De vraag is al dusdanig complex dat het eigenlijk niet gesteld kan worden in 8 regels, hierboven geef ik een (mogelijk) extra aspect aan van de problemen die het zou kunnen geven. Iemand met meer inzicht in compilers zal er nog wel een paar kunnen geven.

Erg leuk maar TS heeft het over C# niet over Java. De vraag is of iemand ook weet wat C# met byte, char, short etc doet

[TheGhostInc]

Phyxion schreef op zondag 22 maart 2009 @ 16:37:
[...]

Erg leuk maar TS heeft het over C# niet over Java. De vraag is of iemand ook weet wat C# met byte, char, short etc doet

Zelfs al weet je wat C# of Java er intern mee doet, dan weet je nog niet wat je CPU er uiteindelijk mee doet. Ik had het over low-level performance richting assembly/microcode niveau. Om dan naar C# te gaan kom je nog wel 2 of 3 laagjes tegen.

Moraal van het verhaal is dan ook dat je C# en Java niet meer 1 op 1 kunt vergelijken qua performance met de performance die een CPU zou halen als je die code rechtstreeks op een CPU zou uitvoeren. De TS had het erover dat het logischer is om 8bits ipv 32bits te gebruiken, ik gaf aan dat ik het aannemelijk kon maken dat er meer aan de hand was/kon zijn.
Benchmarken of de VM/interpreteer dinges ontleden is hier dan ook zinniger dan de CPU erbij betrekken (daarin heb jij dan ook gelijk, maar de TS vroeg daar naar), maar benchmarken zoeken of zelf doen is de enige oplossing voor zijn vraag.

[ Voor 12% gewijzigd door TheGhostInc op 22-03-2009 16:49 ]

[CoolGamer]

In C# werkt het hetzelfde als Java, alleen moet je die cast naar byte zelf doen anders compileert het niet.

C#:

static void Main()
{
    AddInt();
    AddByte();
}
static void AddInt()
{
    int x = 1;
    int y = 5;
    int z = x + y;
}

static void AddByte()
{
    byte x = 1;
    byte y = 5;
    //byte z = x + y; //wont compile
    byte z = (byte) (x + y);
}

GAS:

static void AddInt()
        {
[..]     
            int x = 1;
00000038  mov         dword ptr [ebp-3Ch],1 
            int y = 5;
0000003f  mov         dword ptr [ebp-40h],5 
            int z = x + y;
00000046  mov         eax,dword ptr [ebp-3Ch] ; zet 1 in eax
00000049  add         eax,dword ptr [ebp-40h] ; tel 5 bij 1 op.
0000004c  mov         dword ptr [ebp-44h],eax  ; zet 6 in z
        }

GAS:

        static void AddByte()
        {
[..]
            byte x = 1;
0000003e  mov         dword ptr [ebp-3Ch],1 
            byte y = 5;
00000045  mov         dword ptr [ebp-40h],5 
            //byte z = x + y; //wont compile
            byte z = (byte) (x + y);
0000004c  mov         eax,dword ptr [ebp-3Ch] ; zet 1 in eax
0000004f  add         eax,dword ptr [ebp-40h]  ; tel 5 bij 1 op
00000052  and         eax,0FFh ; gooi alles behalve de byte (de cast)
00000057  mov         dword ptr [ebp-44h],eax  ; zet 6 in z
        }

Dus een int is iets sneller, maar niks significants. Kwa geheugengebruik scheelt het helemaal niks.

[TheGhostInc]

TheCoolGamer schreef op zondag 22 maart 2009 @ 16:51:
[...]
Dus een int is iets sneller, maar niks significants. Kwa geheugengebruik scheelt het helemaal niks.

Die ASM waar jij het over hebt, dat is toch de bytecode die door het .NET framework weer word uitgevoerd?

.

code:

00000052  and         eax,0FFh ; gooi alles behalve de byte (de cast)

Dit is trouwens de regel waarover ik het had qua branche prediction, die kan "vervelend" geëvalueerd worden, maar dan moet je een branche predictor uitgebreid bekijken. Hoewel ik niet uitsluit dat Intel dit als standaard mogelijkheid ziet.

[CoolGamer]

TheGhostInc schreef op zondag 22 maart 2009 @ 17:37:
[...]


Die ASM waar jij het over hebt, dat is toch de bytecode die door het .NET framework weer word uitgevoerd?

Nee, dit is machinecode. Het is daarvoor natuurlijk wel opgeslagen als bytecode, maar de uiteindelijke machinecode is natuurlijk veel interessanter om te kijken kwa performance.

Met optimalisatie levert het dit op:

GAS:

        static void AddInt()
        {
            xi = 1;
[..]
mov         dword ptr ds:[002E90E8h],1 
            yi = 5;
mov         dword ptr ds:[002E90ECh],5 
            zi = xi + yi;
mov         eax,dword ptr ds:[002E90E8h] 
add         eax,dword ptr ds:[002E90ECh] 
mov         dword ptr ds:[002E90F0h],eax 
        }
        static void AddByte()
        {
            xb = 1;
[..]
mov         byte ptr ds:[002E90F4h],1 
            yb = 5;
mov         byte ptr ds:[002E90F8h],5 
            //byte z = x + y; //wont compile
            zb = (byte) (xb + yb);
movzx       eax,byte ptr ds:[002E90F4h] 
movzx       edx,byte ptr ds:[002E90F8h] 
add         eax,edx 
and         eax,0FFh 
mov         byte ptr ds:[002E90FCh],al 
        }

Dan wordt bij het inlezen uit het geheugen wel een andere instructie gebruikt (desondanks blijft voor een byte 4 bytes gereserveerd), maar het lijkt me sterk dat dit enigszins een significant verschil kan veroorzaken. Ook omdat die AND nog steeds nodig is omdat alles achter de schermen (lees: in de processor) allemaal met ints gaat..

[Soultaker]

Welke code gebruik je nu dan? Lijkt me dat als je de code uit deze post letterlijk overneemt een beetje compiler gelijk door zou moeten hebben dat de hele body uit dode code bestaat en weggeoptimaliseerd kan worden.

Verder lijkt het met ten eerste sterk dat de compiler die byte-conversie uitvoert terwijl die compleet overbodig is aangezien toch alleen maar de laagste 8 bits gemoved worden in de volgende instructie, en ten tweede nog veel sterker dat al die constanten niet gepropageert zouden worden!

Ik denk dus dat de code nog niet echt geoptimaliseerd is, of anders stelt optimalisatie in .NET bar weinig voor.

[.oisyn]

TheGhostInc schreef op zondag 22 maart 2009 @ 13:59:
Aangezien je vaak iets doet met de uitkomst van je byte berekeningen, zou je de branchepredictor weleens volledig op het verkeerde been kunnen zetten door bytes ipv integers te gebruiken. Voorbeeldje:

code:

byte a = 129
byte b =  64
a = a + a (= 258 -> 2)
intern komt er nu een stap van integer naar byte, dus a gaat van 258 naar 2
if (a > b) (=FALSE)

De branchepredictor had a waarschijnlijk gegokt op de uitkomst uit de integer vergelijking, wat 258 was (=TRUE), maar door het omzetten naar een byte klapt de if statement om.

Sorry hoor, maar heb je je weleens verdiept in hoe een branch predictor werkt? Niet zoals jij beschrijft, en al zou die wel zo werken dan slaat het nergens op dat de predictor "denkt" dat de uitkomst 258 gaat zijn omdat hij tenslotte in een byte staat, die geen waarde van 258 aan kan nemen.

Branch predictors werken doorgaans louter op de daadwerkelijke branching geschiedenis zoals bomberboy beschreef, en niet wat de condities zijn van de branch. Feitelijk zijn er maar 2 situaties bij een conditional branch - wel branchen en niet branchen. De uitkomst van een branch wordt verwerkt in een state die geassocieerd is met een specifieke conditional branch, die bij de volgende iteratie van dezelfde branch wordt gebruikt om de prediction te doen. Een vrij simpele implementatie hiervan houdt gewoonweg de laatste uitkomst bij, en doet bij de volgende iteratie precies hetzelfde als wat ie als laatst gedaan heeft. Was er toen een branch, dan predict hij dat nu weer, anders niet. Een iets ingewikkeldere implementatie die vrij common is is het bijhouden van een 2 bits counter. Een branch is een +1 op de counter, geen branch is -1. Verder loopt de counter niet over, dus een -1 op een 0 blijft een 0 en een +1 op een 3 blijft een 3. Er wordt een branch gepredict als de counter 2 of 3 is. Op die manier zal 1 zeldzame verandering van de conditional branch niet zoveel roet in het eten gooien - alleen die ene branch wordt dan mispredict, de volgende niet.
Leesvoer

Met de nieuwe instructiesets als MMX, SSE en x64 zie je dat je flinke performance winst kunt halen tov de "normale" instructiesets. Vooral bij handelingen op grote datasets. Dit geeft ook wel aan dat onderin de range, bij de bitjes, bytjes en integers/floats de rek er wel een beetje uit is. Door van 32bit -> 8bit te gaan ga je tegen de ontwikkeling in, die meer van 32bit -> (64) 128/256bit is. Grotere geheugenbereiken uitlezen gaat ook fors sneller dan per locatie.

En daarbij vergeet je dat je met SSE ook bytes kan verwerken. En in een 128 bits SSE register passen maar 4 ints, terwijl er ook 16 bytes in passen. Als de operaties op alle variabelen hetzelfde is kun je dus 4x zoveel data verwerken in dezelfde tijd.

Terug naar of een byte efficienter is. Hier in de topic wordt vooral geconcentreerd op het bewerken van de byte, maar niet op de daadwerkelijke opslag. Het rekenen met bytes zal idd niet zo heel veel verschillen met ints. Maar er passen wel meer bytes in dezelfde chunk memory dan ints, wat betekent dat je minder geheugen touched en daardoor minder cache misses hebt. Het verschil is substantieel als je je gehele applicatie eigenlijk 75% minder geheugen had kunnen laten gebruiken

[ Voor 12% gewijzigd door .oisyn op 23-03-2009 02:32 ]

[TheGhostInc]

.oisyn schreef op maandag 23 maart 2009 @ 02:20:
[...]
Sorry hoor, maar heb je je weleens verdiept in hoe een branch predictor werkt? Niet zoals jij beschrijft, en al zou die wel zo werken dan slaat het nergens op dat de predictor "denkt" dat de uitkomst 258 gaat zijn omdat hij tenslotte in een byte staat, die geen waarde van 258 aan kan nemen.

De waarde wordt in het voorbeeld duidelijk eerst in een integer opgeslagen, "sorry hoor" maar die kan prima 258 worden.

Branch predictors werken doorgaans louter op de daadwerkelijke branching geschiedenis zoals bomberboy beschreef, en niet wat de condities zijn van de branch. Feitelijk zijn er maar 2 situaties bij een conditional branch - wel branchen en niet branchen. De uitkomst van een branch wordt verwerkt in een state die geassocieerd is met een specifieke conditional branch, die bij de volgende iteratie van dezelfde branch wordt gebruikt om de prediction te doen. Een vrij simpele implementatie hiervan houdt gewoonweg de laatste uitkomst bij, en doet bij de volgende iteratie precies hetzelfde als wat ie als laatst gedaan heeft. Was er toen een branch, dan predict hij dat nu weer, anders niet. Een iets ingewikkeldere implementatie die vrij common is is het bijhouden van een 2 bits counter. Een branch is een +1 op de counter, geen branch is -1. Verder loopt de counter niet over, dus een -1 op een 0 blijft een 0 en een +1 op een 3 blijft een 3. Er wordt een branch gepredict als de counter 2 of 3 is. Op die manier zal 1 zeldzame verandering van de conditional branch niet zoveel roet in het eten gooien - alleen die ene branch wordt dan mispredict, de volgende niet.
Leesvoer

Wat ik bedoelde aan te geven is dat waarschijnlijk de recentste processoren een dusdanig complexe branch predictor hebben dat optimalisaties die op je 286 nog werken mogelijk tegen je werken bij je Core 2 Quad processor.

Als je overigens leest over Overriding branch prediction, is de situatie die we hier creeeren mogelijk exact de situatie waardoor de branchepredictor er niks meer mee kan. Door je bewerking op de integer naar byte (die altijd hetzelfde is) is de instructie voor je conditional branch compleet niet informatief voor je branch prediction, een of twee regels ervoor zal de (voor de branchepredictor) interessante instructies langs zijn gekomen.
Zeker als je hele code is vergeven van dit soort omzettingen "ziet" je branchepredictor constant hetzelfde patroon, terwijl het wel andere branches kunnen zijn.

En daarbij vergeet je dat je met SSE ook bytes kan verwerken. En in een 128 bits SSE register passen maar 4 ints, terwijl er ook 16 bytes in passen. Als de operaties op alle variabelen hetzelfde is kun je dus 4x zoveel data verwerken in dezelfde tijd.

Dit is dezelfde logica als de TS gebruikt, iedereen snapt dat er in een 128 bit register 4 32bit integers passen. Maar heb je hier iets aan met je C# code, of ben je dan C of Assembly aan het schrijven?

Terug naar of een byte efficienter is. Hier in de topic wordt vooral geconcentreerd op het bewerken van de byte, maar niet op de daadwerkelijke opslag. Het rekenen met bytes zal idd niet zo heel veel verschillen met ints. Maar er passen wel meer bytes in dezelfde chunk memory dan ints, wat betekent dat je minder geheugen touched en daardoor minder cache misses hebt. Het verschil is substantieel als je je gehele applicatie eigenlijk 75% minder geheugen had kunnen laten gebruiken

Deze redenatie is al langs gekomen en kan inderdaad betekenen dat het sneller is. Alleen erg jammer dat C# toch alles opslaat als integer, zoals een paar posts hierboven staat. Je verhaal gaat dus niet op voor het voorbeeld van de TS, hoewel de cache misses inderdaad een extra penalty hadden kunnen opleveren.
Mijn branche prediction kennis is beperkt, hierdoor schrijf ik dingen misschien fout op, ik was alleen benieuwd of iemand het balletje dat ik opgooide kon inkoppen. Ik heb weer wat bijgeleerd, maar welk effect de branche predictor heeft daar ben ik nog niet over uit.

[TheGhostInc]

.oisyn schreef op maandag 23 maart 2009 @ 02:20:
[...]
En daarbij vergeet je dat je met SSE ook bytes kan verwerken. En in een 128 bits SSE register passen maar 4 ints, terwijl er ook 16 bytes in passen. Als de operaties op alle variabelen hetzelfde is kun je dus 4x zoveel data verwerken in dezelfde tijd.
[...]

Vraagje hierover, want dit is analoog aan 4 bytes in een integer stoppen.
Als least significant byte (of int) "overflowed" dan is de volgende byte met 1 of meer opgehoogd. Zijn er instructies die hiervoor opletten, of moet je die situatie afvangen?
Als je hier zelf mee moet rommelen betekent dat je wel geheugenruimte wint, maar wel extra processor power nodig hebt, of zeker weet dat het nooit kan voorkomen?

[RobIII]

TheGhostInc schreef op maandag 23 maart 2009 @ 15:59:
Als least significant byte (of int) "overflowed"

Ik denk dat je de MSB of Most Significant Bit bedoelt?

TheGhostInc schreef op maandag 23 maart 2009 @ 15:59:
Zijn er instructies die hiervoor opletten, of moet je die situatie afvangen?

De processor heeft een flag (of flags) daarvoor (als een bewerking een overflow veroorzaakt), maar die CPU weet natuurlijk ook niet dat je 4 bytes in een 'int' probeert te werken dus (AFAIK althans) zul je dit zelf moeten vangen. Ik kan me hierin vergissen, maar dat zie je dan zometeen wel in een post van .oisyn

[ Voor 6% gewijzigd door RobIII op 23-03-2009 16:10 ]

[.oisyn]

TheGhostInc schreef op maandag 23 maart 2009 @ 15:49:
Dit is dezelfde logica als de TS gebruikt, iedereen snapt dat er in een 128 bit register 4 32bit integers passen. Maar heb je hier iets aan met je C# code, of ben je dan C of Assembly aan het schrijven?

Waarom zou de .Net JIT compiler geen SSE code kunnen produceren? Het is niet ondenkelijk dat als jij over een array itereert en daarbij voor elk element dezelfde berekening toepast (bijv. 5 erbij optellen) dat de .Net compiler dat naar PADDB instructies omzet op een SSE2 platform.

Deze redenatie is al langs gekomen en kan inderdaad betekenen dat het sneller is. Alleen erg jammer dat C# toch alles opslaat als integer, zoals een paar posts hierboven staat.

Alles, of alleen locals? Hier in de topic worden alleen locals gedemonstreerd, niet bytes als members van classes of structs. En daar gaat het nou juist om.

TheGhostInc schreef op maandag 23 maart 2009 @ 15:59:
[...]

Vraagje hierover, want dit is analoog aan 4 bytes in een integer stoppen.
Als least significant byte (of int) "overflowed" dan is de volgende byte met 1 of meer opgehoogd. Zijn er instructies die hiervoor opletten, of moet je die situatie afvangen?
Als je hier zelf mee moet rommelen betekent dat je wel geheugenruimte wint, maar wel extra processor power nodig hebt, of zeker weet dat het nooit kan voorkomen?

SSE registers zijn geen 128 bits ints, maar een packed datastructuur van gelijke elementen. De representatie van die elementen is afhankelijk van de instructies die je erop loslaat. De eerdergenoemde PADDB behandelt een register als 16 losse bytes, maar je hebt ook PADDW, PADDD en PADDQ instructies voor resp. 8 word, 4 dword en 2 qword ints, en ADDPS en ADDPD voor resp. 4 floats en 2 doubles. Als een byte overflowed dan wrapt ie gewoon zoals je dat bij een normale byte zou verwachten. Het is niet dat de byte ernaast daar ineens last van krijgt oid.

RobIII schreef op maandag 23 maart 2009 @ 16:08:
De processor heeft een flag (of flags) daarvoor (als een bewerking een overflow veroorzaakt), maar die CPU weet natuurlijk ook niet dat je 4 bytes in een 'int' probeert te werken dus (AFAIK althans) zul je dit zelf moeten vangen. Ik kan me hierin vergissen, maar dat zie je dan zometeen wel in een post van .oisyn

Whoa, je bent helderziend . Dit geldt alleen voor bewerkingen op de normale int registers, niet op SSE registers.

[ Voor 13% gewijzigd door .oisyn op 23-03-2009 16:29 ]

[Verwijderd]

RobIII schreef op zondag 22 maart 2009 @ 13:21:
Ik vind het vooral jammer dat we niets meer horen van TS...

was van het weekend niet heel erg fit vandaar

Ben nog op zoek geweest naar het document waar ik er toen wat over gelezen heb maar kan hem nog niet vinden.

[RobIII]

.oisyn schreef op maandag 23 maart 2009 @ 16:20:
Whoa, je bent helderziend

Ik wist dat je dat ging zeggen

.oisyn schreef op maandag 23 maart 2009 @ 16:20:
Dit geldt alleen voor bewerkingen op de normale int registers, niet op SSE registers.

Tegen het SSE tijdperk ben ik afgehaakt (wat ik erg jammer vind overigens) om me te (kunnen) verdiepen in de interne werking van CPU's maar ik had inderdaad al zo'n vermoeden. Toch maar weer eens gaan inlezen

Verwijderd schreef op maandag 23 maart 2009 @ 17:57:
was van het weekend niet heel erg fit vandaar

Het heerst schijnbaar. * RobIII is ook kwakkelig

[ Voor 24% gewijzigd door RobIII op 23-03-2009 18:06 ]

[RayNbow]

RobIII schreef op maandag 23 maart 2009 @ 18:05:
[...]

Tegen het SSE tijdperk ben ik afgehaakt (wat ik erg jammer vind overigens) om me te (kunnen) verdiepen in de interne werking van CPU's maar ik had inderdaad al zo'n vermoeden. Toch maar weer eens gaan inlezen

offtopic:
Zo, lekker glimmend... mijn oude IA-32-only hard copy glimt niet zo erg

[TheGhostInc]

.oisyn schreef op maandag 23 maart 2009 @ 16:20:
[...]

Thanks, heb weer het nodige bijgeleerd.

RobIII, je kunt op je foto de dikte niet goed zien, misschien heb je wel alleen de executive summary
Over je MSB opmerking, ik bedoelde wel de least significant byte, maar ik zal de volgende keer een andere uitdrukking gebruiken, want zo gaan mensen er niks van snappen.

[RobIII]

TheGhostInc schreef op dinsdag 24 maart 2009 @ 00:16:
RobIII, je kunt op je foto de dikte niet goed zien, misschien heb je wel alleen de executive summary

Het gaat niet om de dikte, maar om wat je er mee doet... Euh...
Klik
Overigens; die krijg je gratis en voor niets van Intel; kost je alleen een mailtje en *plop* ze liggen een week later in je bus. Niet eens verzendkosten

TheGhostInc schreef op dinsdag 24 maart 2009 @ 00:16:
Over je MSB opmerking, ik bedoelde wel de least significant byte, maar ik zal de volgende keer een andere uitdrukking gebruiken, want zo gaan mensen er niks van snappen.

Je bedoelt een MSB die overflowed in een (theoretische) naastliggende LSB van een 2e byte links er langs dan ofzo? De MSB zit "links", de LSB rechts. Zie eventueel MSB/LSB

[ Voor 9% gewijzigd door RobIII op 24-03-2009 00:24 ]

[Soultaker]

RobIII schreef op dinsdag 24 maart 2009 @ 00:22:
Overigens; die krijg je gratis en voor niets van Intel; kost je alleen een mailtje en *plop* ze liggen een week later in je bus. Niet eens verzendkosten

Ah, doen ze dat weer/nog steeds? Ik heb jaren geleden ook eens zoiets aangevraagd, vandaar dat ik een soortgelijk stapeltje heb uit de Netburst-tijd, en die komt nog wel eens van pas.

[RobIII]

Soultaker schreef op dinsdag 24 maart 2009 @ 00:42:
Ah, doen ze dat weer/nog steeds?

AFAIK nog steeds.

[Woy]

Ik heb een tijdje geleden de PDF's maar gedownload, ik ga ze toch niet helemaal doorlezen, dus PDF is ook makkelijker zoeken als je wat nodig hebt

[TheGhostInc]

RobIII schreef op dinsdag 24 maart 2009 @ 00:22:
[...]
Je bedoelt een MSB die overflowed in een (theoretische) naastliggende LSB van een 2e byte links er langs dan ofzo? De MSB zit "links", de LSB rechts. Zie eventueel MSB/LSB

Precies, overigens links of rechts heeft ook te maken met big en little endian. Je foto is nu een stuk ... uhm ... duidelijker.

[H!GHGuY]

Maak het nou even simpel: gebruik het datatype waarvoor het bedoeld is naargelang de range/precisie die het type heeft of de functie die eraan toegekend wordt (bvb een char is 16bit in C#, net zoals een short, maar men je gebruikt wel chars voor tekens).

Als je echt een speed-up nodig hebt via het gebruik van andere datatypes, dan:
- was je uberhaupt al niet in een taal als C#/Java bezig (voor de fanboys: ik zeg hiermee niet dat de talen traag zijn, maar dat je er niet zelf SSE/MMX/... instructies op kan gaan programmeren)
- zou je weten welke speedups er mee verbonden kunnen zijn
- had je al heel goed geprofiled en was dit een laatste stap om die laatste procentjes uit je algoritme te halen

Conclusie: kies je datatype adhv de range/precisie of de specifieke functie (of welk ander relevant criterium je nodig acht).