Raise the performance in large projects

Again some urgent improvement requests on the (good) old v4, after the completion of a project that was actually to big for v4 as we know it.

1.) Lazy Evaluation

When we look at what makes using v4 complicated, a major amount of work doesn’t go into patching logic or design, but only into making the patch perform again–and in itself incurs the use of many nodes that are there just for computation management.
In our usecases, for rendering the actual scene only a few of all nodes in the patch are required at a time. The rest needs to be put to sleep manually. And a large set of nodes is actually only there to manage the project flow, or to set initial values and never changes. For many computations it doesn’t matter, whether their result arrives in one frame or the other. And also de-evaluated parts of the graph still consume ticks.

So here’s the proposal.

We need a possibility that is integrated into the UI, that sends parts of the graph to a lazy evaluation thread, to make room in the main thread for the actual scene. In large projects 50% of CPU power is consumed by v4 infrastructure nodes–and we already use A LOT of evaluation logic.

Think from the perspective of a boygroup client. As a boygroup client, you get only the part of the graph that you actually need for the scene - and control and initialization data comes from the outside. That is what you actually want - But on a local machine. Decide, which parts of the graph are sent to the MainLoop, and which can be evaluated lazy.

Of course you could say that you can do this in a boygroup setup (And the 'we can also patch it in VL‘ theory). But on a local machine there are so many more possibilities and ease of use. Even branches of the graph that have node outputs could be on a lazy thread.
As in boygrouping, let the user decide and learn what works and what not.

Use Ctrl-B to send nodes to a boygroup. Use Ctrl-H not to hide the nodes, but to send them to a lazy thread. Or come up with another state for the nodes.

The proposal is kinda old and around since a long time, but I think it needs to be revisited and can be addressed with less concerns regarding timing accuracy and IPC. For the deep shit we’ll learn VL. But for the time being, we need a way to expand the magintude of v4 projects. It’s at the limit of what it can do in it’s current form.

2.) UI in a separate thread.

Get a grip and move the UI rendering to a separate thread. This is the single most annoying thing to constantly explain people that this stuttering on the LED is normal, because v4 has to render the interface in the same thread–and we need to keep on working. It’s really bad, and I think justifies touching the code of the plugins that manage their own windows.

Smaller issues and proposals.

The keyboard is actually very empty. Every shortcut starts with a Ctrl-. So … we have a whole keyboard of unsed modifier keys free! Like in other applications, where you can change the tool with a single key, you could have many more operations on the keyboard in v4. Or just get rid of the Ctrl-Key all over. Just press B for Boygroup. etc. Because: The letters are only needed in the node browser, or when you are in node-creation mode, or edting an IObox, etc. All separate states. But when you’re just navigating the patch, none of the keys has a function.

S-R nodes. Finally we have a sorted list of senders/channels. How about selecting the channel that match the letters that you type? Still a lot of unnecessary scrolling / searching.

Highlight pins containig non-default data (for example when pressing the letter P ;) )

11 Likes

I feel your pain. I regularly make use of 2 or 3 or 4 instances of vvvv to split processing into separate threads, its a complete pain in the arse. My wish would be for a subpatch to be set to evaluate in another thread, without worrying about sync, the patch updates the output when its done, lazy threading. But we both know, this isn’t going to happen because VL will solve all the worlds ills ™ eventually.
I use zeroMq for communication between instances, which seems to be the most efficient, and texture sharing before pipetting graphics for LED control from a separate instance are my main takes.
But boy grouping on 1 pc, is that possible? I’ve only used boy grouping once or twice and it didn’t go that well, the whole rebuild the entire graph with dodgy networks…
For requests, being able to search in the node finder with an address 73/12/311/43, etc would make sense to me rather than finding one node, then drilling down one after another, especially when TTY tells you which node address you’ve got freaking out!

2 Likes

Bump.

Hey Devs. I’ve been really serious with this post. This is not something tralalala nice to have at some point. V4 is at the limit and needs a feature update, and VL is not able to take over yet. For the time being and at least also the next two or three years to come, VL is no alternative to v4.

I take the fact that that nobody really joins into this discussion here in the forum (compared to a couple of years ago) as a sign of resignation: ‘It’s not gonna happen anyways’, this discussion is a waste of time.

If you don’t have enough developer force to both pursue the VL development and support your loyal customers until we reach VL heaven, watch out you’re not loosing the crowd until you get there.

Sincerely yours,

Eno.

2 Likes

i took this to the phone with @eno where i invited him to analyze their project together with us and see where/how vl could be of help there today already and what are the bits keeping them from using vl in production. this is going to happen within the next weeks.

also been on a skype session with @catweasel to understand his particular needs and try to offer vl solutions.

and the offer we made to everyone at keynode17 stands: if you want to get serious with vl and have a particular project in mind we’d love to hear from you and help you getting started!

Thank you for the answer @joreg .

Reading this answer, and after seeing the node 17 keynode, I have questions about the future of VVVV.
Or maybe just one question: does VVVV has a future?

In the keynode, we can understand (between the lines) that VVVV will never have an app exporter, a crossplatform version, a timeline (by the devvvvs)… But VL will.


(at 3:33:02)

For me, VVVV and VL are totally different beasts, and are made for different users.
I remember when I started VVVV, it took me a few hours to understand the basic concepts, and to be able to create a small project (I was a designer, not a developer at all)

For VL, I assisted all the VL workshops at Node17 (the basics by joreg, the concepts by tonfilm and elias, and the VL project by sebastian and anton). I watched hours of workshops from youtube (the most interesting was this one: https://www.youtube.com/watch?v=hUuMMA1JEko&index=1&list=PLG540xv6kfGFIXYVV_hmOZ4U0lGgDuA11). But I’m far away from being able to use VL for any small project.
I know it’s the beginning, everything will be easier when the documentation will be here, the help-patchs…
But for sure, the learning curve of VL is, and will be, harder than VVVV.
I’m happy to see advanced users like dottore or velcrome doing magic things using VL, importing some new libraries easily…
I will try again later, maybe in one or two years, when VL will be more robust.
But I don’t want to replace totally VVVV by VL, it’s too different, I do not find what I need and like with VVVV in VL.

For me, VVVV is a language more than a software, and I like the “granularity” of this language (the ratio between the number of nodes used and the complexity of the result)
It’s just perfect for me. I would not change it for Max, PD, TouchDesigner, or any nodal system possible.
VVVV allows me to prototype something in a few minutes, in every field possible (sound, 3D, video, databases…). I can teach VVVV in a few hours to people who have no idea of what programming is (People like me, who don’t know and don’t want to know what are generics, state/stateless patchs, recursion… People who just want to be able to code things visually, without writing code…)
On the other hand, I can create very complex systems with the simplicity of VVVV: I worked on the Immersio performance, http://immersio.tv/, the virtual reality experience with the clarinet we played at Node17 Off :)
It’s not as complex as the @eno impressive project tree before in this post, but the result is very complex, when the patches behind it are simple. Like Eno said before, the most complex task was to manage the scale of the project (a LOT of workarounds to de-evaluate things, to optimise, to load and unload things at the right moment…). For me it’s a major weakness of VVVV.

Could you make a clear statement in a blogpost about what is the future of VVVV ?
Because it’s never clearly said, but all the indicators since last year go in the direction of: “no more new features for VVVV, everything new is for VL”.

What I (we?) would like to hear, it’s something like: “ok, we worked hard these last months on the Import Library thing for VL, it will be a game changer for both VL and VVVV, but now we are coming back into VVVV on the next months to give you some long awaited things…”
(the UI in a separate thread, the crossplatform app, the app-exporter, the integrated timeline …?) .

But I’m afraid you will rather say something like: “forget about VVVV, it’s something from the past, look at the future, VL is the perfect tool for you…”

HOPE :)

1 Like

@ludnny What you describe is exactly the argument I wanted to pursue in the workshop `‘Programming Language vs. Authoring Environment’ .

Yet, in that sense I wouldn’t follow your line:

VL is much more of a language compared to v4, and that’s been the whole point of creating it.
V4 has the ease of use, because it is very flat, and has the ability to hold a lot of settings / data / adjustments, which makes it perfect for ‘quick n dirty’ design work.

As it stands, I don’t see how VL can hold the same amount of data without becoming totally cluttered. The fact alone that you (currently) have to create an iobox for every value that you want to set, practically renders it useless for the classic v4 usecase. And so may be the whole approach of VL - but I also see that a lot of effort is taken to bring the convenience of v4 into VL by importing some of the nodes and concepts.

VL is made to create logic.
V4 is made to create content.

That’s how I’d put it. And this is also how the community for v4 is biased.

Now you could say that the specific problems that occur in very large projects are in fact language problems - not design problems - and may be overcome by the features of VL. But we might end up having a solution for the scaling issues, not being able to do design work anymore. That’s at least for the near future, and @joreg, sorry to say, but this is what I’m mostly interested in. I can’t wait another two years. We need solutions for these particular issues now.

I don’t see how these two ends could fit together. So I’m very happy to follow @joreg s invitation and analyze the problems and learn how he’d address them. I’ll report with our findings.

5 Likes

I would like to chime in to what eno said with a little bit of hardware context: CPUs will becomer wider, not faster. Today we are maxing out around 4,5GHz. More cores can easily be bought, more speed per single thread will get sparse in the future or never reach this level any more. By itself this is not a problem, because as time progresses the amount of CPU-power we can work with will become even more gigantic - if we can use it.

This means we will have to abandon the single thread philosophy (some nodes already do this) and split the whole of vvvv into multiple threads. This will be complicated, because solving and evaluating a dependency tree in parallel is difficult, but it’s possible.
Running the Mainloop (aka timing source of truth), most nodes and the UI in a single thread might work for the next 2 to 3 years. After that the bigger projects will simply not be possible anymore. Well, they would be possible given enough development time, but who doesn’t have a deadline?

If we have to employ 2 coders for building the project and 4 for bringing the project to 60 fps, then I will have to go look for another framework/software stack. Building everything in VL is a theoretical solution, that only works if you have enough programmers or time for training them. We all know the learning curve.

I do not see the need for manual backgrounding of subpatches, but I absolutely see the need to spread the weight of vvvv over multiple cores.

1 Like

i have to second eno in terms of VL not being a solution for our kinds of projects. we have massive lists of settings (read IO boxes), shader and light management and timelined animations. none of these things are comparable / available in VL. and in terms of number crunching and string operation there is not much difference between c# and VL for me.

initialize nodes / patches is interesting. you can somehow achieve a similar behaviour with S+H etc. but it can be tedious. having background thread nodes / mode would be very useful too.

1 Like

I really like @eno’s proposal: Invent a possibility to evaluate nodes lazy on a/some background thread(s) and let the user find useful ways of such a feature.
Of course, I can imagine a vvvv where the system tries to find the best threading strategy automagically, but that is a very complex task and I believe it would absorb too much of devvvvs ressources. It’ll either never be finished/bugfree or not even started…

@UI in separate thread
A (maybe) simpler solution might be to take enos proposal and make all ioboxes lazy. So, one can tweak a patch (with client present), but changing the graph will still lead to stutter - which I think is totally ok compared to a recompile/restart scenario from conventional software development.

Still, UI in a second thread would be great. Really great. (It would be so greeeeeat)


Disclaimer:
I only try to find a compromise between “forcing vl development” and “lifting vvvv to a higher level”. I personally totally want vl to be the successor of vvvv. The sooner, the better. On the other hand - like @eno, @u7angel or @rockbert stated before - we also still use mainly vvvv in our projects (though some vl in each project when it comes to wicked logic and data-juggling) and want it to be faster/better/more powerful.

I think what is described as a difference between authoring and coding or logic and content is imho just a matter of level: extremely high-level nodes in vvvv vs. (also) extremely low-level nodes in vl. even the ‘+’-node is a big thing in vvvv. (automatic wrapping, conversion of different types,…). still, i totally see the lack of such high-level nodes in vl. This is the missing library.

I’d love to see (when b36 with importing and interface features is out) a open-source node-library to address the issues connected with a (imho) missing high-level node-library.


hey, let’s keep discussing (here and not on the phone/skype). I guess there are many more opinions out there.
And @devvvvs: Talk a bit more on your roadmap (i know it’s a bad situation when things delay, but the users need an deserve that informations. Tell us more about your estimates, plans, wishes, ideas, concepts or problems).

[insert image of 2 Cent coin here]

5 Likes

What could be useful is to have a ctrl+/allowmultiple , using shared memory or similar to communicate , but in a way that you dont have to count how many bytes you can send, etc. just generate a “subpatch” in another vvvv instance.

Allowmultiple Is an excellent feature, but not used as much, at least in my experience because it takes more time to reorganize data being sent.

@sebl I’ll lend these 2c to you… Just remember it’s my 2c, so remember to give them back.

i totally absolutely 100% agree with the posts of eno and ludnny.

since i can not add more facts i just wanted to post my YES :
yes, eno youre right.
please devs dont forget about vvvv

vl will not replace vvvv, and when i learn new Software, it will not be vl, it will be more userfriendly stuff like unreal,…
but
dear devs, believe me, vvvv user base is still expanding and especially in my Job i often see how new users learn vvvv because ist the easiest tool to solve ar/vr design problems. they will never learn vl because they are ui designer not (so much) developer, vl is not intuitive fot them.

so pls dont stop making vvvv better

1 Like

I feel you @Eno.

Large patch performance is an issue. Lots of switches and working with the evaluate pin, but a lot of times its not possible to achieve the desired result, as you dont want to completely disable something, but just give it less priority. Also some way of using the power of multiple cores would be great.

I am already using VL in a small (put performance hungry) part of the project. Now there arent really any major single bottlenecks, but the sheer size of the project adds up to a requirement for lots of CPU and GPU Power. With Superphong enabled, I need a GTX1070 and i5-7600k to get decent performance (around 45fps@1080p), but on anything less its running rather slow.

Even though I have some basic coding skills I always felt that vvvv had just the right amount of complexity to be understood by non-coders and create even larger projects. So I share the sentiment, that I would really love to see some improvements to vvvv or a roadmap thereof as well.

I think one of those little niggles that I always wanted to have is zooming in patches like in VL. It cant be very hard as it also works in the finder since forever. Dont understand why this useful UI enhancement hasn’t made it into vvvv after so many years, but is in VL from the start, as I can see no single down-side to it, but only upsides. Also S+R sorting/searching as eno suggest, so I dont have to scroll through the 200 or so send strings to find one - right now they are vaguely sorted by time created, but some just appear in random places. I think some simple UI/UX improvements would be a good start to let non-VL users feel like there are improvements coming to vvvv, which are not purely “technical” and get a new generation of users excited for this incredible tool, just as you have done with the refreshed look and feel of Node17.

Happy to assist in any way I can.

@seltzdesign
the vvvv UI is based on addflow, if i‘m not mistaken. the finder uses something else. that‘s why there are differences.

this comes down to the old discussion why not iterate vvvv. replace the UI, then replace the delphi core and nodes and after that maybe think about new language features. but this should have happend years ago, maybe right after the introduction of c# plugins.

devs decided to go a different route as we know.

not sure what would be the solution right now. VL is not ready to replace vvvv. and vvvv is not getting enough dev time due to VL not being ready.

@u7angel thanks for clarification. That makes sense. Oh well, thats just how it goes I guess.

Lets see what the future holds. I guess vvvv will always be there as it is today, but more and more things will make it to VL. VL actually also has the zoom feature, even though I think the VL UI is not there yet - too confusing and inconsistent to my liking. I get how vvvv and windows and inspektor work, but I just dont “get” the VL UI yet. Trying to make everything totally minimal, always leads to compromises down the road, when things get more complex and minimal quickly turns into complicated. I have the comparison to Grasshopper, which I use a lot and which is sort of on the other end of the spectrum UI-wise, where everything is really graphical and I have to say its much more fun to use. I guess even though I dont like Max/MSP so much, I think their approach to GUI and how they mix the programming and presentation version of windows is pretty much a perfect balance for me and how I would love vvvv to look.

I’m really glad that after an initial silence, this discussion is picking up among pro users, and that many people express the urgent need for a feature update for the old v4.

I agree that it is probably a waste of time to bring smaller features like zoomable UI to the old v4. I can live with the way it is right now for a while.

But I want to stress that I think it is absolutely crucial for the survival of the v4 community to make sure it’s not drying out in the transition process. It’s worth to invest a couple of moths into the old v4 to cure the most pressing needs and to keep up with the competition. The people you keep entertained now will bring VL to life with their experience and passion. It will be much harder to build a new community from scratch.

Find a way to increase the power of v4 by offering a simple way of using more of the available hardware resources. Don’t reinvent the VheeL.

7 Likes

I have a question, those super big projects, would be easier to build or better performant in other software ? Unity unreal or Touch designer ? Or will they have the same problems in the end and you will require complex programing (like vl) to make it work ?

I’ve never seen really complex big projects on touch .

Clearly unity and unreal have them (games) but Its usually what those software are made for.

Unity and unreal are object oriented and vvvv not that’s why such overhead happening. That why using vl in conjunction with flow control will give you more perf then pure vvvv solution. On such big projects I would recommend to use some custom plugin set to reduce overhead…

Adding my 2cents I can just repeat @eno remark: “(…) it is absolutely crucial for the survival of the v4 community to make sure it’s not drying out in the transition process.(…) It will be much harder to build a new community from scratch.”

@eno
And that’s why I stressed so much about certain aspects in a few threads about VL. Because I care about all of this, not for the sake of critique.