Why is bool type not available in VEX?

[magneto]

In the list of types that are supported, I couldn't find booleans:

http://www.sidefx.com/docs/houdini11.0/vex/lang

I am using ints for now, but is there a reason why they didn't add this to VEX on purpose?

I don't think it's unintentional, there must be a reason

[symek]

Vex works mostly on geometry attributes, so no bool attribute -> no bool variables I presume. (All Houdini parts are tied closely to things like its geometry library which are used across a whole program, so the design of such thing influences all parts).

Additionally VEX is heavily multi-threaded with SIMD instructions, in which case data alignment and vectorization is crucial for performance. I suspect it is easier for VEX for perform on floats and vectors, which can be piped into registers faster.

Edited January 20, 2012 by SYmek

[magneto]

Thanks Symek, I was mainly using them for parameters, etc so they were one-offs, but I understand what you mean.

Do you also know if I can find more info about the inner workings of VEX beyond what's shown in the VEX reference in the docs, which isn't much.

I was looking for things like:

Prefer this technique:

...

over this:

...

etc

which Python section of the docs have.

What kind of cases are optimized more efficiently, what happens when VEX is compiled into an operator, etc.

I find this sort of info very valuable, but I suspect it would only be available if you grab a drink with the Sidefx developers

[symek]

I find this sort of info very valuable, but I suspect it would only be available if you grab a drink with the Sidefx developers

Oh, apparently you have more chances to meet them than me . As to VEX I don't know any insights besides what's scattered across docs, forum and HDK inline comments (which I like to read a lot). There is a book though (mine is lost somewhere...) in which Mark Elendt described in details VEX virtual machine design. Second point is that VEX is not such an isolated case. Once you start reading about SIMD design, Renderman RSL, code optimization, you may reach ( presumably misleading but still ) the feeling you know better

What kind of cases are optimized more efficiently, what happens when VEX is compiled into an operator, etc.

In mantra there is a verbose mode with vex profiling, which tells you a lot about vex run-time conditions. Other than that it's all about trial&error. Not sure what you mean by "what happens when VEX is compiled into an operator"? When you make an operator with a VEX code, it is still a general Vex-like-SOP, it doesn't change magically into completely custom node (except UI which are spare parms anyway). It's general vex node, which keeps inside your code and on cook calls vex virtual machine, just like a VopSOP. There are differences like in SOPs node has a single virtual machine, unlike Mantra which most probably (can't be sure), has such a machine per thread (what has this effect, that thread-unsafe code, runs well in shaders, but blows up Houdini at sight!).

There are some tips which afaik are common for all parallel environment, like avoiding switches/conditional statements etc. Basically the more streamlined execution tree is the better. It's true about VEX, Cuda, or pure SIMD code. But there really isn't much difference between "naive" and "optimized" code in SOPs. The main slow downs are out of control anyway (like ray intersecting, single threaded write geometry access (in H11), and such). The code itself gets well optimized by a compiler (which apparently gets even better in H12).

[magneto]

lol brb heading to Sidefx Toronto office

Thanks for the info. Eetu also mentioned the same book, so I will pick up a copy and read the VEX section.

Sorry when I said "what happens when VEX is compiled into an operator?", I meant asking about details along the same lines of your description, like VEX compiler turns your code into bytecode, it's wrapped inside the a special SOP that calls the virtual machine on every cook, etc.

I also try to avoid branching in vex but sometimes it's unavoidable and had to use them for options. Though I did some experiments and found out that in branching if the value is fixed, the vex compiler seems to optimize it. I also found one of Edward's comments where he was saying "the magic of the vex compiler" in regards to a similar question.

Is it possible to maybe take a look at the generated bytecode and compare?

Edited January 20, 2012 by magneto

[hopbin9]

I find this sort of info very valuable, but I suspect it would only be available if you grab a drink with the Sidefx developers

Yes, let's get them shit face drunk.

[symek]

Is it possible to maybe take a look at the generated bytecode and compare?

Sure, just compile it to *.vex:

$ vcc test.vfl
REMARK (3005) Outputting VEX code to ./test.vex

[magneto]

@hopbin:

Yeah that's a good idea, I wanna know all the insider details

Thanks Symek, maybe it's you I should grab a drink

[Krion]

I would like this.

Automatic Toggle Parameter creation. A little less moving into the Edit Parameter Interface.

 

Would such datatypes also not take less memory or something as opposed to an int?

Edited July 10, 2021 by Krion

[acey195]

It would add a new data type to take into account for the compiler and memory management.
Generally speaking, having if checks in shader like languages is not extremely efficient anyway, so optimizing for them might also not really matter that much.

I for one looove the fact that you can just add/multiply bools (ints) together, where with most other languages you cannot.
I'm happy to pay a tiny bit extra RAM for that.
 

If you have a lot of && checks, you can just multiply them all together, and if one of them was 0, the result is 0,
whereas if you have a lot of || checks, you can also just add them all together and check if the sum of that, is larger than 0

and you can still use bitwise operators on ints to cover all the functionality bools have like:

• |=
• &=
• ^

Edited July 11, 2021 by acey195

[Krion]

Okay then just make a cht() function, SideFX :-) I’m laizy

Edited July 11, 2021 by Krion

[acey195]

would actually not be opposed to that idea..