On Wed, Apr 15, 2020 at 5:48 PM Alex Kodat <alexko...@gmail.com> wrote:
> 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! > Depends on what you're doing. If you're doing e.g. crypto you're likely going to end up with numbers that require the full 32bit; but not more if you use bit-operations since they are defined to be 32bit in JS. You can get around it by explicitly masking off the upper bits to stay within 31-bit range, but you need to be aware of this. Otherwise we'll end up doing a lot of computation using doubles, possibly requiring heap allocation. You already need to be aware that you should use bit-operations to stay within 32 bits too though :-) > > > 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> 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 > <https://groups.google.com/d/msgid/v8-users/3ed94732-25a0-4978-9374-54de37011809%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- 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/CANS-YRr0TBEXDbA05iSz7xwY2W2HL3sKmMr%2B6V%3Diwt58tfUO-A%40mail.gmail.com.
