V8_31BIT_SMIS_ON_64BIT_ARCH

[Alex Kodat]

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

[Jakob Kummerow]

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.

--

[Alex Kodat]

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! 

[Toon Verwaest]

On Wed, Apr 15, 2020 at 5:48 PM Alex Kodat <alex...@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-u...@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+u...@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.