Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Are stack machines inherently faster? Date: Thu, 17 Nov 2016 15:58:33 -0800 Organization: A noiseless patient Spider Lines: 28 Message-ID: <87vavld5g6.fsf@nightsong.com> References: <40b9c778-3a98-450b-b65b-6cbaee444921@googlegroups.com> <6a4467c7-1b3b-4e36-b10d-c6a4c98433c6@googlegroups.com> <0ebbb961-6537-4472-8170-f899bd801edb@googlegroups.com> <34e47822-500b-421c-a53d-a9e0fcc1f6ae@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="5bf5bad05786a48fbd1d205fec1a8158"; logging-data="22012"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vjWItxEM/N0EIwpdtUYpu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:42kJRQqxoybP0basIC4TTa6Ddgg= sha1:DlLx/RbXPfe6cbAebEjK0OyZBn4= Xref: csiph.com comp.lang.forth:52705 mhx@iae.nl writes: >> My own experience is that in real world projects, even ITC Forth >> performed very well, if you allow for a hand coded primitive ... > It depends on what you call "very well." I would say that you're > describing a popular Forth myth. It is not true. I don't know about Foxaudio, but I'd say "very well" means the ITC performance is enough to satisfy users' real-world requirements. Most of my stuff these days is written in Python and it's fast enough for my purposes, and Gforth-itc is probably >10x faster than Python. I've never written a Forth program that wasn't a benchmark, that used enough computation time for me to notice. Even big problems that need a lot of computation can often be parallelized. Computers are cheap and it's often better business to just buy more of them, than to increase software development costs or decrease maintainability. > CLF threads that posed problems that piqued people's interest and > resulted in a flurry of smart algorithmic tricks Sure, good algorithms can produce a far bigger speedup than careful optimization of dumb algorithms can possibly hope to. > that would have been a lot more cumbersome to come up with, design, > and test in other languages. I'd be interested in seeing an example.