Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Using Forth in the current year. Date: Mon, 30 Nov 2015 21:22:30 -0800 Organization: A noiseless patient Spider Lines: 79 Message-ID: <87k2oyd9pl.fsf@jester.gateway.pace.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="7fb8b9b5119ed656382b2cea88166c4f"; logging-data="24649"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rDnB/8xdjNKeEa1MJIaq2" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:pMi9fvDpPKdrMPpXEHIvT+q6tHA= sha1:e6c5JyvNpHxmwfDhexPcaxda1uM= Xref: csiph.com comp.lang.forth:43996 Julian Fondren writes: > But the Forth webserver runs in 22MB fixed memory and the Erlang > webserver starts out using 1.1GB of RAM. npm's 'http-server', written > in Node.js, starts out consuming 772MB of RAM. Is that on a 64 bit system? Even if yes, those numbers all sound way too high. Erlang runs ok in 64 meg embedded systems and Forth as you know is generally tiny. I have no experience with npm http-server but people use it all the time on Beaglebone/RPi type systems with 256MB or 512MB and it doesn't use all the memory. I did look at your Forth web server and thought the implementation approach was pretty cute, though it was SwiftForth-dependent so I didn't try it out. I'd expect it to not need (much) more memory than the httpd's found in (say) OpenWRT boards, which usually run in a few hundred K or less. Also, Fossil (fossil-scm.org) is a complete VCS, bug tracker, wiki, and web server, written in C with an embedded SQL database (SQLite), all in a single image of 2MB or so (used to be under 1MB but it's gotten bigger recently). > Have you heard that there's no place for Forth outside of embedded > hardware? If you've got even 1MB of flash, isn't it time to use a > 'real language'? RAM can also be a serious constraint ;-). > poll() ... is used mainly because its data structures and values are > well-documented, as opposed to select() for example where you'll told > to use some magic C macros, and nevermind what they do. Select just returns bit maps of which fd's have i/o available. But poll or epoll are better if you have lots of active channels. > For $10/month or so, you can get an account on a shared server that > has 64GB of RAM. But, it's running MySQL and Apache already, > configured for thousands of sites already. And by policy you're not > to have long-running processes, since people would of course have > servers at 1GB each if allowed, so you have to use CGI for dynamic > content. Here, no, memory pretty much doesn't matter. Look up erlangonxen.org - you can spin up a complete Erlang VM running directly on a Xen hypervisor (no *nix kernel) in about 20 msec. So you can launch one from scratch on every request, no need for long running processes or even long running computers ;-). > You would strain something, trying to write a Forth CGI program that > used as much RAM as PHP does. PHP can run in a few meg, Forth should of course use less. > Even with the $10/year option, 1GB of RAM is pretty tight when you > need sshd, some other minor services, and a database server, in > addition to your 1GB-resident webserver. Nah, to misquote Bill Gates, 64MB should be enough for anyone. http://lowendbox.com/blog/yes-you-can-run-18-static-sites-on-a-64mb-link-1-vps/ Really though, the JS bloatware that everyone these days puts into their web pages need gigabytes of memory on the client side, so I wonder what a 64MB server is proving. > Apache has a defect. Nobody uses Apache on small sites any more. > If you have all of 64GB of RAM, and only 64 customers to that server, > then you can't encourage them to run their own Node.js Express I'd be interested in the memory footprints if you run your tests again under a 32 bit kernel. People run Node all the time in tiny little VPS's. > All continues to matter that "doesn't matter anymore". So Forth is > pretty good, and you should use it. It will still be good in five > years when a typical server will have a full 1TB of RAM. An Erlang-like Forth system with isolated lightweight processes instead of the classic shared memory multitasker could be interesting. I guess OForth is something like that.