8 ms·
I wish new platforms would embrace 64 bit as the default. C and C++ for all common platforms use 32 bit literals and prefer 32 bit operations (char * short =>
by xscott 6y ago
I wish new platforms would embrace 64 bit as the default. C and C++ for all common platforms use 32 bit literals and prefer 32 bit operations (char * short => int). Rust made a similar mistake. Java arrays use 32 bit subscripts, etc... I don't have a single computer (including my phone) using 32 bit pointers, but integers are stuck in the late 80s. (We already had 64 bit DEC alphas in the early 90s)
For a web page, 4 gig seems like a courtesy limitation to users, but that should be enforced by the browser refusing to suck up the entire computer rather than the language being unable to. I routinely write (non-web) applications which use arrays larger than 4 gigasamples.
- metalliqaz 6y agoI'm pretty sure rust uses usize, which is 64 bits on modern architectures.
- nicoburns 6y agoRust literals will infer their type from context if possible. Otherwise I believe the default is i32. There are also literal suffixes. So you can 999u64 of 999.02f64 if you want.
- metalliqaz 6y agoliterals, yes, but he's talking specifically about indexing into arrays by my understanding
- steveklabnik 6y agoYes, so, the situation is: #![feature(type_name_of_val)] fn main() { let v = vec![1, 2, 3]; let x = 1; let y = 1; v[x]; dbg!(std::any::type_name_of_val(&x)); dbg!(std::any::type_name_of_val(&y)); } gives [src/main.rs:11] std::any::type_name_of_val(&x) = "usize" [src/main.rs:12] std::any::type_name_of_val(&y) = "i32" https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=faedcbb75b4b29b4a4def06d31c37f13 https://play.rust-lang.org/?version=nightly&mode=debug&editi...
- xscott 6y agoThis type inference at a distance thing is unsettling to me. Adding v[y]; much later in the function (after your debugs) quietly changes everything above it...
- pornel 6y agoType inference works only when the types are unambiguous - arrays don't support indexing by anything else. With strict typing and very few implicit conversions in the language it works very well without surprises. You can still declare types ahead of time if you want to.
- xscott 6y ago> Type inference works only when the types are unambiguous It looks to me like when the types are ambiguous (because nothing placed a restriction on them), integer literals become 32 bit and floating literals become 64 bit. Then quietly, later when you add a restriction, the code above (which you've already worked through one line at a time with debug statements and all) changes from underneath you. > You can still declare types ahead of time if you want to. When the implicit stuff is surprising, I'd rather it wasn't ever implicit.
- steveklabnik 6y agopornel is right, but to be extra clear: if that happened and the types were mis-matched, it’s not very quiet: you’d get a compiler error. We don’t implicitly coerce numerics.
- xscott 6y agoI think the i32 default for integer literals stands in contrast to the otherwise solid choices for numerics on builtin types in Rust.
- steveklabnik 6y agoWhat would you prefer?
- zozbot234 6y agousize can even be 16 bits, when targeting small microcontrollers and vintage architectures.
- saagarjha 6y agoDo you happen to have an Apple Watch?
- skybrian 6y agoUsing 32-bit pointers can save a lot of memory in pointer-heavy data. Saving memory matters on mobile devices.
- xscott 6y agoPointer heavy data is begging for cache misses and should be avoided for lots of reasons. I want 64 bit loop indexes for large flat arrays.
- gpm 6y agoI, on the other hand, wish everyone would embrace 32 bit by default. Doubling the size of every index, integer, etc comes at significant memory cost for next to no benefit. Increasing the amount of memory used directly impacts performance considering how slow memory is and how important it is to keep commonly used items in cache. If you're seriously using more than 4gb in a web page... I wouldn't mind a non-default wasm64 format. You should also be considering shipping a native app at that point, wasm is not free in terms of performance.
- centimeter 6y ago> Doubling the size of every index, integer, etc comes at significant memory cost for next to no benefit. The overwhelming majority of GUI program data is composed of images, textures, sounds, videos, 3D models, text, etc. I would bet that less than 5% of the memory required to host a popular web page (facebook, amazon, etc.) is dedicated to pointers, array indices, etc.
- gpm 6y agoThe overwhelming majority of what wasm will be used for probably does not include images, textures, sounds, videos or 3d models. The overwhelming majority of the memory in most wasm programs will probably be not large arrays of text. The webpage as a whole is a gui program, but wasm is primarily a place to run computationally intensive code. The web-browser deals with things like rendering images natively without storing the image in wasm.
- _bxg1 6y agoAlso V8 underpins Node, which has many more legitimate use-cases for that much memory. That said I think we need some sort of user-facing permissions constraints for memory usage and/or webassembly execution. I fear that in practice this new capacity will mostly get used by unscrupulous crypto-miners.
- jfkebwjsbx 6y agoUsing 64 bits when you don't need them is the mistake, not the other way around. Cache isn't infinite.
- xscott 6y agoGo ahead and use smaller types in your arrays of structs, but 32 bit loop variables is quietly asking for weird failures when your users run real data.
- Avi-D-coder 6y agoWhy prefer 64bit pointers over multiple memory address spaces (https://github.com/WebAssembly/multi-memory https://github.com/WebAssembly/multi-memory)? Your CPU has to do a lot of work to keep pretending it's memory is flat, If we give up that pretense you can optimize cache utilization and multiplex multiple WASM threads onto a single OS thread without allowing specter.
- kllrnohj 6y agoBecause the CPU is going to do the work to make that illusion happen regardless of if you participate in it or not - so why constrain yourself to anything less than 64-bit pointers if you're not going to get anything in return? What cache optimization are you referring to? Just that 32-bit pointers is a form of pseudo-compression and can be more densely packed? Because there's not really any other cache benefits in play here, and you don't need 32-bit compressed pointers to get optimized cache utilization - value types & data oriented design is far more effective for improving cache utilization.
- Avi-D-coder 6y agoImmutable data structures tend to use a lot of pointers see how Haskell executes, even in other paradigms halving pointer s can have a significant impact on alignment (tags, enums, etc). V8 sandboxes WASM by placing them in a dedicated OS process, this buys 64 bit pointers, but comes at a cost. We can chose for a 64 bit processor to buy us in process memory isolation, by masking pointers or we can have 64 bit pointers.
- _nalply 6y agoJavaScript is already an old language from 1993 and quirky in that it doesn't have 64 bit integers. Webassembly inherits that so you can't really say it is a new platform. I don't see Rust making what you call a mistake. Rust has 64 bit and even 128 bit integers. 64 bit integers and pointers have a trade-off we need to consider: they need more memory. Out there are still embedded systems perhaps running on a tiny battery and having 16 bit memory, and it is wasteful to force 32 bit or even 64 bit data on them. So currently we have at least three different directly adressable memory sizes: 16 bit (up to 64 KiB directly addressable memory), 32 bit (up to 4 GiB directly addressable memory) and 64 bit (up to 16 EiB directly addressable memory, this is 4 billion times of 4 GiB, however currently platforms don't use all bits and don't have that addressability, for details see: https://en.wikipedia.org/wiki/64-bit_computing#Limits_of_processors https://en.wikipedia.org/wiki/64-bit_computing#Limits_of_pro...).
- xscott 6y ago> JavaScript is already an old language ... JavaScript is old and crufty. WASM is new and definitely has 64 bit integers: https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format#Signatures_and_parameters https://developer.mozilla.org/en-US/docs/WebAssembly/Underst... > I don't see Rust making what you call a mistake ... The details are subtle, but you can find discussion about it elsewhere in this thread. > 64 bit integers and pointers have a trade-off we need to consider: they need more memory. [...] embedded systems perhaps running on a tiny battery I'll pay you a dollar for every 16 or 32 bit system that WASM will run on if you pay me a penny for every 64 bit one.