On Monday, January 9, 2017 at 12:03:11 AM UTC-6, Charles Vaughn wrote: > > > > On Saturday, January 7, 2017 at 2:04:13 PM UTC-8, Brendan Bohannon wrote: >> >> I have recently been using Emscripten for building some personal projects >> as a test, but have noted some various issues. >> version = 1.35.0 >> > > You mention testing WASM. 1.35.0 doesn't support that. In any case try > using the latest 1.37.x. > >
it appears it does on my end, as there is a WASM tool, though I did have to modify some things before it actually worked (my first attempts to use it, it just blew up). granted, I don't know if it is using the current form (I guess WASM started out as an AST serialization and has since changed into a full bytecode or similar). 1.35 is the version which got installed when I reinstalled it (fairly recently). > >> slow compilation times: >> * compiling takes a fairly long time if compared with native compilers, >> such as MSVC or GCC. >> * ex: when compiling a 200 kLOC program, compilation takes a decent >> number of minutes. >> ** program is most a basic Minecraft-style 3D engine (voxel-based). >> ** it isn't that big, and MSVC (VS2015) compiles it in under a minute. >> * can note: optimized JS output is about 8MB, vs ~ 60MB without >> optimizations. >> >> general requests: maybe try to make compile times faster? >> >> > Compilation, especially to size optimized JS will take longer than > generating an optimized .exe due to needing to optimize textual javascript. > I suspect most compilation time improvements will be focused on the native > LLVM WASM backend, but I htink that's still WIP. You can try seeing if Side > Modules ( > https://github.com/kripken/emscripten/wiki/Linking#overview-of-dynamic-linking > > ) allow you to compile frequently modified code in a smaller JS subset. > > ok. I had half considered working on my own C compiler (and writing an ASM.js or WASM back-end), but it is pretty debatable if it is worthwhile (time/effort). Emscripten does at least work, even if not perfectly in some cases. I am using a custom VM in the program for scripting, and had half considered possibly targeting the VMs bytecode (in native land, it can get within ~3-5x native for an x86 or x86-64 JIT, *1, and often within ~15x for interpretation; not really tested but it seems the speed difference between the interpreter and C code is a lot less when compiled to JS vs built for x86). *1: though the x86-64 JIT had to use register-allocation / ... as it is a little harder to approach native C speeds than in 32-bits with when producing code with lots of extra memory loads/stores... > misc: >> * compiler seems to be imposing some C++ rules onto C for some reason. >> > > Certain features of Emscripten require the use of a C++ compiler (embind > for example) > > so, it is taking C code and compiling it in C++ mode?... > * this can be addressed, but it was annoying needing to go over and stick >> in extra type-casts on pointers and similar. >> >> also more/better debugging facilities would be nice, even if only >> something like making "emrun" able to provide a GDB style interface. >> >> > You can can give CyberDWARF a shot for better printing support, but it's > still rough: > https://kripken.github.io/emscripten-site/docs/debugging/CyberDWARF.html > > Expect WASM to deliver better debugging. In general I'd recommend having a > project that can be built either for JS or Native and primarily debugging > native. > > I am also mostly debugging the native build, but during the port, I have been faced with numerous bugs (primarily related to using the OpenGL emulation), which I can't reproduce in the native version. I had wondered about doing a GLES2 version of the renderer, dunno. >> have observed that rendering and input-handling seem faster on Chrome, >> whereas primarily CPU-based tasks seem faster on Firefox (but offset by it >> being noticeably slower to respond to keys being pressed/released than in >> Chrome). general start-up times are a lot faster in Chrome. >> >> however, I keep getting "browser ran out of memory" type error messages >> (primarily in Chrome, which basically says something like "Aw, Snap! >> Browser ran out of memory while trying to display website.") after a period >> of time (~ 15-20 minutes), this being seemingly uneffected by the choice of >> a 256MB or 512MB heap size (note: 256MB is about the minimum I can get away >> with, with a 64-meter draw distance; in native land for a 256 meter >> draw-distance memory use is generally around 1 GB, ...). >> >> > You can get an overview of where else in your JS app you're consuming > memory with a tool like Chrome's heap profiler: > https://developer.chrome.com/devtools/docs/heap-profiling > > Firefox has a similar tool. Javascript has a maximum heap size of 1GB, so > you'll have to stay under that for your JS allocated memory. WASM memory > regions don't count against that (or at least can go beyond it). > ok. strangely, the issue appears as if it may have magically fixed itself. had left the thing running in the browser for about ~2 days (had been working on other stuff in native land), and it didn't blow up. strange... granted, it could be because of moving it over to WASM?... > >> >> thoughts/comments?... >> >> >> for anyone curious, I have a built version online from here: >> https://cr88192.github.io/bgbtech_html/ >> >> I haven't pushed the changes for all this back up to GitHub yet, but >> general source for the engine is here: >> https://github.com/cr88192/bgbtech_engine2 >> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
