Ah yes, of course. So a teensy bit better to set v8_enable_31bit_smis_on_64bit_arch = false if v8_enable_pointer_compression == false. This would suggest that the default for v8_enable_31bit_smis_on_64bit_arch (true) is ever so slightly suboptimal (since it's irrelevant if v8_enable_pointer_compression == true). But as you say, "you might not even notice it". In fact, I'd be very surprised if anyone does as by far the bulk of integers in applications will not be in the 1G+ range. As an aside, I'm awed by V8's integer performance which some simple tests suggest is only 2-4 times slower than optimized gcc or clang C++ code for heads down integer arithmetic!
Thanks! On Wednesday, April 15, 2020 at 10:14:03 AM UTC-5, Jakob Kummerow wrote: > > Is there any reason to use V8_31BIT_SMIS_ON_64BIT_ARCH or not when not >> using compressed pointers? > > > Smis are faster than any alternative, so 32-bit Smis potentially allow > more code to benefit from the Smi advantage than 31-bit Smis. We separated > the build flags mostly to be able to track the impact of moving to 31-bit > Smis separately from the impact of un/compressing pointers on the fly. If > you don't compress pointers, you're better served by 32-bit Smis. The > difference should (in most cases) be small though, you might not even > notice it. > > And just to reiterate: pointer compression requires 31-bit Smis, you can't > have V8_COMPRESS_POINTERS without V8_31BIT_SMIS_ON_64BIT_ARCH. > > > On Tue, Apr 14, 2020 at 5:56 PM Alex Kodat <alex...@gmail.com > <javascript:>> wrote: > >> It appears that the default for v8_enable_31bit_smis_on_64bit_arch has >> changed from false to true somewhere between 7.7 (our last build for our >> code) and 8.1 (what we're trying to upgrade to). It appears that if >> V8_COMPRESS_POINTERS is defined, the setting of V8_31BIT_SMIS_ON_64BIT_ARCH >> doesn't matter because kApiTaggedSize is set to kApiInt32Size in >> v8-internal.h when V8_COMPRESS_POINTERS is defined. >> >> But, we decided we didn't want compressed pointers so we built V8 >> with v8_enable_pointer_compression set to false. But, because we didn't >> realize the default for v8_enable_31bit_smis_on_64bit_arch had changed to >> true, when we compiled our code with V8_COMPRESS_POINTERS not defined, bad >> things happened because V8_31BIT_SMIS_ON_64BIT_ARCH was defined for the V8 >> build but not for our compile and when V8_COMPRESS_POINTERS is not defined >> this difference causes problems. >> >> So this is mostly just a heads up to anyone building with >> v8_enable_pointer_compression set to false. You either better also set >> v8_enable_31bit_smis_on_64bit_arch to false in your V8 build or make sure >> you define V8_31BIT_SMIS_ON_64BIT_ARCH in your own compiles. >> >> But then also, one question. Is there any reason to use >> V8_31BIT_SMIS_ON_64BIT_ARCH or not when not using compressed pointers? It >> seems that the difference is largely aesthetic -- what do you like your >> SMIs to look like when looking at storage? So we just went with the new >> default of V8_31BIT_SMIS_ON_64BIT_ARCH assuming the default must be the >> better approach. ;-) Opinions? >> >> Thanks >> >> -- >> > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/3ed94732-25a0-4978-9374-54de37011809%40googlegroups.com.
