Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Up to 4GB of Memory in WebAssembly

v8.dev

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Up to 4GB of Memory in WebAssembly

#51

Post by xscott »

steveklabnik wrote: post #25
metalliqaz wrote: post #23

Earlier quoted context omitted.

literals, yes, but he's talking specifically about indexing into arrays by my understanding

Yes, 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&editi...

This 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...

Re: Up to 4GB of Memory in WebAssembly

#52

Post by xscott »

jfkebwjsbx wrote: post #49
xscott wrote: post #16

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…

Using 64 bits when you don't need them is the mistake, not the other way around. Cache isn't infinite.

Go 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.

Re: Up to 4GB of Memory in WebAssembly

#53

Post by Avi-D-coder »

xscott wrote: post #16

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…

Why prefer 64bit pointers over multiple memory address spaces (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.

Re: Up to 4GB of Memory in WebAssembly

#54

Post by kllrnohj »

Avi-D-coder wrote: post #53
xscott wrote: post #16

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…

Why prefer 64bit pointers over multiple memory address spaces ( 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.

Because 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.

Re: Up to 4GB of Memory in WebAssembly

#55

Post by kllrnohj »

gpm wrote: post #42
skunkworker wrote: post #39

Earlier quoted context omitted.

On some platforms like ARM, the transition from 32bit to 64bit(Aarch64) and the improvements to the ISA allowed some software to run much quicker on the same hardware. While the increased memory usage was detrimental if you are running into memory pressure issues, the speed improvements would be well worth the change for most tasks. When the Pi 3 launched it had a 32bit OS, but switching to 64bit improved the speed f…

There doesn't have to be a choice between a fast ISA, and even 64 bit registers, and using 32 bit pointers/indices. We can do theoretically do both - it's just extremely rare in practice.

Not rare at all. 32-bit "pointers" in a 64-bit process is relatively common, even, as it's what ART does on Android ( https://www.anandtech.com/show/8231/a-closer-look-at-android... ). And Hotspot has a similar optimization: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

Re: Up to 4GB of Memory in WebAssembly

#56

Post by pornel »

xscott wrote: post #51
steveklabnik wrote: post #25

Earlier quoted context omitted.

Yes, 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&editi...

This 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...

Type 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.

Re: Up to 4GB of Memory in WebAssembly

#57

Post by xscott »

skybrian wrote: post #28
xscott wrote: post #16

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…

Using 32-bit pointers can save a lot of memory in pointer-heavy data. Saving memory matters on mobile devices.

Pointer 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.

Re: Up to 4GB of Memory in WebAssembly

#58

Post by kllrnohj »

shrimp_emoji wrote: post #13
baybal2 wrote: post #10

So, will we need to have 4GB of ram to run Javascripts now? :)

If we start playing crossplatform, browser-based wasm games[0], we might. And we should. OS independence when. 0: https://wasm.continuation-labs.com/d3demo/

4G memory limits, 64-bit migration issues, Doom 3, brk()-based memory management, no multi-threading, unreliable SIMD support... It's like it's 2004 all over again!

Re: Up to 4GB of Memory in WebAssembly

#59

Post by steveklabnik »

xscott wrote: post #51
steveklabnik wrote: post #25

Earlier quoted context omitted.

Yes, 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&editi...

This 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 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.

Re: Up to 4GB of Memory in WebAssembly

#60

Post by xscott »

pornel wrote: post #56
xscott wrote: post #51

Earlier quoted context omitted.

This 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...

Type 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.

> 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.

Post reply on HN