On Mon, Sep 9, 2019 at 4:12 AM Mark @pysoniq <m...@pysoniq.com> wrote: > > "I don't think the ctypes wrapper in itself is very interesting." > > Well, we disagree on that! I think that automatic generation of a ctypes > wrapper to connect Python to assembly is interesting and a huge timesaver. > > "I don't know where to find those blog entries." > > The blogs can be reached directly at: https://pysoniq.com/text_16.htm and > there is a link "Blog" on the home page. That link should light up when you > go to the link I've just provided. > > If you read the 3rd & 4th entries -- Assembly Optimizations in Complex > Calculations — Part 1 of 2 and Assembly Optimizations in Complex Calculations > — Part 2 of 2, those blog posts contain a step-by-step breakdown of > translating Python source to assembly language. And the NASM source is > linked there and is also available at the Resources link, so you can follow > along between the Python source and the assembly listing. > > Your questions are helpful! >
Redirecting this to python-list as this is not discussing any actual Python language or interpreter ideas. Please remove python-ideas from cc for future replies. Your blog breaks the browser's Back button. Please don't do that; if you want people to read your content, make it easy for us to do so. How does your assembly translation cope with the possibility that "round(h, 2)" might not call the Python standard library round() function? You go to great lengths to show how you can optimize a specific type of calculation that appears to be specifically relating to floating-point math, including a number of steps that are basically the same as a peephole optimizer could do - or, for that matter, any programmer could easily do manually (I don't see a lot of loops in the real world that go "for a in n" and then "v0 = a" with no other use of a). What would happen if integers were involved? Remember, Python's integers can happily grow beyond any CPU register - will your transformation maintain the semantics of Python, or will it assume that everything is floating-point? > This line is self-explanatory. It takes the input array "n" and loops > through each data point. The input array "n" is 64-bit double-precision > floating point. How do you ensure that this is an array of 64-bit floating-point values? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
