[SOLVED]native emitter - why not always enable?

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
jickster
Posts: 628
Joined: Thu Sep 07, 2017 8:57 pm

[SOLVED]native emitter - why not always enable?

Post by jickster » Sun Apr 29, 2018 12:42 am

Code: Select all

 On the other hand, the byte code and native emitters support all of Python.  
https://www.kickstarter.com/projects/21 ... ontrollers

If @micropython.native works on ALL of Python, why wouldn’t you enable it by default?

Besides increase in code size, is there a reason why you wouldn’t enable it for everything?
Last edited by jickster on Mon Apr 30, 2018 7:42 pm, edited 1 time in total.

User avatar
pythoncoder
Posts: 3367
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: native emitter - why not always enable?

Post by pythoncoder » Sun Apr 29, 2018 6:14 am

I imagine, of its nature, it needs to be rewritten for each machine architecture. In the days of the kickstarter MicroPython ran on the Pyboard. Ports to other archs came later.
Peter Hinch

jickster
Posts: 628
Joined: Thu Sep 07, 2017 8:57 pm

Re: native emitter - why not always enable?

Post by jickster » Mon Apr 30, 2018 2:55 am

pythoncoder wrote:I imagine, of its nature, it needs to be rewritten for each machine architecture. In the days of the kickstarter MicroPython ran on the Pyboard. Ports to other archs came later.

That doesn’t answer my question.

For a given board where @micropython.native is supported, if I don’t care about code size, why wouldn’t I enable @micropython.native permanently?

Seems like the guaranteed speedup is a no brainer If code size isn’t an issue.


Sent from my iPhone using Tapatalk

stijn
Posts: 321
Joined: Thu Apr 24, 2014 9:13 am

Re: native emitter - why not always enable?

Post by stijn » Mon Apr 30, 2018 8:17 am

Code size is likely the reason why it's not on by default, so if you don't care about that by all means go native. One caveat I can think of: native emitter probably doesn't see the same amount of usage as the rest of the code because less people use it. As such there could be a higher chance of bugs yet to be discovered.

User avatar
pythoncoder
Posts: 3367
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: native emitter - why not always enable?

Post by pythoncoder » Mon Apr 30, 2018 9:12 am

Those of us who write large programs need to freeze them as bytecode. You can't freeze native code.
Peter Hinch

User avatar
Roberthh
Posts: 1370
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: native emitter - why not always enable?

Post by Roberthh » Mon Apr 30, 2018 9:16 am

There was a thread about being able to freeze both native code & viper code. It seemed not too difficult, but seemd not to be on the top priority list and has not been further discussed.

jickster
Posts: 628
Joined: Thu Sep 07, 2017 8:57 pm

Re: native emitter - why not always enable?

Post by jickster » Mon Apr 30, 2018 3:23 pm

Roberthh wrote:
Mon Apr 30, 2018 9:16 am
There was a thread about being able to freeze both native code & viper code. It seemed not too difficult, but seemd not to be on the top priority list and has not been further discussed.
If you have a .py and mark some, not all, functions as @micropython.native, is the entire file ineligible to be frozen?

User avatar
Roberthh
Posts: 1370
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: native emitter - why not always enable?

Post by Roberthh » Mon Apr 30, 2018 3:26 pm

If you have a .py and mark some, not all, functions as @micropython.native, is the entire file ineligible to be frozen?
Yes, as far as I can tell. You have split it into two files and import the native section.

Post Reply