hayley-patton

There is some irony in juxtaposing a statement on floating point arithmetic before; I = I + 1 if I is a sufficiently large float.

Yes, the numeric language does numeric things. But these examples of closed form solutions ignore that numbers on computers are not the usual mathematical objects, rather having finite size and precision, and so it is hard to say immediately if these solutions using floating-point arithmetic provide the same precision. Of course the precision can be calculated and improved with analysis, still, but this falls under "it doesn't work but it's fast" territory (unless the limited precision is acceptable; I'd personally keep the result as a float then to expose that to the client of these functions).

I would be remiss not to mention the following story:

There is a story that Ken Iverson, the inventor of APL, was passing a terminal at which a Fortran programmer had just typed:

    I = I+1 

Ken paused for a moment, muttered “no it doesn’t”, and passed on.

> Maybe I'm just missing something obvious but it doesn't seem like you can start with an empty list that you can repeatedly append to

You can, but appending some list L and an empty list, or an empty list and L yields L in either case; there's nothing to append. Subsequent appends will be more interesting, e.g.

    CL-USER> (append '(x) (append '(y z) '()))
    (X Y Z)

> The empty list is nil, and `(append nil foo)` seems to just yield `foo`, not `(list foo)`

Right. Conceptually APPEND appends lists and not bare elements; try (append '() '(foo))

There are "hierarchical" schemes which attempt to clump graphs together. SBCL has a special case of trying to lay down lists sequentially.

Anything with a read barrier might also be able to see which slots are hotter, and thus prioritise copying those first; there was one paper from the 90s showing profiling helped get a better layout.

Thanks. How can the network tell that it is definitely communicating with a secure enclave, and not some kind of emulator? [1] suggests that keys and signatures from Intel are burnt into CPUs, which would work. All in all it's certainly an odd thing to put trust in.

[1] https://news.ycombinator.com/item?id=21840086

Doesn't seem like a wise thing to do.

Quoth one of the pages of the Secret Network <https://scrt.network/about/about-secret-network/>:

> Every validator on Secret Network runs their code inside a TEE so no one—not even the nodes operating on the network—can access the information being decrypted and processed.

How could one possibly verify that a secure enclave is being used?

Didn't putting so much rendering code in kernel-space also produce a lot of security bugs in NT? Would be nice to run trustable code in a trusted context if one wants to do so.

I did it, decided to compare results, and saw

> Best Score for your Gender -69420

> Worst Score for your Gender 1000000000

Someone doesn't sanitize their inputs?

There's a similar sentiment in the first SICP lecture <https://youtu.be/-J_xL4IGhJA?t=48>, when Harold Abelson brings up the examples of computers and computer science, physics and particle accelerators, biology and microscopes and Petri dishes, and geometry and surveying instruments. All those tools definitely help, and indeed one would struggle at this stage to research without them, but the tools aren't the goals of the sciences.

I'm not sure what Dijkstra would have thought the "goal" of computer science was, but in the lecture Abelson seemed to think it was about describing procedures and processes in a formal manner.

And, if one wants to be picky, Pauseless is a variation of Henry Baker's "real-time" copying collector from 1978 [2], although Pauseless uses tags corresponding to various interesting states (marked/unmarked, forwarded/unforwarded) rather than just from-space/to-space.

[2] https://plover.com/~mjd/misc/hbaker-archive/RealTimeGC.html

Pauseless [0]? It originally used hardware support on Azul machines to trap upon reading an unmarked pointer, but now (in the C4 generational incarnation, as well as in ZGC) this is done in software. But the other collectors use snapshot-at-the-beginning and a write barrier for concurrent marking, which originated in 1990 [1].

[0] https://www.usenix.net/legacy/events/vee05/full_papers/p46-c...

[1] https://core.ac.uk/download/pdf/39218501.pdf

Ditto. My parents thought MPT looked a bit like a spreadsheet, from memory.

I wouldn't expect caching vs. cache ping-ponging to be an easy and clear-cut decision in any language, and any external dependency is thus possibly an issue there.

Compared to the other pauses kernels make? Biscuit (POSIX in Go [0]) introduced at worst a pause of 115 microseconds and a slowdown due to GC and safety checks of 15%. But the forementioned systems don't have a kernel/userspace split; Microsoft measured the split made a server 25 to 33% _slower_ [1].

[0] https://pdos.csail.mit.edu/papers/biscuit:login19.pdf

[1] https://dl.acm.org/doi/10.1145/1178597.1178599

Something like "Address/memory management for a gigantic LISP environment or, GC considered harmful" <https://dl.acm.org/doi/10.1145/1317203.1317206>? I think that uses usual LRU mechanisms to determine what to page though.

But why?

> GC is the problem there.

It is? That didn't stop Genera, Interlisp, Movitz or Mezzano to name a few. Outside Lisp there's also Smalltalk, Oberon and Singularity to name a few operating systems with GC.

I don't know of any reference counting implementations which ever recursively increment counts though, so I don't see how it's an improvement on anything else.

I had left some comments on this duplicate <https://news.ycombinator.com/item?id=33453020>, and am admittedly not sure if I should duplicate the comments here, which seems to have more activity. But in summary - this article really conflates implementation and language; in particular, the "mysterious link between Lisp and OOP" is that you can write the evaluator in an object-oriented way, which you also can in a functional way, procedural way, relational way, and so on.

There is another page <https://github.com/naver/lispe/wiki/2.5--LispE-vs.-Python:-A...> on implementation details that I don't get either.

In particular, the hash table apparently cannot have collisions, as "variables are necessarily unique". Sure, but there are only 64 buckets for 65,536 names, so it is further necessary for all variable names to be unique modulo 64, which can't be guaranteed. One option (which I believe CPython uses, more or less, by numbering locals and arguments) is to use De Bruijn indexes [0], but I'm not sure how to make it work with a tree-walking interpreter.

I'm also not sure how it is possible to come up with a reference-counting algorithm that performs "recursive increments", as an assignment X := Y only ever adds one incoming reference to Y from X. The example suggests the reference counts are the number of ways each value is transitively reachable, which is unnecessary and no one does that; Collin's original paper on reference counting [1] describes it as "a tally of the number of arrows pointing to [an object]" which is not transitive.

[0] https://en.wikipedia.org/wiki/De_Bruijn_index

[1] https://dl.acm.org/doi/10.1145/367487.367501

This article really conflates language and implementation. My reading is that "this mysterious link between Lisp and OOP" is that you can put values manipulated by a Lisp system in an inheritance tree, and put an eval() method on each.

And with the exception of 3-Lisp's infinite tower of interpreters, "modifying eval in the implementation" is not how anyone extends the language, because modifying the implementation is very much the least portable thing possible to do. The usual suspects for that are macros and fexprs, but the author refers to generic arithmetic, which would best be managed by some kind of dispatch or polymorphism in the language.

The part of threading is also a head-scratcher. The author claims that you cannot run bytecoded VMs with multiple concurrent threads without a lock, only seeming to suggest it is because CPython doesn't do that. One counter-example would be BEAM. And concurrent reads to immutable data structures are entirely harmless, so copying between threads is unnecessary.

Newspeak?

https://newspeaklanguage.org/

Barriers are probably too small to cause latency spikes. The object logging barriers are a bit complicated, as they write an object into a thread-local log and infrequently have to get more memory for the log. But a card barrier is rather simple, and could look like

    SHR R_pointer, 9
    AND R_pointer, <cards>
    MOV BYTE [R_cards + R_pointer], 0

where <cards> is one below an immediate power of two number of cards, each card covering 2^9 = 512 bytes of heap. This is roughly the write barrier in SBCL on x86-64; there isn't much of a reason to think it will cause a latency spike.

On the other hand, "Barriers revisited" does mention a pathology about how cards can introduce false sharing, but that's still more of a smear than a spike.

To "lose" 5% I imagine one has to only be "worse" than some other heuristic that they measured the results of.

Right, I don't mean to downplay the significance of 1%, but aren't there many ways to win or lose 1%? More specifically perhaps, are there so few GCed pointers that a faster collector cannot recuperate that 1%?

moonchild's suggestion to monomorphise against GC/explicitly managed pointers might reduce that figure lower; evidently you know D programs better than I, but it doesn't seem unreasonable that the 1% can be won by a faster GC.

I would expect to be able to find another 1% slowdown somewhere in an implementation of another "system programming language" - would that also disqualify it from being such a language?

It's also worth mentioning that being conservative only on the stack, even when moving, is often good enough. SBCL still works that way, and the space and time overheads are pretty tiny [0].

[0] Fast conservative garbage collection https://users.cecs.anu.edu.au/~steveb/pubs/papers/consrc-oop...

The Go collector isn't generational or moving, and the write barrier AIUI is only used for getting it to run concurrently. The barrier records interesting writes when the collector is running, to avoid "losing" objects whose liveness changed while the collector was running.

Barriers are pretty cheap; [0] claims a 0.9% time overhead for a card-marking barrier common in generational collection and 1.6% for an object-logging barrier which is also useful for concurrent collection. Apparently they're cheaper nowadays, but the results aren't published yet [1]. That's not to say that the barriers are free, but it seems feasible that collector optimisations could still cover that ground.

It can help throughput, still, by running the collector concurrently. I've felt that while working on a new parallel (but not yet concurrent) collector for SBCL; the program parallelises well, but a serial collector hurts worse than it should by stopping the program.

[0] "Barriers reconsidered, friendlier still!" https://users.cecs.anu.edu.au/~steveb/pubs/papers/barrier-is... [1] https://twitter.com/stevemblackburn/status/14942409060061102...

Well, Bjarne did make C++.