[HN Gopher] Up to 4GB of Memory in WebAssembly
___________________________________________________________________
Up to 4GB of Memory in WebAssembly
Author : feross
Score : 76 points
Date : 2020-05-14 14:41 UTC (8 hours ago)
(HTM) web link (v8.dev)
(TXT) w3m dump (v8.dev)
| xscott wrote:
| 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.
| gpm wrote:
| I, 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 wrote:
| > 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 wrote:
| The 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.
| monocasa wrote:
| What do you think that computationally expensive code is
| cranking on? It ain't small bits of text.
| [deleted]
| Hokusai wrote:
| You are probably right about the heap, but in the stack
| there are no big data structures. To move all data types to
| 64bits would impact the stack size of processes and
| threads.
|
| Bigger data structures also mean more cache misses. So,
| systems would be also slower. As, bringing data from memory
| to the CPU is very slow compared with accessing L1 or L2
| cached data.
|
| So, you have a point. But, it does not apply equally to all
| data.
| xscott wrote:
| Let's take an example in your favor and say you've got 16
| integer local variables per stack frame and you're
| recursing 1000 (!!!) times over some really unbalanced
| tree or such. You saved 64 kilobytes...
|
| Ok, now let's say 32 bit integers are the standard: You
| either wrote a program that starts to fail in mysterious
| ways when someone runs it on a 2 GB file, or you
| complicated the hell out of your data structures by
| needing arrays of arrays (i.e.
| https://www.nayuki.io/page/large-arrays-proposal-for-
| java).
|
| It should be easier to make correct programs.
| skunkworker wrote:
| 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 from 15 to 30% at the cost of 1.5X
| larger memory size.[1]
|
| [1] https://www.cnx-software.com/2016/03/01/64-bit-arm-
| aarch64-i...
| gpm wrote:
| 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.
| metalliqaz wrote:
| I'm pretty sure rust uses usize, which is 64 bits on modern
| architectures.
| nicoburns wrote:
| Rust 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 wrote:
| literals, yes, but he's talking specifically about indexing
| into arrays by my understanding
| steveklabnik wrote:
| 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...
| zozbot234 wrote:
| usize can even be 16 bits, when targeting small
| microcontrollers and vintage architectures.
| saagarjha wrote:
| Do you happen to have an Apple Watch?
| skybrian wrote:
| Using 32-bit pointers can save a lot of memory in pointer-heavy
| data. Saving memory matters on mobile devices.
| Ericson2314 wrote:
| Why do we need to support stating the length ~~"2^32+1"~~ 2^32?
| wahern wrote:
| It would be "2^32", not "2^32+1". 2^32 isn't representable in a
| 32-bit integer, the same way 256 isn't representable in an
| 8-bit integer--the maximum is 2^8-1, or 255.
|
| But the argument that they need to represent 2^32 and therefore
| _that 's_ why they used 64-bit integers is dubious. No 32-bit
| WebAssembly program could ever operate on and pass an object as
| large as 2^32 bytes because the code and data structures for
| the smallest possible program would already take up more than 1
| byte in that 32-bit address space.
| snek wrote:
| As is mentioned in the article, u64 was used to future proof
| for wasm's upcoming memory64 type: https://github.com/WebAsse
| mbly/memory64/blob/master/proposal...
| Ericson2314 wrote:
| Yeah, so what are they going to do when they then claim to
| need to to represent the length 2^64?
| colejohnson66 wrote:
| If you have 2^64 objects, you have a bigger problem.
| Dylan16807 wrote:
| That won't happen on a 64 bit machine. By the time we
| need that, the code will be so vastly different that
| trying to prepare for it now would be counterproductive.
| MaxKK wrote:
| Amazing that they have a dark mode detection on that website.
| saagarjha wrote:
| Unfortunately their dark mode detection is incorrect on my
| computer :(
| TeMPOraL wrote:
| You can do that in CSS now. I've noticed surprisingly many
| sites adjusting when I started using a Windows machine and set
| my system-wide preference to dark mode.
| diffrinse wrote:
| Prolly cause the devs themselves use it
| aledalgrande wrote:
| Yup I try to convert every product I develop lol
| austincheney wrote:
| I am not seeing any difference in Firefox.
| baybal2 wrote:
| So, will we need to have 4GB of ram to run Javascripts now? :)
| orangepanda wrote:
| The title refers to web assembly memory limit. However, it's
| mentioned javascript now supports up to 16 million terabytes of
| memory (equivalent to 4 jira tabs).
| eggsnbacon1 wrote:
| Hah! It really is comical how insanely slow and bloated JIRA
| is. Its the only tab I keep open 24/7 because loading it
| takes so long.
|
| When I restart my PC I have a login script that fires up a
| bunch of slow stuff while I get coffee. My IDE's, Docker
| containers... and my JIRA tab :)
| cookiengineer wrote:
| Came here to see this, was not disappointed.
| abfan1127 wrote:
| I must be tired, because the Jira stab went right over my
| head, twice! well done.
| seangrogg wrote:
| Taken seriously: RAM often does get offloaded to disk as
| needed, so realistically this changes nothing in terms of specs
| needed to handle what's in memory.
|
| Taken less seriously: Do you not already need this just to run
| JIRA on Chrome? Or apps on Electron, generally?
| eggsnbacon1 wrote:
| I've found its faster and more reliable to reload JIRA tabs
| by simply creating a VM, running it on a browser in there,
| and pausing the VM when you don't need JIRA. When you need
| it, or after a restart, simply load up your VM and resume the
| operating system. This usually takes only a second or two,
| much faster than reloading JIRA the normal way.
|
| If anyone from Atlassian is here, please help me create an
| official JIRA tab VM image! Maintaining my JIRA OS negates
| probably half the time I save loading JIRA this way!
| shrimp_emoji wrote:
| 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/
| pan69 wrote:
| Are WebAssembly projects going to display a message somewhere
| that says "WEB4G" when started?
|
| (disclaimer: If you're under 35 you might not get this reference)
| recursive wrote:
| I'm 39 and I don't get it.
| hed wrote:
| I assume it's from when you used to boot DOS mode games that
| addressed beyond 640KB conventional memory they had DOS/4GW
| labeled all over.
|
| https://en.wikipedia.org/wiki/DOS/4G
| recursive wrote:
| The slash helps. I'm pretty sure Duke Nukem, Doom, and
| similar all showed that banner during startup.
| greatgib wrote:
| It's like reinventing what exists and doing the same mistakes
| that were already done!
| brundolf wrote:
| Just reading the part about the ensuing JavaScript implications
| gave me a stress-headache. Bless the people who are willing to
| work through these kinds of issues so the rest of us get to use
| the result.
___________________________________________________________________
(page generated 2020-05-14 23:01 UTC)