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

71–80 of 86 posts

Re: Up to 4GB of Memory in WebAssembly

#71

Post by shigeo »

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

Tangentially, Rust goes well out of its way to avoid "type inference at a distance". For example, unlike Haskell or most MLs, type inference will not work across a function boundary.

Re: Up to 4GB of Memory in WebAssembly

#72

Post by _nalply »

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…

JavaScript 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_pro...).

Re: Up to 4GB of Memory in WebAssembly

#73

Post by xscott »

gpm wrote: post #67
xscott wrote: post #66

Earlier quoted context omitted.

> for the simple reason that that means you probably loaded 2GB of data over the internet No, web pages can access local storage.

You mean file:// urls? If you have access to do that... why not just install a real executable as well. (Can't say I'm terribly up to date on the different ways to store data as a website... but if there's a way to persist multiple gb I would be very surprised)

I really don't like being in the position of defending web apps - that is really not my preferred way to do most things I would write. However, taking a devil's advocate position:

> You mean file:// urls? If you have access to do that...

Modern browsers provide JavaScript with way more power than just file urls: https://www.w3.org/TR/FileAPI/

There are also drag and drop APIs...

> why not just install a real executable as well.

That depends on who your audience is. It's certainly easier to tell some users "go hit this web page and click ok when it asks to open your file". And there are some web apps which I find preferable to downloaded apps. For instance, I really like draw.io, and it works seamlessly on Windows, MacOS, and Linux.

> but if there's a way to persist multiple gb I would be very surprised

The only limitations I'm aware of are tied to this nonsense about 32 bit integers :-)

Re: Up to 4GB of Memory in WebAssembly

#74

Post by xscott »

shigeo wrote: post #71
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...

Tangentially, Rust goes well out of its way to avoid "type inference at a distance". For example, unlike Haskell or most MLs, type inference will not work across a function boundary.

Here's one that caught me off guard:

    #[derive(Debug)]
    struct Foo { pub bar: T }

    fn hmm(x: T) -> Foo {
        Foo { bar: x }
    }

    fn main() {
        let f:Foo = hmm(1.23);
        print!("got: {:?}\n", f);
    }
So maybe that's not crossing function boundaries, but the type for the generic "hmm" function as the rvalue is being inferred from the explicitly declared type of the lvalue. I know it's pointless to try and change anyone's mind about this, but I personally find it unsettling :-)

Re: Up to 4GB of Memory in WebAssembly

#75

Post by xscott »

steveklabnik wrote: post #59
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...

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.

I think the i32 default for integer literals stands in contrast to the otherwise solid choices for numerics on builtin types in Rust.

Re: Up to 4GB of Memory in WebAssembly

#77

Post by xscott »

_nalply wrote: post #72
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…

JavaScript 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 bat…

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

Re: Up to 4GB of Memory in WebAssembly

#79

Post by juntao »

V8 wasm has memory size limitation because it is fundamentally limited by the chrome browser.

But other server-side WebAssembly don't have this question, for example, SSVM never had any arbitrary memory limit.

Re: Up to 4GB of Memory in WebAssembly

#80

Post by steveklabnik »

xscott wrote: post #75
steveklabnik wrote: post #59

Earlier quoted context omitted.

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.

I think the i32 default for integer literals stands in contrast to the otherwise solid choices for numerics on builtin types in Rust.

What would you prefer?
Post reply on HN