If Deno just took payments or at least donations, it would have thousands, or even tens of thousands of paying customers. Instead, they preferred to submit to VC and chase beehives on Deno Deploy territory.
Deno Deploy offering would have never be profitable because it contradicted the very core of the Deno's technology promise: absence of lock-in and freedom to self-host.
I don't quite trust this class of devices to be programmed in China by who knows who. KVMs are among those things that need authentic, business-registered suppliers that hold a trackable reputational responsibility.
I totally agree with you, but where are those trustworthy companies? It seems every household names in the consumer electronics space are hell-bent on abusing their customers in every conceivable way. Just look at the LG scandal, and that is standard practice across the entire industry. It has to start with strong consumer protection laws and strong enforcement of those laws.
100x speed improvement of math operations by 8087 is not an overestimation. The difference for apps relying on math was crazy back then. I experienced this first-hand on my 80286 machine, where it was 3-second vs 300-second calculation results.
One neat feature of 8087 instruction set is that it can be interspersed with x86 instructions in the code stream, giving you a simultaneous access to two processor chips working in parallel. This combo forms a real asymmetrical multi-processor system with certain opportunities for hardware-assisted code parallelization. If a thoughtful instruction scheduling is used, floating operations executed by 8087 work in parallel with the usual integer x86 code.
Vs. Ken's Blog says "up to 100 times", and Wikipedia gives a lower estimate.
Theory: Your 100X experience compared Intel's "exact emulation" code (noted in the article) with native x87. That emulation would have to cover the myriad x87 oddities and corner cases which Ken describes. Vs. Ken's & Wikipedia's are comparing x87 to various "good enough" 8088 floating point libraries - so naturally much faster than Intel's exact code.
(And yes, speed might have been a low priority for the team writing Intel's emulator.)
Any modern processor has different execution ports specialized in different things and replicated a different number of times, and all of them can execute instructions in parallel.
It schedules to these transparently for you, that's known as superscalar execution. To maximize occupation, out-of-order execution and simultaneous multithreading are used.
80186 is often forgotten to have existed because it didn't see much success in the market / because IBM skipped it and went with 80286 for the AT, but it did exist.
The 80186 didn’t really introduce anything new architecturally. It’s basically an 8086 with a few more chips bundled on-die. 80286 however introduced protected mode, expanded the address size to 24 bit, hardware enforce memory protection, multitasking, etc.
80186 Was not IBM PC compatible. It had e.g. a PIC, DMA and timer built-in, and these were incompatible with the chips in a 8086 based IBM PC.
There were a few new instructions, too, mostly closing holes. You could left or right shift with a constant, while the 8086 had only 1 or the CX register. I think mul also gained a constant.
The fact that Intel released a CPU that could not be put in a PC probably indicates how low they estimated the survivability of the PC.
Transparent scheduling of superscalar execution was a later advance in microprocessors, termed out of order execution. Apart from micros both did come out around the same time in the mid-1960s.
In the x86 microarchitectures superscalar came in Pentium and OoO got introduced in Pentium Pro.
(Superscalar is just having >1 pipelines, which at its introduction meant needing to manually schedule your code very carefully to take advantage of it absent the OoO execution. For example the frequently posted-about Doom optimizations and talk of the u and v pipes are about this. The scheduling didn't happen transparently in early superscalars, at best the cpu automatically stalled, and some archs (eg MIPS, i860, TI C3x) even visibly punted hardware detection of pipeline hazards and required the code to just not go there, see load delay slots and branch delay slots.
)
I'd argue most people would consider it scheduling only if there's some attempt to arrange order of execution to improve throughput. Idling the other execution units when they could be executing instructions is not scheduling, at least not good scheduling.
In estabilished computer architecture terminology, scheduling is decidedly a OoO execution term. (At least if you're talking about processors. There's also static scheduling, which means the compiler does it and the hardware doesn't.)
I remember getting a 80387 (coprocessor for the 80386) and POVRAY renders going from running for days to still many minutes but you could sit and watch it.
Ego is insulted, they're raging but it changes nothing. Math is beautiful exactly because it discerns right from wrong with 100% accuracy, while all the emotions and "flexible interpretations" are redirected to /dev/null.
Not sure whose ego is being insulted here. If you spend two seconds reading the letter you’d realize it’s talking about human understanding has been crucial to advancing of mathematics, and AI companies are not bothering with it. If they succeed, human understanding becomes irrelevant. The beauty of math that you claim comes from the process of humans understanding it.
Maybe you should try to redirect your emotions and misdirected feelings of schadenfraude to /dev/null and try to read what it is about
Where this approach might shine right now is .o/.obj files for assemblers/compilers/linkers. Instead of using COFF/ELF/whatever binary voodoo, a relational DB container makes most of the previously hard things trivial, including optional vendor extensions.
This would be a super pragmatic approach for a modern compiler suite. This is the brilliant part of the whole idea.
Don't pay too much attention to the inner-circle feedback. Some people subconsciously use the tone of reception to control you, especially peers/colleagues are prone to this. They see someone having a bright idea, and they genuinely don't like it just because it makes them feel small in comparison. The thing they do next - they try to extinguish the spark by creating an illusion of worthlessness in your mind. By doing so, they are getting rid of a potential competitor on their own way to success. According to psychology, they start feeling normal again by reducing you, this is a natural compensatory mechanism ingrained in human archetypes.
The key thing here is to be able to discern between real and manipulated input information. For this, gut feeling usually works best: it spots that whiny, attention-insisting, importance-seeking, fear-inducing tone of a manipulator, but oftentimes the higher-level nervous system of the brain suppresses that signal (e.g. "How can a well-educated and charismatic person feel a bit off and responsibility-lacking sometimes? It cannot be right, so it must be something with my interpretation of reality. I bet they have the best intentions.")
An even better approach may be not to search for feedback at all, unless it's shared naturally without any strings attached.
The copied vs. mapped memory situation is the only deal breaker in this experiment. Otherwise, file format unification would be a big step forward. The PE/COFF executable file format used by Windows (and some older Unix systems) is a relational database as well. The same goes to .NET assembly format - it's a relational database too. The wheel gets reinvented over and over again.
I was thinking that one could just write a loader that goes from SELF->ELF on load. You then pay the cost on startup. Probably not worth it for one-shot programs like ls/cat/etc, but for long running programs and daemons it might be workable.
Of course there are many options, but the benefit of the SQLite approach is the existing tooling, support, etc. Like others have said, one could just write a SQL interface over a set of virtual tables derived from the actual elf (if one just wanted a CRUD-like interface to a binary).
All of the benefits of SQLite disappear once one diverges from the format in any way. At which point it would be better to ask: "what is the best first-principles implementation of this idea?", instead of "what is the minimal change to SQLite to achieve this specific narrow goal?"
I didn't understand the core issue, is it that due to non-alignment of the on-disk data you have to do a copy at load time, but if you could guarantee alignment of the actual blob content then you could use it directly?
On a brief background read it looks like another issue is that blobs are not necessarily stored in contiguous regions of the file. Maybe there's some clever way to combine a VFS shim and virtual tables to store page aligned blobs in a region of the same file as the main database.
In real life, an imaginary "leadership" quickly evaporates upon the first hurdle of any kind until proven otherwise by real actions. If I was in your shoes, I would be very careful with blanket statements like these.
This would be the "proven otherwise by real actions" part. They've been around since 2017 and have had plenty of time to hit various hurdles. Past performance is no guarantee of future performance and it is within the realm of possibility for them to go of change course like Elon did. But who are you? Are your Internet comments some proenoucement of truth that can never ever be taken back? So you said something that, years later, turns out to be wrong. So what?
Deno Deploy offering would have never be profitable because it contradicted the very core of the Deno's technology promise: absence of lock-in and freedom to self-host.
reply