Dan Wood

For anything remotely realistic-space-scale, you'll have to use 64-bit precision position data to avoid precision issues.

You can convert an object's P attribute to 64-bit using the Attribute Cast SOP.

It's possible that won't help with camera-jitter issues though, as I presume Houdini's camera handling is hardwired to 32-bit. Not sure about that.
(And those issues might follow you into rendering, etc... depending on if the renderer supports 64-bit precision or not)

Been getting to grips with OpenCL in Houdini recently, and it's got me wondering - unless you're doing 1000s of iterations on a data set between copy-backs, or some very complex calculations, generally the lion's share of time seems to end up loading data to/from the GPU (even when being careful only to transfer the minimum amount necessary).

So what in a typical modern highish-end-desktop system is the principle bottleneck there? Say, in a dual-channel DDR5 system with a PCIE 5.0 x16 interface to the GPU, would it be the RAM bandwidth or the PCI bus, or some other factor?

Just to add to the answers above - I believe it's because the "point" function doesn't have a single, predefined return type - it *might* return a vector, or it might return a float or a string, depending on what input you plug in... explicitly casting it as in the above posts means VEX can know in advance that referencing a .y component is valid.

You can still assign directly to @P.y this way: