Hacker News Reader

Comment by FrozenVoid | Hacker News Reader

50% of speed isn't the whole deal. Latency and memory use matter too. Audio,Video, Games, Networking,etc require minimal latency. Memory use is also critical: when you data structures explode into GBs of RAM, a twice larger means you can run out of RAM and start swapping to disk, lowering performance substantially. Finally 50% of speed in isolated benchmarks with minimal GC use doesn't mean 50% inside a complex application, where GC can pause the current thread or steal time continuously.

View on HN

I have a couple of Lisp Machines at home. They ran an object-oriented OS fully written in Lisp incl. window system, networking with TCP/IP, object-oriented database, text editor, graphics editor, 3d suite used by companies like Nintendo and Sony, mail server, file server, ...

That thing ran on a 5 MIPS (Millions instructions per second) 40 bit processor with 40 MB RAM in the end 80s / early 90s.

Suddenly with 1000 times more CPU speed, multi-core machines, fast GPUs, GBs of RAM, etc. it should not be possible to do that anymore?

Because suddenly Lisp is too slow? Why was it fast enough to run that stuff in the 80s on tiny machines?

Naughty Dog wrote Crash Bandicoot for the Playstation using a Common Lisp IDE and a specialized Scheme runtime for the Playstation. It sold millions of games and critics liked it for its fluid gameplay.

Suddenly with machines much faster than the first Playstation this should no longer be possible?

>Why was it fast enough to run that stuff in the 80s on tiny machines

Lisp Machines were invented precisely because Lisp was slow on common hardware, hence the 8 extra tag bits. Lisp Machines are specialized Lisp hardware.

Lisp Machines were invented as the first personal workstations, because the common hardware was timeshared PDPs. The researchers wanted powerful personal computers with interactive user interfaces - something which did not exist at that time.

Still that was not the question. The question was why 1000 times faster computers with much more space should not be able to run Lisp applications when in the 70s it was possible to run a whole OS on tiny machines.

I don't claim that "Lisp cannot run on modern hardware", just that it has performance sapping features that lower its competitiveness vs mainstream compiled languages. If you don't care about performance and don't pretend to be in the same league as C i have no problem with Lisp/Scheme. Its the same deal with people pretending languages with GC such as Java are fit for systems programming and low-level tasks.

Yet most enterprise servers are written for GCed infrastructure: .net and JVM.

Actually Lisp runtimes perform not worse than the JVM.

Java pretty much defeated the whole "the sky will fall if we deploy something with GC" nonsense. (Thank you, Java). What you're dealing with in this thread is twenty-year-old recycled FUD.

"Ruby proves its systems programming language as fast as C because i deployed an app on rented server i know nothing about"

I've taken a fair crack at it, but I'm unable to find an interpretation of your sentence such that it relates to my comment.

Your Apps (such as Java) are user-level programs. Its irrelevant if you can run Interpreted Brainfuck or Python on Crutches. Read this comment: https://news.ycombinator.com/item?id=14488427

These servers run C-based OSes where Java/.Net is just a server app.

I knew that.

But you ignore the whole stack the OS, Libraries, the Java runtime all are written in C/C++ only the end-user server app is written in Java code(that obviously means C/C++ is obsolete and Java is the systems language as fast as C/C++).

Why do you think I ignore that and what does this have to do with this discussion?

"Yet most enterprise servers are written for GCed infrastructure: .net and JVM." Link to comment: https://news.ycombinator.com/item?id=14487354

That's even worse, there are other layers below the GCed Java/.net infrastructure, which makes the whole thing even slower and less performant.

Reply on news.ycombinator.com