Type Byte

BlitzMax Forums/BlitzMax Beginners Area/Type Byte

H&K	(Posted 2006) [#1]

Has there always been a type BYTE?

I could have sworn that there wasnt a type Byte. Yet there is. Why would I think that there wasnt a type byte?

FlameDuck

(Posted 2006) [#2]

Has there always been a type BYTE?

Yes. Just don't use it.

Azathoth

(Posted 2006) [#3]

What about in user types or arrays?

FlameDuck

(Posted 2006) [#4]

You might be able to get away with it in arrays, but in general, unless it's for some sort of interoperability with legacy software that you simply must use, I'd advise against it.

Brucey

(Posted 2006) [#5]

The only time I use Byte is with the word Ptr on the end - Byte Ptr.
But then that is something altogether entirely different.

Are there any "good" reasons why one might *want* to use a Byte type?

SculptureOfSoul

(Posted 2006) [#6]

I'm using bytes all over the place in my tile engine. No need to waste 3 extra bytes on an int when I need to store 6 draw flags.

Considering the number of tiles and the size of my map, I need to save every byte I can.

Dreamora

(Posted 2006) [#7]

No there is no reason to use byte.
While it might sound nice from the ram waste point of view, Byte are significantly slower than Int.
So you should really only use them if it is in a speed uncritical part or for interfacing with C

tonyg

(Posted 2006) [#8]

Can somebody provide some example code showing how much slower bytes are than ints? I agree that they're slower but is it really by that much? Isn't it another trade-off between space used vs performance?

SculptureOfSoul

(Posted 2006) [#9]

Why are they slower?

CS_TBL

(Posted 2006) [#10]

Internally they're uplifted to INT for the calculations. So if you're directly using an INT then you save this byte->int conversion..

H&K	(Posted 2006) [#11]

If Byte is just a cutdown Int, then I probably read about it and promptly ignored its existance.

Still it was a bit weird.

Dreamora

(Posted 2006) [#12]

Regular OS today are 32Bit
For that reason all operations (especially in GCC) are optimised in 32Bit which is the reason Int / Float are the prefered data type for anything speed critical.
With 512MB+ of RAM, 3 Byte more or less don't make a difference, not even with 1000 or 10000 objects of the type

SculptureOfSoul

(Posted 2006) [#13]

I'm sure it is impossible to quantify an exact amount, but does anyone know approximately how much slower using a byte or short would be, in general, in real world applications.

If there's a noticeable difference I'll just convert my current byte fields (which only need a range of 0-255) to ints, but write them to disk as a byte.

It's not the RAM usage that I'm worried about in my game, it's disk space. I mean, there's a big difference between requiring 1gb of disk space, or 4gb (or more).

FlameDuck

(Posted 2006) [#14]

I'm sure it is impossible to quantify an exact amount, but does anyone know approximately how much slower using a byte or short would be, in general, in real world applications.

It is unlikely there is any real difference since bytes are most likely zero padded to be 32-bit address aligned anyway.

Type aType
	Field a:Int
	Field b:Byte
	Field c:Int
EndType

Print SizeOf( New aType)

Oh look. It prints 12.

H&K	(Posted 2006) [#15]

Thats what I said, but I said "Cut down Int" ;)

However......

Question: The compiler must deal with overflow on some level. So there must be some sort of bounds checking added to byte. (Or am i missing something here). And if there is, that must be a speed overhead. No?

Iv just checked

Type aType
	Field a:Int 
	Field b:Byte 
	Field b1:Byte
	
	Field c:Int
EndType

Print SizeOf( New aType)

Is also 12

So it might have ror and rol in there as well.

Dreamora

(Posted 2006) [#16]

Why would it need a bound checking?
Its handled the same as on it -> overflow is handled with "entering the lowest posible number" -> 255+1 = 0

Here is a little benchmark code


Rem
	Small benchmarking of byte, short vs int on access and operation
End Rem

Strict


Local bVal:Byte	= 0
Local sVal:Short = 0
Local iVal:Int = 0


Local t1:Int,t2:Int,t3:Int

' Byte test
t1 = MilliSecs()
For Local i:Int = 1 To 100000
	For Local k:Int = 1 To 100
		bVal = (bVal + Rand(1, 1000)) Mod 256
	Next
	For Local k:Int = 1 To 100
		bVal = (bVal * Rand(1, 100)) Mod 256
	Next
	For Local k:Int = 1 To 100
		bVal = (bVal Shl 1) Mod 256
	Next
Next
t1 = MilliSecs() - t1
Print "Byte Operations took: " + t1 + " milliseconds."

' Short test
t2= MilliSecs()
For Local i:Int = 1 To 100000
	For Local k:Int = 1 To 100
		sVal = (sVal + Rand(1, 1000)) Mod 256
	Next
	For Local k:Int = 1 To 100
		sVal = (sVal * Rand(1, 100)) Mod 256
	Next
	For Local k:Int = 1 To 100
		sVal = (sVal Shl 1) Mod 256
	Next
Next
t2 = MilliSecs() - t2
Print "Short Operations took: " + t2 + " milliseconds."

' Int test
t3 = MilliSecs()
For Local i:Int = 1 To 100000
	For Local k:Int = 1 To 100
		iVal = (iVal + Rand(1, 1000)) Mod 256
	Next
	For Local k:Int = 1 To 100
		iVal = (iVal * Rand(1, 100)) Mod 256
	Next
	For Local k:Int = 1 To 100
		iVal = (iVal Shl 1) Mod 256
	Next
Next
t3 = MilliSecs() - t3
Print "Integer Operations took: " + t3 + " milliseconds."

My results:

Byte Operations took: 2545 milliseconds.
Short Operations took: 2616 milliseconds.
Integer Operations took: 2553 milliseconds.

Thing to mention:

I'm working on a Core Duo T2500 @ 2Ghz with fully rebuild modules on most actual GCC version (not the one used with BM originally). So could someone on a regular system (single core, perhaps P4 3ghz or the like without rebuilt modules) test that as well?

H&K	(Posted 2006) [#17]

If it was a padded INT it would need bounds checking.
As I dont think it is a padded int, it doesnt. (It was a badly delevered NOR example)

I was pointing out that it didnt need bounds checking, because of its size. Which it would have needed if Flames suggestion about the padded ints was right.

A single byte needs the same space as an Int, two btyes need the same space as an int etc

Edit: What was sudgested was that there wouldnt be a significant increase in size. And that Bytes would be stored as INTs. If this was so there would need to be some bounds checking placed ontop of the int. As both you and I proved, this was not so.

Dreamora

(Posted 2006) [#18]

What was said is that it could be used as padded int on operations (makes sense as BM only has 3 arithmetic levels: Int, float and double).

Byteemoz

(Posted 2006) [#19]

The compiler will propably clamp the value to one byte, so

MyByte:Byte = 2000

becomes

MyByte:Int = 2000 & $FF

The benchmark (PC):

Byte Operations took: 4511 milliseconds.
Short Operations took: 4569 milliseconds.
Integer Operations took: 4488 milliseconds.

(Mac)

Byte Operations took: 3626 milliseconds.
Short Operations took: 3569 milliseconds.
Integer Operations took: 3419 milliseconds.

-- Byteemoz

tonyg

(Posted 2006) [#20]

My results...
Byte Operations took: 4019 milliseconds.
Short Operations took: 4158 milliseconds.
Integer Operations took: 4004 milliseconds.
It suggests that bytes are not 'significantly' slower but, if they take the same to store no need to use them.
Is that right?

SculptureOfSoul

(Posted 2006) [#21]

Byte Operations took: 9073 milliseconds.
Short Operations took: 9086 milliseconds.
Integer Operations took: 9029 milliseconds.

Yeah, my system is showing it's age.

ziggy

(Posted 2006) [#22]

My results:
Byte Operations took: 6047 milliseconds.
Short Operations took: 6282 milliseconds.
Integer Operations took: 6048 milliseconds.

Dreamora

(Posted 2006) [#23]

So GCC has some quite intelligent way of using them.
Good to know ... so short is the "slowest" type beside long and double naturally

CS_TBL

(Posted 2006) [#24]

AMD XP2.0 win98se 256MB, lotsa crap in mem prolly, like emule and such.. :P

debugmode:
Byte Operations took: 10734 milliseconds.
Short Operations took: 10757 milliseconds.
Integer Operations took: 10691 milliseconds.

releasemode:
Byte Operations took: 5344 milliseconds.
Short Operations took: 5355 milliseconds.
Integer Operations took: 5297 milliseconds.

So, in the end, speed does differ a bit, but is the minor difference a reason to avoid bytes for using large maps etc. to save on disk/mem-space?

Abomination

(Posted 2006) [#25]

Most computers restrict shorts and integer accesses to be �aligned�. A short must start at an even address and a integer must start at an address that is a multiple of 4.
so:

Type aType
	Field a:Int
	Field b1:Byte
	Field b2:Byte
	Field b3:Byte
	Field b4:Byte
	Field c:Int
EndType

Print SizeOf( New aType)

It's still 12

Type aType
	Field b1:Byte
	Field a:Int
	Field b2:Byte
	Field c:Int
	Field b3:Byte
	Field b4:Byte
EndType

Print SizeOf( New aType)

It's 18
So if you cluster your bytes, 4 of them take as much space as 1 integer.

ImaginaryHuman

(Posted 2006) [#26]

One example where you might want to use byte POINTERS at least is for manually manipulating 8-bit-per-component pixel data. However, in that case, you can read in a whole integer and then separate out the bytes using extra instructions - probably faster than doing 4 memory reads.