There are clang/gcc attributes to define the alignment of a property, or to make the entire struct packed, you can use those if you want to adjust alignment. This at least keeps the unaligned reads and writes just in the places they are needed. However, the slowdown of unaligned accesses is quite high in JS, so it is highly not recommended. My guess is the game would be faster just using the normal allocator and normal alignment.
- Alon On Mon, Aug 11, 2014 at 7:01 AM, Floh <[email protected]> wrote: > I'm pretty sure that the 4-byte alignment of you allocator is the problem > since emscripten (very likely) wants to access the double members through a > Float64Array heap view which has 8-byte granularity. On x86 CPUs memory > access don't need to be naturally aligned (except for SSE read/writes which > must be 16-byte aligned), but you should be aware that you're still paying > a performance penalty on Intel since the CPU has to use 2 read/write > operation for such unaligned memory access. So IMHO it would be a good idea > to make your custom allocator at least 8-byte aligned (16 if you want to > SSE). > > There are a few -s Options which deal with alignment, may be these help, > but there will definitely be performance panelties (see > emscripten/src/settings.js): > > var UNALIGNED_MEMORY = 0; // If enabled, all memory accesses are assumed > to be unaligned. (This only matters in > // typed arrays mode 2 where alignment is > relevant.) In unaligned memory mode, you > // can run nonportable code that typically would > break in JS (or on ARM for that > // matter, which also cannot do unaligned > reads/writes), at the cost of slowness > var FORCE_ALIGNED_MEMORY = 0; // If enabled, assumes all reads and writes > are fully aligned for the type they > // use. This is true in proper C code (no > undefined behavior), but is sadly > // common enough that we can't do it by > default. See SAFE_HEAP and CHECK_HEAP_ALIGN > // for ways to help find places in your code > where unaligned reads/writes are done - > // you might be able to refactor your > codebase to prevent them, which leads to > // smaller and faster code, or even the > option to turn this flag on. > var WARN_UNALIGNED = 0; // Warn at compile time about instructions that > LLVM tells us are not fully aligned. > // This is useful to find places in your code > where you might refactor to ensure proper > // alignment. (this option is fastcomp-only) > > > Cheers, > -Floh. > > Am Montag, 11. August 2014 15:34:27 UTC+2 schrieb Sergey Solozhentsev: > >> I have ga,e that is works on windows (an arm ios/android). And I need to >> port in on web. I have code that is warks fine for all previous platforms. >> However after compiling code using emscripten I found strange behaviour. I >> have class >> >> class CEnemy >> { >> ... >> wchar_t* version; >> double m_d1; >> double m_d2; >> } >> >> When I set m_d1 to some value e.g. 1.0 version field is also changed. I >> use special allocator to reuse memory for different objects. All values >> from this allocator are 4 bytes aligned. Without reusing memory it seems to >> work. However I'm afraid that using normal allocator slows down my game >> very much. >> adress of m_d1 is 4 bytes aligned but not 8 bytes aligned. Probably it is >> important. >> > -- > 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. > -- 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.
