About MarvinW

MarvinW · ‎10-19-2023

That's really interesting to know. How would such a jump table look like for a switch statements whose cases are 1, 50 and 1000 though? It sure won't build a table with 1000 entries just so it can look up the jump target. So it needs to check individually again. Doing a binary search on a sorted table is still the best the compiler can do, at least from what I can come up with. Curious to learn more. In general I don't trust the TwinCAT compiler to do a lot of optimizations because basically every program is running in super debug mode all the time. But I don't know any information for a fact regarding this topic. If your test shows that CASE is faster than ELSIF and my test shows that a self-made table is still faster than CASE, even in a case where the jump targets are all adjacent, then it seems the compiler really creates a table but not quite as efficient as it can? My main concern is not that a PLC cannot handle many thousand IOs. My concern is that we should keep an eye on performance every now and then, especially with software that is running on many instances. If you have 1000 Nexeed machines with BinIo in the field and you save just 1% CPU load of all of them, then you saved 10 PLCs worth of computing power. Just by changing an export template that ships with your engineering. BinIo is probably not the biggest impact BCI can achieve, but it's one that I was able to do experiments myself.

MarvinW · ‎08-30-2023

Of course I can understand that you don't just take code from someone on the internet and integrate it into your flagship product 😛 I'm glad we agree on the Replace Constants settings. I also advise my colleagues to activate this setting, although my main concern is not the performance gain. Instead, my argument is that not having this setting allows the PLC engineers to modify constants at runtime like any other variables. Someone may accidentally (or even on purpose) modify a constant of a running machine to test something and then leave the machine without actually changing the constant in the code. Then a restart of the machine by the customer at some later point in time will restart the PLC program with different behavior than when we left it. Not good. Like you said, the constraints are hardly important, whereas the benefits are attractive.

MarvinW · ‎08-30-2023

I expect the bottleneck is rather the CPU and not the memory. I heard you mention memory concerns before, but I am a bit surprised by this actually. I don't see how our PLCs would be even remotely constrained by memory at the moment. The CPU on the other hand is very perceivable as a limited resource. In my example above I'm running at 48% CPU usage with a 5ms cycle time but I'd prefer to go faster than this. Why should I be concerned about memory usage, too? Also, I am not familiar with the memory model of the TwinCAT PLC runtime, but it might be a small comfort that the large struct array can be implemented as VAR CONSTANT. This way, if "replace constant" is active the whole data can go into the code or text memory and doesn't have to be on the heap. At the same time, since the methods are much smaller and a lot of the text (in particular the event additional text strings) is not compiled into the code or text area anymore, the overall memory usage should actually be quite similar! I ran the original version and my proposal through my project and got the following compiler output (although I am not 100% sure what these numbers mean and whether they can be trusted and are meaningful): Memory area Original New Proposal Generated code 2084112 2066608 Global data 4300269 4321077 Total (code and data) 7086832 7090136 Special memory (IO, persistent etc) 128000 128000 So the code memory goes down by 20000 and data goes up by 20000. It seems that the compiler either doesn't take the "replace constants" very seriously or the data area also encompasses the text area and that's where the big structure is stored. Anyway, overall it seems bigger by less than 4kB. And a 0.05% increase in memory seems like an acceptable price for 1% CPU 😅 This is a bit off-topic now, but just writing about the "replace constants" settings, is there a recommendation from BCI which setting should be used and if so, is there some documentation that says so and why?

MarvinW · ‎08-29-2023

Yes, and I want something that is a little bit more official than the astersik so everybody knows what it means and it can be supported by the other tools 🙂 It seems nexidator correctly understood my initial requirement.

MarvinW · ‎08-11-2023

In BinIo, most of the methods are implemented with a CASE structure and a single case for each IO. According to my understanding the compiler turns this into very long chains of IF-ELSIF-ELSIF-ELSIF-ELSIF... And for each IO all conditions need to be checked until the right IoIndex is found. For stations with many hundred IOs this is actually costly. A faster implementation is to create an array with all data that is currently accessed through CASE structures. That's the variable itself (I used a pointer to the original BOOL), the two event numbers and the additional text. Then, each of the methods uses the IDX_ variables to access the correct entry from the array to get the requested data directly. The compiler turns this into an address calculation, which is basically a multiplication and an addition. This only has complexity O(1), instead of the O(n) of the current implementation. Considering that having n IO in your station also means you are probably going to access these n times per PLC cycle, the respective total complexities are O(n) for my proposal and O(n²) of the current implementation. I modified the BinIo export template to test this. See attachment. It also needs a new STRUCT like this: TYPE BinIoItemStruct : STRUCT pVariable : POINTER TO BOOL; EventS0 : DINT; EventS1 : DINT; AddText : EVENTADDLTEXT_T; END_STRUCT END_TYPE My station only has 258 IO in total (inputs, outputs and flags) and doesn't use them very much. My CPU usage went down from 48 to 47. But I simulated a bigger station by adding some more calls to BinIo.GetState and SetState and the difference was 51 to 48. So it does make a difference. Are there any reasons that speak against this solution? I guess how big the effect on speed is also depends on how the most commonly used objects are implemented, e.g. whether they use GetState/SetState or just grab the addresses with GetAddress and then use these directly. And of course what the station programmer is doing in the application directly. I also tested a version where the BOOL variables were directly in the array of the structure instead of a pointer, because that should be even faster, but it wasn't noticable compared to the pointer approach. Also, that would not be a compatible change anymore. This is the V2 in the attached zip.

Bosch Shared

About MarvinW

Re: More efficient BinIo implementation

Re: More efficient BinIo implementation

Re: More efficient BinIo implementation

Re: Feature request: mark what makes a version incompatible

More efficient BinIo implementation

About MarvinW

Re: More efficient BinIo implementation

Re: More efficient BinIo implementation

Re: More efficient BinIo implementation

Re: Feature request: mark what makes a version incompatible

More efficient BinIo implementation

Still looking for something?