Python and the need for speed

[bartc]

On 11/04/2017 15:56, Steve D'Aprano wrote:

> The truth is, all of us in this discussion -- including me -- are "random,
> ignorant commentators". I don't believe that any of us are experts at
> writing compilers.
>
> Bart is a possible exception, for some definition of "expert" -- he claims
> to have written a quite fast, moderately dynamic language, but nobody else
> (that I know of) has used it.
>
> And no offence to Bart, but from his comments and questions on the list, I
> think it is fair to say that whatever knowledge he has on language design
> was probably state of the art thirty years ago. Bart sometimes expresses
> surprise and confusion over concepts which are common in languages like
> Javascript, Python, Perl, Ruby etc. These are not young languages! Python
> is over 20 years old, Perl is even older. So I suspect Bart's knowledge is
> probably from the 70s or 80s?

Yes, about then. But it means I have a lot of experience getting this 
stuff to work briskly on limited hardware, and I can identify bloat and 
inefficiency.

(My latest project is a C compiler, which currently generates asm source 
(later it will run from source like Python). But it takes 50ms to 
process a 30Kloc file that then takes 90 seconds, nearly 2000 times 
longer, to assemble into .obj. That sounds like there's something wrong 
to me with that assembler.

So I think I can question the efficiency of other people's software. My 
experience may be out of date but that 50ms - half of which is 
generating that damned asm source - was from yesterday!)

However, when the obstacle is a particular language design then the 
options are more limited. I think CPython does remarkably well given the 
language. And the official byte-code (which can do with tweaking as that 
Wpython project demonstrated).


-- 
bartc