Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One nice thing about short types (i32 f32 u16 etc.) is that they can easily be extended for vector types such as f32x4 or u8x16 etc.

Consistency, conciseness and clarity (you don't have to guess much about those, once you've understood the naming scheme)



I actually have the opposite feeling. I like the non-sized type names like float extended as float4 or float4x4.

My brain wants to read f32x4 as a 32 by 4 matrix of floats.

(That being said I'd definitely be interested in trying your convention in the context of something like Rust.)


float4 is nice, but in video games, especially graphics, the vast majority of our floats are 32 bits but we also use 16 bits floats quite extensively, and in this case it is quite practical to follow the same convention. f32 -> f16 f32x4 -> f16x4

And when working on some heavily optimized SIMD code on the CPU side, I tend to use the default types even less.


My preference for float4 comes from HLSL so I'm aware. For vectors of 16 bit floats my preference would be half4 etc. (Although I do concede that in HLSL land that doesn't actually do what you want on older language versions.)

IMO including the number of bits in all primitive types is usually an overcorrection from trauma caused by C/C++'s historic loose definitions of primitive type sizes. However I don't write much CPU SIMD code and can definitely see how you'd develop your preference from that context.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: