[Beremiz-devel] The output file of beremiz is real machine code????

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi,
The beremize's executive process as fowllow:

IEC61131-3 ST/IL——>C code——>output file

I have two qustions:
(1)the output file is binary code???
(2)the output file is real machine code???



--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-01-23 02:13, [hidden email] wrote:
> Hi,
> The beremize's executive process as fowllow:
>
> IEC61131-3 ST/IL——>C code——>output file
>
> I have two qustions:
> (1)the output file is binary code???
> (2)the output file is real machine code???
>

End result is real machine code of your target.

--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi,
Thanks your reply.
I have learned about some other plc tools,such as multiprog and codesys.
And I have test the benchmark of mulitprog and codesys

1000 line BOOL IL test ,the result as follows:

multiprog:3-4us
codesys:2-3us
beremiz:200us

The gap is clearly , so I doubt the output file is real machine code ,cpu's
instructon list code.

Not the the middle code which runtime to analysis and to execute

so ,what's the real reason of the so big gap?





--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-01-23 02:45, [hidden email] wrote:

> Hi,
> Thanks your reply.
> I have learned about some other plc tools,such as multiprog and codesys.
> And I have test the benchmark of mulitprog and codesys
>
> 1000 line BOOL IL test ,the result as follows:
>
> multiprog:3-4us
> codesys:2-3us
> beremiz:200us
>
> The gap is clearly , so I doubt the output file is real machine code ,cpu's
> instructon list code.
>
> Not the the middle code which runtime to analysis and to execute
>
If you doubt, you can look at it. ;-)
It's open source, nothing is hidden behind the doors.


> so ,what's the real reason of the so big gap?
It's hard to say, there could be many reasons for that. Hardware performance, [RT]OS
configuration, compiler optimization, test project difference, wrong
assumption in test suite.
Could you post your Beremiz test project?
What platform (hardware and software) do you use for your test?

--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi

The multiprog ,codesys and beremiz have the same test-platform RaspberryPi2
B .
The test code are the same, and the follow is tested on beremiz
Perfornance.rar
<http://beremiz-devel.2374573.n4.nabble.com/file/t13/Perfornance.rar>  




--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 18-01-23 13:08, [hidden email] wrote:

> On 18-01-23 02:45, [hidden email] wrote:
> > Hi,
> > Thanks your reply.
> > I have learned about some other plc tools,such as multiprog and codesys.
> > And I have test the benchmark of mulitprog and codesys
> >
> > 1000 line BOOL IL test ,the result as follows:
> >
> > multiprog:3-4us
> > codesys:2-3us
> > beremiz:200us
> >
> > The gap is clearly , so I doubt the output file is real machine code ,cpu's
> > instructon list code.
> >
> > Not the the middle code which runtime to analysis and to execute
> >
> If you doubt, you can look at it. ;-)
> It's open source, nothing is hidden behind the doors.
>
>
> > so ,what's the real reason of the so big gap?
> It's hard to say, there could be many reasons for that. Hardware performance, [RT]OS
> configuration, compiler optimization, test project difference, wrong
> assumption in test suite.
> Could you post your Beremiz test project?
> What platform (hardware and software) do you use for your test?
Hi  Wumengkui,

thanks for bringing this topic up.
First your code doesn't have any IL code. If you would rewrite this in
IL, then performance would be much better. Because IL is much more
lightweight that other languages and is better optimized by compiler.
For example on my desktop machine: (i7-6700k) with your test I've got
11us and for the same logic written in IL I've got 0.025us. It's
almost 500 times boost.
This is because GNU C compiler (GCC) is smart enough to optimize out all
useless code duplication to get the same results. This is one thing.

Second, as I said compiler optimization level matters. Default
optimization level in GCC is -O0 (no optimization).
You can read more about optimization levels at [1].
You can set your own optimization level in CFLAGS in project properties.
I change default optimization level for Beremiz to -O2 in the future.
It should be save, get much better performance and can be overwritten
by user's CFLAGS.

I've tested performance different on two platforms:
- desktop amd64 with i7-6700k stock clocks;
- Beaglebone Black (BBB), ARM Cortex-A8, 600Mhz.

1) AMD64 (gcc 7.2.0)
-O0 (default): 11us
-O2:           4us (2.75 faster)

2) ARM (gcc 4.6.3)
-O0 (default): 273us
-O2:           142us (1.92 faster)

As you see I've used pretty old gcc on BBB. Most likely newer gcc
would give better results. It usually does.

Third, FBD/SFC/LD generates pretty heavy code now (some of problems
could be addressed in Beremiz). FBD/SFC/LD are converted into ST code.
You may look at generated code, where is button on the toolbar for
that. So you are actually testing performance of ST, not IL.
If you look at generated C code, you look that code for every AND and OR block
has implicit EN/ENO inputs and are implemented as functions with variable
number of arguments [2] (what a great feature that you may look at the code. ;-)).
GCC will not inline functions with variable number of arguments, as a
result we have function call overhead, variable arguments handling and
gcc don't have opportunity to aggressively optimize inlined code.
This causes pretty big overhead to execute single OR/AND instruction
like in your case. To address this I wrote patch for matiec, that
addresses this case. For OR/AND/ADD/MUL/XOR it generates
special functions for up to 8 arguments (number maybe changed) and for
more arguments old function with variable number of arguments is used.
These new special functions with fixed number of arguments can be
inlined and further optimization maybe done. The patch is attached.
No GCC specific tricks are used, so theoretically it should work fine
with any C99 compiler.

Here are my results:

1) AMD64 (gcc 7.2.0)
-O0 (default): 11us
-O2:           4us (2.75 faster)
-O2 + patch:   2.5us (4.4 times faster)

2) ARM (gcc 4.6.3)
-O0 (default): 273us
-O2:           142us (1.92 faster)
-O2 + patch:   39us (7 times faster)

Wumengkui, your target (RPi2B) is running 1000Mhz instead of 600Mhz on
BBB. I think you should get with this patch around 23us and maybe even
slightly better with newer compiler.

Mario, does it make sense to apply this patch to your repo?
Additionally I attached test project for Beremiz, where I've tested all changed functions.

1. https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html
2. https://bitbucket.org/mjsousa/matiec/src/29735e347716b5f2da0591b0d0af0505c126aa7d/lib/C/iec_std_functions.h?at=default&fileviewer=file-view-default#iec_std_functions.h-490

--
Best regards,
Andrey Skvortsov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

std_function_performance.patch (23K) Download Attachment
test_arith_expand.tar.bz2 (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On Wednesday, January 31, 2018 13:33:18 Andrey Skvortsov wrote:
> On 18-01-23 13:08, [hidden email] wrote:
> > On 18-01-23 02:45, [hidden email] wrote:
> > > Hi,
>
> Hi  Wumengkui,
>
> thanks for bringing this topic up.

 Yep! We have been mostly focusing on getting things to work. Optimisation
comes later. I guess the 'later' has now arrived ;-)


 Andrey, since you have the setup running, could you perhaps check the impact
of using "matiec -e" on the timings?

>
> Mario, does it make sense to apply this patch to your repo?
> Additionally I attached test project for Beremiz, where I've tested all
> changed functions.
>


 Interesting hack!

 The only downside I see is the hard-coded limit of 199 input parameters. I
find this aspect rather ugly. If somebody has some automatically generated code
that is to be compiled by matiec it would be easy to go over this limit. At
the very least I think we should expand the limit. What do you think? Any
suggestions?

 I would personally have gone for a new intermediate optimization phase in
matiec itself (replacing function calls for the equivalent ST expression), but
then we would have another limitation that it could only be applied to
function calls where no output variable was connected to the ENO output.


 Andrey:
1)
 Did you check that the patch works with "matiec -e", i.e. when the EN/ENO
parameters are removed to make the code execute faster?


2)
 It seems to me that you forgot the possibility that these functions may be
called with a single parameter "a := ADD(42);"
 This is easy to fix.

3)
 Is there any reason you explicitly defined each variation of the functions
example:
+#define OR_BYTE(...)
+#define OR_WORD(...)
+#define OR_DWORD(...)
+#define OR_LWORD(...)

 instead of adding it to the _iec macro so it gets automatically expanded by
the __ANY_NBIT (or equivalent) macro?

 #define __iec_(TYPENAME) \
 ...
 __ANY_NBIT(__iec_)
 #undef __iec_



 Cheers,

            Mario


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-01-31 19:28, [hidden email] wrote:

> On Wednesday, January 31, 2018 13:33:18 Andrey Skvortsov wrote:
> > On 18-01-23 13:08, [hidden email] wrote:
> > > On 18-01-23 02:45, [hidden email] wrote:
> > > > Hi,
> >
> > Hi  Wumengkui,
> >
> > thanks for bringing this topic up.
>
>  Yep! We have been mostly focusing on getting things to work. Optimisation
> comes later. I guess the 'later' has now arrived ;-)
>
>
>  Andrey, since you have the setup running, could you perhaps check the impact
> of using "matiec -e" on the timings?

Amd64, i6700k, 4200MHz, GNU/Linux (non-RT kernel), gcc 7.2.0

-------------------------------------
 Optimization   | EN/ENO |no EN/ENO |
-------------------------------------
default         |   11   |    9.5   |
-O3        |    3.9 |    5.2   |
-O2        |    4   |    4.8   |
-Os        |    4.1 |    3.5   |
-Ofast        |    3.9 |    5.2   |
-------------------------------------
-O3    + patch  |    2.5 |    2.5   |
-O2    + patch  |    2.5 |    2.5   |
-Os    + patch  |    2.5 |    2.5   |
-Ofast + patch  |    2.5 |    2.5   |
-------------------------------------

with patch performance difference is
hardly measurable on amd64.


ARM, BBB Cortex-A8, 600Mhz, GNU/Linux, gcc 4.6.3

-------------------------------------
 Optimization   | EN/ENO |no EN/ENO |
-------------------------------------
default         |  273   |  226     |
-O3        |  141.8 |  106.2   |
-O2        |  142   |  107     |
-Os        |  152.5 |  112.2   |
-Ofast        |  141.7 |  106.2   |
-------------------------------------
-O3    + patch  |   41.6 |   38.7   |
-O2    + patch  |   39   |   38.8   |
-Os    + patch  |   78.8 |   78.8   |
-Ofast + patch  |   41.6 |   38.7   |
-------------------------------------

For embedded systems with size constaints (like Cortex-Mx, AVR and so
on) I usually use -Os. It gets pretty good results, but the code may
run slower (as in case with ARM target).
For GNU/Linux-based systems -O2 is usually a good choice, as you see
the test results.



> > Mario, does it make sense to apply this patch to your repo?
> > Additionally I attached test project for Beremiz, where I've tested all
> > changed functions.
> >
>
>
>  Interesting hack!
>
>  The only downside I see is the hard-coded limit of 199 input parameters. I
> find this aspect rather ugly. If somebody has some automatically generated code
> that is to be compiled by matiec it would be easy to go over this limit. At
> the very least I think we should expand the limit. What do you think? Any
> suggestions?
I agree and me don't like hard-coded limit either. But it was the only
way I could find to solve this problem.
Expanding the limit is not a problem at all. The patch contains Lisp
code for Emacs editor to generate these defines.
Change limit, select and evaluate lisp code.

Another solution would be that matiec would generate different
function calls for functions with small number of arguments and all
other. Like AND__BOOL__BOOL() and AND__BOOL__BOOL_VAR().
So this would help to get rid of these 199 defines. I don't now how
difficult or not-pretty this would be matiec's code.

>  I would personally have gone for a new intermediate optimization phase in
> matiec itself (replacing function calls for the equivalent ST expression), but
> then we would have another limitation that it could only be applied to
> function calls where no output variable was connected to the ENO output.
I thought about that too. This could be addressed in Beremiz as well, but
I've not investigated yet how invasive this fix would be for Beremiz.
This approach solves only part of the problem and in a different way.
I think both approaches may coexist for better end result.

>  Andrey:
> 1)
>  Did you check that the patch works with "matiec -e", i.e. when the EN/ENO
> parameters are removed to make the code execute faster?
Yes, it works. See results above.

>
> 2)
>  It seems to me that you forgot the possibility that these functions may be
> called with a single parameter "a := ADD(42);"
>  This is easy to fix.
Thanks. I didn't even know that it was allowed. Fixed and updated test
project. Both are attached.

> 3)
>  Is there any reason you explicitly defined each variation of the functions
> example:
> +#define OR_BYTE(...)
> +#define OR_WORD(...)
> +#define OR_DWORD(...)
> +#define OR_LWORD(...)
>
>  instead of adding it to the _iec macro so it gets automatically expanded by
> the __ANY_NBIT (or equivalent) macro?
>
>  #define __iec_(TYPENAME) \
>  ...
>  __ANY_NBIT(__iec_)
>  #undef __iec_
>
The reason is C preprocessor limitation.
It's not allowed to have preprocessor directives inside #define.
So I can't generate new macros with __arith_expand(), only C functions.
And OR__BYTE(...) should be macro function to do all these
preprocessor tricks with arguments.
If you have another suggestion how to solve this, I'd be very glad to
know. =)


--
Best regards,
Andrey Skvortsov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

improve_functions_perf.patch (23K) Download Attachment
test_arith_expand.tar.bz2 (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On Thursday, February 01, 2018 16:40:20 [hidden email]
wrote:

> On 18-01-31 19:28, [hidden email] wrote:
> > On Wednesday, January 31, 2018 13:33:18 Andrey Skvortsov wrote:
> > > On 18-01-23 13:08, [hidden email] wrote:
> > > > On 18-01-23 02:45, [hidden email] wrote:
> > > > > Hi,
> > >
> > > Hi  Wumengkui,
> > >
> > > thanks for bringing this topic up.
> >  
> >  Yep! We have been mostly focusing on getting things to work. Optimisation
> >
> > comes later. I guess the 'later' has now arrived ;-)
> >
> >  Andrey, since you have the setup running, could you perhaps check the
> >  impact>
> > of using "matiec -e" on the timings?
>
(...)
>
> For embedded systems with size constaints (like Cortex-Mx, AVR and so
> on) I usually use -Os. It gets pretty good results, but the code may
> run slower (as in case with ARM target).
> For GNU/Linux-based systems -O2 is usually a good choice, as you see
> the test results.
>


 Thanks Andrey, that was really interesting.


> > > Mario, does it make sense to apply this patch to your repo?
> > > Additionally I attached test project for Beremiz, where I've tested all
> > > changed functions.
> >  
> >  Interesting hack!
> >  
> >  The only downside I see is the hard-coded limit of 199 input parameters.
> >  I
> >
> > find this aspect rather ugly. If somebody has some automatically generated
> > code that is to be compiled by matiec it would be easy to go over this
> > limit. At the very least I think we should expand the limit. What do you
> > think? Any suggestions?
>
> I agree and me don't like hard-coded limit either. But it was the only
> way I could find to solve this problem.

 Yep. I can't think of any other way either.

> Expanding the limit is not a problem at all. The patch contains Lisp
> code for Emacs editor to generate these defines.
> Change limit, select and evaluate lisp code.

 Yes, I noticed.

 I think:
  -   100 is too little.
 - 10 000 is too much.

 I would be fine with 1000, but it seems crazy to have 1000 lines of code in
that library file.
 
 What the heck, I seem to have changed my own mind. I'm OK leaving it at 199
for now.



>
> Another solution would be that matiec would generate different
> function calls for functions with small number of arguments and all
> other. Like AND__BOOL__BOOL() and AND__BOOL__BOOL_VAR().
> So this would help to get rid of these 199 defines. I don't now how
> difficult or not-pretty this would be matiec's code.
>

 I considered this too, and don't really like it.
 1 - the cut-off value between AND__BOOL__BOOL_XX() and
       AND__BOOL__BOOL_VAR() would need to be hard-coded in the library
       and matiec itself. These values would also need to match.
       This would be a hassle.
  2 - Additionally, not all extensible functions are getting this treatment,
        so the list of functions where the function call gets changed would
        also need to be hard-coded, and match the library implementation
        (e.g., we would change ADD(), but not MUX() )
        Really ugly!!


 Too many special cases. I would give this a pass for now, especially
considering this part of matiec needs to be cleaned up (currently has 3 copies
of (almost?) identical code in 3 different places).

 Even so, I think in the long run I would still prefer this to the hard-coded
limit to the number of function parameters. As long as everything is well
commented and explained, it should be OK.


> >  I would personally have gone for a new intermediate optimization phase in
> >
> > matiec itself (replacing function calls for the equivalent ST expression),
> > but then we would have another limitation that it could only be applied
> > to function calls where no output variable was connected to the ENO
> > output.
> I thought about that too. This could be addressed in Beremiz as well, but
> I've not investigated yet how invasive this fix would be for Beremiz.
> This approach solves only part of the problem and in a different way.

 If we do implement it, I say it should be done in matiec.
 This way standard ST and IL code gets optimized too, and not only LD and FBD.
 (unless you are suggesting beremiz change the ST and IL code too?)

 It would not really be invasive in matiec. Simply a new visitor that gets
called to do optimization. One more pass. It integrates neatly into matiec
architecture.




   Mario.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi Mario,

On 18-02-01 17:17, [hidden email] wrote:

> > >  Interesting hack!
> > >  
> > >  The only downside I see is the hard-coded limit of 199 input parameters.
> > >  I
> > >
> > > find this aspect rather ugly. If somebody has some automatically generated
> > > code that is to be compiled by matiec it would be easy to go over this
> > > limit. At the very least I think we should expand the limit. What do you
> > > think? Any suggestions?
> >
> > I agree and me don't like hard-coded limit either. But it was the only
> > way I could find to solve this problem.
>
>  Yep. I can't think of any other way either.
>
> > Expanding the limit is not a problem at all. The patch contains Lisp
> > code for Emacs editor to generate these defines.
> > Change limit, select and evaluate lisp code.
>
>  Yes, I noticed.
>
>  I think:
>   -   100 is too little.
>  - 10 000 is too much.
>
>  I would be fine with 1000, but it seems crazy to have 1000 lines of code in
> that library file.
>  
>  What the heck, I seem to have changed my own mind. I'm OK leaving it at 199
> for now.
>
I'm OK with any number you OK with. Originally I thought about 1000 as
well, but I didn't want to scary people with so many defines in the
proposed patch.

What about number of inline functions? Is 8 OK or should be increase
the number?


> > >  I would personally have gone for a new intermediate optimization phase in
> > >
> > > matiec itself (replacing function calls for the equivalent ST expression),
> > > but then we would have another limitation that it could only be applied
> > > to function calls where no output variable was connected to the ENO
> > > output.
> > I thought about that too. This could be addressed in Beremiz as well, but
> > I've not investigated yet how invasive this fix would be for Beremiz.
> > This approach solves only part of the problem and in a different way.
>
>  If we do implement it, I say it should be done in matiec.
>  This way standard ST and IL code gets optimized too, and not only LD and FBD.
>  (unless you are suggesting beremiz change the ST and IL code too?)
>
>  It would not really be invasive in matiec. Simply a new visitor that gets
> called to do optimization. One more pass. It integrates neatly into matiec
> architecture.
>
Agree. matiec solution would be better here.


--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Hi,
The benchmark of yours is really fascinating.So I test it follow your way.
Before, I though using the FBD/LD/ST/IL , the middle file of ST is nearly
same by matiec.
Now, I use the real IL language to get the real answer. And I using -O2 to
optimize the gcc, and using patch to optimize the matiec. The benchmark as
follows:
          FBD:200us
            IL:78us
          -O2:26us
-O2+patch:0.7us
Wow,wow, the benchmark is really crazy,especially the patch function.
But when using the patch, my timer TON in the project works not
well,refering to the attchment
Performance_IL_TON.rar
<http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_TON.rar>  
So I changed another way to get the benchmark,refering to the attachment
Performance_IL_New.rar
<http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_New.rar>  




--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-02-02 19:59, [hidden email] wrote:

> Hi,
> The benchmark of yours is really fascinating.So I test it follow your way.
> Before, I though using the FBD/LD/ST/IL , the middle file of ST is nearly
> same by matiec.
> Now, I use the real IL language to get the real answer. And I using -O2 to
> optimize the gcc, and using patch to optimize the matiec. The benchmark as
> follows:
>           FBD:200us
>             IL:78us
>           -O2:26us
> -O2+patch:0.7us
> Wow,wow, the benchmark is really crazy,especially the patch function.
> But when using the patch, my timer TON in the project works not
> well,refering to the attchment
> Performance_IL_TON.rar
> <http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_TON.rar>  
> So I changed another way to get the benchmark,refering to the attachment
> Performance_IL_New.rar
> <http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_New.rar>  
Sure your example breaks, I've told you about this in my first answer.
In your example Performance_IL_TON you rely on changing timer's ET output during the
cycle. But it's not the case. __CURRENT_TIME used by all software timers is
updated between PLC cycles.

Therefore I've suggested to use own function
block that on GNU/Linux-based targets synchronously read current
system time.

BTW why you wrote your own wrapper for standard TON timer?

--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment