New Interpreter Incoming x~100 speed

Well, when it comes to reflected nodes created from your codebase yes. Everything else is approximately x10+ increase. I just think that's rather exciting anyway

 

Do I understand this right? Are those numbers (103226 and 1092) are milliseconds executing big, enormous nothing 1000 times?

 

Apologies, I do everything in ticks! 10,000,000 ticks per second (on my machine) so;

1000x Trigger empty node

0.0103226s 10.3ms 97fps x1.0
0.0001092s 0.11ms 9159fps x94.52

Basically, node flow 'latency' is a thing of the past (I'm doing nothing in that cycle). There is still latency in getting and setting values as to be expected, but this is where things are approx x10 (to x20) speed up. The more complex the loop the closer you will get to x10 speed. As you can see, without using a reflected (slow) node, the difference here is x23.

1000x Set Var1 with For.index, set Var2 = Var1

0.0132401s 13.2ms 75fps x 1.0
0.0005726s 0.05ms 1746fps x 23.12

It's not going to make 'actual code' run faster, that will still be the same obviously, but the system won't be slowing things down significantly.

 

Does it have feature parity with the reflection runtime? And is this still 1.8.0-Pre or something newer?

 

Still 1.8.0-Pre although managed to get full speed in Editor (turned off tracing in the code, hopefully an option on newer releases). I don't think there is anything different in regards to runtime abilities, it's more about the actual trigger points and passing data. Although not sure how I might translate 2 unit headers (not that there are any with that but I might use for complex multifunction nodes!)

 

How does the high performance interpreter perform when compared to C# scripts???

 

That's a challenging comparison to make, since Visual Scripting is linking code together. If a line is broken down into separate nodes, each action is therefore separately linked. I would say;

a) It makes it more possible to make simple builds in just VS form that don't have high complexity/critical performance needs (not that the goal is ever to replace programming). Added assets/code are still code, so still using code. But with reflected nodes now being 100x faster that makes using them more feasible
b) It makes it more possible to link high performance code or custom nodes together without the overhead of connections, giving a visual level to some aspect of your high performance code.

I do want to test both of these, to see what is possible from both sides.

 

Do a millisec comparison. If it's not millisecs it will be misleading and inaccurate if you are doing "100x speed" then comparing to C# scripts.

 

Whether ticks or milliseconds, the comparison will be the same surely? (I'm no pro tester but learning!)

 

If I use the profiler and take out the stop watches and just run Update -> For 10000x -> DoNothing(reflected). Although not sure what I'm look at with the EditorLoop on the Interpreter version but not Normal version.

Normal


Interpreter

 

Nope.

The milliseconds are international standard, when we say something takes one millisecond, we know exactly what it does mean (some people know more precisely than others though).
When you say ticks, we have zero idea what you're talking about. What is a tick? Are you referring to a CPU tick? A Unity tick (one update execution)? A visual scripting tick if it exists? One command executed on the visual scripting engine? Or what it is exactly?

 

(It's probably further down actually because it would be slower than the player loop)

 

Seems like you're at the moment satisfied with the performance so really it's a positive thing isn't it?

 

I'll bear it in mind to what people are used to, just prefer whole numbers to decimals when working on small tests. Eg. 1 tick in milliseconds is 0.0001ms, and it's more testing A vs B in comparison rather than actual speed which is relative to someone's computer so means little compared to actual comparisons. Although optimising can also be different based on CPU instruction sets.

 

So... Doing nothing is really fast now?

 

I'm a Unity Visual Scripting cheer leader for sure and excited about what Unity create out of it. At the same time trying to tailor it to my own ideas for custom nodes that I would use. While it is a challenge to use in the current state (however not doing too bad here), I will feel complete when 1.8 becomes a useable version (mainly so I can build to IL2CPP)

 

Sounds funny, but yes, the empty space of nothing between A saying your turn B, have some int on the side, is now less of a performance hog when comparing to the actual actions of A and B!

 

I always knew Unity is the best engine if you don't want to do anything, glad to see they're really trying not to lose that competitive edge.

 

Current UVS is 5-10 times slower than C#. So having it being closer to C# is great. Wish it didn't take nearly two years, though. Next to no other improvements have been made in that time, at least nothing that has landed in users' hands and would make the tool more usable.

If you get Bolt 1 from late 2018 and compare it to the current version of UVS, the tools are functionally identical in UI, UX and performance in builds since the new interpreter is in preview and not stable. UVS has better editor performance for large graphs and rudimentary Input System support and some minor naming changes, a few new niche nodes and a new coat of paint.

Long story short, Unity machine has grown so huge, it can't make decent progress anymore.

 

This is the problem with a lot of established software. I typeset music professionally and for many years used Finale and Sibelius. New kid on the block, Dorico, comes along and within a couple of years of clean code, modern design and no fear of backward compatibility, it knocks the spots off the old contenders, solving problems that FInale and Sibelius would otherwise find impossible.

You might hope that the Package model of Unity would make things easier but Packages have to talk to the main Editor engine and it's quite possible that the original design didn't open it up as much as is necessary.

Visual Scripting will never be an important part of Unity revenue generation. Both the Create and the Operate business arms depend on C# monkeys driving income.

We hear warm words about UVS expanding the user base but if it doesn't drive revenue, it will always be the second child.

 

I think the modern thing is either, making anew, or making backward compatible (forever). My company (that I work for) has been through 3 types of software for keeping everything. Each one kept adding things on, new features, until they were just slow and breakable. Although the last one were more interested in what their other clients wanted and fitting for everyone rather than tailoring to our needs.

I'm hopeful on the new one we are using, because their focus seems to be simplicity and speed for the process at hand. Many software, you can't choose potato mode, you have to have all their features because they are built in, even if you might never use them!

 

When it fully works as intended, then I think it will. ShaderGraph as a feature compared to writing c code surely that has helped immensely. Although C# as visual is slightly different, but it's still translating one model into another. Hard coders will always want features not possible with a translated model of code. The current issue with the old version was the speed. If you have to choose between a massive performance gap vs abilities, performance comes first. If that is not such a big gap, the choice becomes a bit more towards the actual usage and ease of use, eg. how quickly can I do something, convenience.

 

TBH where it's a real winner to me even in the current state, is the avoidance of recompile times. You can alter your code concept which is in the form of nodes, without the favourite part of coding, wait for recompile. So, amazing in terms of prototyping code (albeit not uber complex code, just actual results/output).

I had an idea (one of many radical ideas i haven't got to yet!), maybe I could use it to lookup code, and replace variables with mod variable nodes. Although not using as intended, it's still a great idea I think. Of course adding/reverting a mod will require recompile, but I imagine the results will be fun. Currently messing around with that in actually designing a node. I have no idea how would have quickly done that without using mods in the code.

 

Yup. Amen to that. As a programming musician, I've tried all sorts of packages for creating music. I love Supercollider (based on Smalltalk) and taught it at Uni for both UG and PG music students. However, I always had a soft spot for Reaktor and Max, both of which are graphical/block-based programming environments. I understand how non-programmers set about programming and, while a small number of them truly understood Supercollider, many more got under the skin of Reaktor, simply because it was graphical.

Instant gratification from either interpreted languages or JIT compilation makes things so much easier to understand and use.

Personally, I'm excited to see what Unity will do. I just hope they don't abandon the vision, as seems to be the case with ProBuilder and other packages.

 

I don't normally reply to my own messages but, in case Gabriel Williams happens to see this, my criticism of ProBuilder is that both Bezier Shapes and Boolean (CSG) tools have been in Experimental stage for at least 4 years and possibly longer. Certainly since the ProCore days and that means before Feb 2018. That makes them stagnant, as far as I'm concerned.

 

This is going to happen (and kinda _has_ been happening) to UVS as well.

As far as I can tell -- @gabrielw_unity was pulled to the Editor Overlays team (as with pretty much any decent developer who stays with Unity for any length of time). Management of multiple projects (and the lack of core, stable, technology) is the common issue with these 'stagnant' projects -- not the tools themselves.

Unity always buys S*** and plans to "improve" it -- but then yanks devs away from the projects constantly, leaving them to wither and die otherwise. This poor management is the reason Unity is almost NOT a competitor to Unreal these days.