Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Thomas Koenig Newsgroups: comp.compilers Subject: Re: Portable Software (was: fledgling assembler programmer) Date: Fri, 31 Mar 2023 05:19:14 -0000 (UTC) Organization: news.netcologne.de Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-03-041@comp.compilers> References: <23-03-001@comp.compilers> <23-03-002@comp.compilers> <23-03-003@comp.compilers> <23-03-007@comp.compilers> <23-03-008@comp.compilers> <23-03-012@comp.compilers> <23-03-017@comp.compilers> <23-03-022@comp.compilers> <23-03-029@comp.compilers> <23-03-034@comp.compilers> <23-03-036@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="97448"; mail-complaints-to="abuse@iecc.com" Keywords: tools Posted-Date: 31 Mar 2023 07:42:09 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3441 gah4 schrieb: > For system like Matlab and Octave, and I believe also for Python, > or one of many higher math languages, programs should spend > most of the time in the internal compiled library routines. They should, but sometimes they don't. If you run into things not covered by compiled libraries, but which are compute-intensive, then Matlab and (interpreted) Python run as slow as molasses, orders of magnitude slower than compiled code. As far as the projects to create compiled versions with Python go, one of the problems is that Python is a constantly evolving target, which can lead to real problems, especially in long-term program maintenance. As Konrad Hinsen reported, results in published science papers have changed due to changes in the Python infrastructure: http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/ At the company I work for, I'm told each Python project will only use a certain specified version of Python will never be changed for fear of incompatibilities - they treat each version as a new programming language :-| To bring this back a bit towards compilers - a language definition is an integral part of compiler writing. If - the specification to o be implemented is unclear or "whatever the reference implementation does" - the compiler writers always reserve the right for a better, incompatible idea - the compiler writers do not pay careful attention to existing specifications then the resuling compiler will be of poor quality, regardless of the cool parsing or code generation that go into it. And I know very well that reading and understanding language standards is no fun, but I'm told that writing them is even less fun.