/tech/ - Technology

Technology & Computing


New Reply[×]
Name
Sage
Subject
Message
Files Max 5 files32MB total
Tegaki
Password
Captcha*Select the solid/filled icons
[New Reply]


d90241b934a3105d264192295d667e9f.jpg
[Hide] (109.4KB, 703x1000)
It was well known that C was obsolete in the 90's. It could have been replaced with region inference a la ML Kit, Cyclone, etc. By 2000 computers were fast enough such that 90% of applications could just be written in a memory-safe garbage collected language[1]. Now what about that other 10%? Glad you asked.

What we need now (2010) is a return garbage collected languages with hardware support. Manual memory management is a complete waste of time and is a large source of program defects. Analog computing can be used to implement O(1), deterministic, garbage collection, suitable for even hard real time applications. Imagine a pipe from your water heater to a hot water tap on your kitchen sink. Here's a quick experiment: Have someone go to the water heater in your basement and listen while you turn on the hot water tap. Did you notice it *instantly* turns on?

Now here's one way O(1), deterministic GC can be implemented in hardware. There are millions of tiny water pipes. Each time you have an allocation, a water pipe goes from it to the code using it. If a structure has the pointer to the allocation, a water pipe goes from it to the allocation. When someone (code or a struct) is done using an allocation, it closes its end of the pipe.

All water in the system is in constant flow. When all ends of an allocation's pipe are closed, water overflows from that pipe, and it knows it's time to free it.

Q.E.D.

The CPU will have to be cubic shape to fit this system. Water doesn't have to be used, of course. There are plenty of other industrial chemicals to choose from.

This of course raises several questions, but the system is in development and I'm technically breaking NDA by posting this, but I need you all to be ready for it when it comes. This is the future.

[1]. for people who are new to programming, this may be confusing; lots of simple software that does nothing but display text on the screen is slow; this is due to lack of programmer skill, not the "slowness" of GC
Replies: >>17544 >>17556
Even with hw accelleration it wouldn't become twice as fast.
You can already mix gc and manual allocations in D.
Does that answer the questions you had about this greentext?
Replies: >>17541
Is this some retarded pasta?
>>17537
D like Rust doesn't fix the issue it only mitigates it. What greentext?
Replies: >>17542 >>17547
>>17541
What issue? Standard D uses the GC for most things and the GC runs oniy short cycles and only on allocation. Thus it's relatively predictable for a gc.
Replies: >>17547
>>17530 (OP) 
So LISP good?
Replies: >>17545
>>17544
No.
Replies: >>17552
Ramiel_best_gril.jpg
[Hide] (10.7KB, 261x253)
Even if the debounce latency problem of analog/multilevel logic could be fixed, that would still eat up precious gatecount budget where you could put moar paralLOLIsm
>It was well known that C was obsolete in the 90's
Classic scholarly shitpost on the subject:
<C Is Not a Low-level Language:
<Your computer is not a fast PDP-11.
https://spawn-queue.acm.org/doi/10.1145/3212477.3212479
>garbage collected languages with hardware support
I can't find it at the moment, but I remember when Lisp machines like Symbolics Ivory benchmarked HW accelerated LISP against software compiled from C, LISP was still absolutely creamed running on the same chip.

>>17541
>>17542
Stronger typing such as Rust (or, indeed, OP's aforementioned ML & Cyclone) uses, versus optional GC such as D uses, are two different solutions to two somewhat different problems.

The former imposes zero runtime overhead but can not (yet) be applied everywhere, the latter imposes runtime overhead but can be applied anywhere.

Even so, D without GC has stronger typing than C, but weaker typing than Rust. Likewise, early versions of Rust (much like early versions of Ada) included an optional GC, but due to unpopularity the feature was axed, and of course any language capable of manual allocation (such as C) can be used to bolt on any sort of automatic allocation with some potentially confusing nonstandard annotation added to code it manages.

Also, there is the brute force approach of just using two different languages.

>17544 
There are two wolves inside you. One is LISP, the other is FORTH.
Replies: >>17561
akari_sad.jpg
[Hide] (178.7KB, 1083x720)
>>17545
>>17530 (OP) 
Don't care, I still like C
>>17547
> HW accelerated LISP
That doesn't sound like a real LISP machine? More like a conventional CPU with some LISP ASIC or some shit.
Replies: >>17566
>>17561
Aside from the Ivory by Symbolics I mentioned, were multiple generations of full-custom silicon CPUs built specifically for special LISP dialects, it was a bit of a fad in that era before the first "AI winter". Unique design traits varied from more general (stack rather than register machine) to more specific (on die GC offload), but the entire architecture was built around the language.

Note the same thing has been done at times for other languages, including, for reasons noted in the ACM paper I linked above, C itself! For instance:
https://en.wikipedia.org/wiki/AT&T_Hobbit
Replies: >>17569
>>17566
I mean if the CPU is running Lisp opcodes instead of more conventional CPU ones, then it means that Lisp is the assembly language on that platform. If it's not doing that, then it's not a real Lisp machine, just some hybrid shit. But if it is purely Lisp opcodes, then wtf is the point of using C at all, when you can already just write asm (Lisp) directly.
Replies: >>17570 >>17578
>>17569
Both are high level languages and there are no C cpu instructions.
Replies: >>17580
>>17569
Because many LISP features, for instance GC, are inherently inefficient. Think of how Emscripten transpiling C/C++ to JS results in code that runs way faster than idiomatic JS, specifically because it avoids using features such as GC as much as possible.
Replies: >>17579
>>17578
Most LISP languages are scripting languages with dynamic typing. I think that has a larger impact than GC.
Replies: >>17582
>>17570
Implement Lisp in CPU microcode?
>>17579
True, even more so for some languages such as Python.
[New Reply]
17 replies | 3 files
Connecting...
Show Post Actions

Actions:

Captcha:

Select the solid/filled icons
- news - rules - faq -
jschan 1.7.3