HackerTrans
TopNewTrendsCommentsPastAskShowJobs

inkyoto

no profile record

comments

inkyoto
·11 วันที่ผ่านมา·discuss
Sun was one of the few RISC design houses who stubbornly resisted NUMA in favour of SMP, which they have perfected in the hardware and in the software (Solaris). The «Solaris internals» book discusses the subject of SMP vs NUMA vs ccNUMA in the «Parallel systems architectures» section (3.2).

You might be thinking SGI who went in big on NUMA. IBM and HP have also built ccNUMA systems (e.g. HP Superdome and Superdome 2).
inkyoto
·15 วันที่ผ่านมา·discuss
Well. The Latin version of Roman is Romanus, which is believed to have descended from Romulus, one of the two legendary founders of Rome.

The popularity of Roman in Eastern and Western Slavic cultures is likely due to the cultural influence of the Byzantine Empire. Roman is also a rather popular name in Spanish speaking Latin American countries (Román) and is not entirely unknown in Germany (same spelling).
inkyoto
·19 วันที่ผ่านมา·discuss
It is exactly the other way round: JSON-LD has largely displaced and superseded RDF/XML in many web applications.
inkyoto
·21 วันที่ผ่านมา·discuss
kowtow (叩頭) is a Cantonese word borrowed into English in the early 19th century.
inkyoto
·28 วันที่ผ่านมา·discuss
I see Swift as a more approachable version of Rust.

If somebody is mulling over Rust but finds it too difficult to grasp, they could start off with Swift first and then move over to Rust.

One of the main advantages of Rust is a more developed and thriving ecosystem.
inkyoto
·28 วันที่ผ่านมา·discuss
Not just interoperability with Objective C but with C (full) and C++ (increasingly better but not full) as well.

Swift is also interoperable with different versions of itself courtesy of the Swift stable ABI (Application Binary Interface)[0], which they invested a significant amount of time into at the expense of adding other new features to the language, which have come along later.

Rust offers a different approach: recompile everything and static linking.

[0] https://faultlore.com/blah/swift-abi/
inkyoto
·เดือนที่แล้ว·discuss
> I got my first bifocals last year. I got the "no line" variety and, so far, I hate them.

They are called progressives (or multi-focal – depending on whom you speak with).

Progressives come in a few «ranges»: near-range, mid-range and all-purpose. There are also «premium» options available, although I am not entirely sure how much different they actually are.

I have found that having two separate pairs of progressives (near-range for reading, laptop use and all-purpose for everything else) works the best. All of them can also be had as the transition variety and with different tint colours, thus obviating the need for a separate pair of shades.

In fact, when I first tried the near-range progressives some 5 years ago, it was an eye-opener in the almost literal sense of the word – the laptop screen flattened and became bigger despite obviously not changing its physical size. It was something that I had struggled with for a long time before the progressives entered mainstream. At high prescription numbers, the lenses for myopia start distorting the true shape of objects which creates mild to substantial visual discomfort, and near-range progressives fix that.

Another source of discomfort might be the suboptimal «Add» number on the script for progressives. This can be fixed by going to an optometrist clinic rather that a street optometrist (or find a reputable and good one first). If the «Add» is too small, the progressives will make little difference compared to conventional lenses, and, if it is too big, they will make it difficult to see in the distance.

Based on own subjective experience, I can't recommend the progressives enough, although a little bit of fine-tuning might be required (none in my case).
inkyoto
·2 เดือนที่ผ่านมา·discuss
The vast majority of virtual machines, including JVM and .NET, are stack based.

And, whilst compiling C and C++ the JVM / .NET CLR byte codes is very uncommon, both VM's have become very popular compilation targets for other programming languages.
inkyoto
·2 เดือนที่ผ่านมา·discuss
Rotating register windows are a distinguishing feature of the Berkeley RISC design, which predates VLIW by at least a decade.
inkyoto
·3 เดือนที่ผ่านมา·discuss
> "PLEASE COME FROM" is one of the eldritch horrors of software development.

The most enigmatic control flow statements in INTERCAL, however, remain PLEASE GIVE UP and DO ABSTAIN FROM – a most exalted celebration of pure logic and immaculate reason.
inkyoto
·3 เดือนที่ผ่านมา·discuss
Once again – respectfully – this remains largely twaddle as the facts themselves state otherwise.

Even at the microarchitecture level, the hard part is not raw CISC-ness but irregularity and compatibility baggage. In that respect x86 was usually the uglier customer.

High-end x86 implementations ultimately scaled further because Motorola had less market pressure and fewer resources than Intel to keep throwing silicon at the problem, not because m68k was somehow harder to optimise.

Later high-performance m68k cores did what later x86 cores also did: translate the architected variable-length instruction stream into a more regular internal form. Motorola’s own MC68060 manual says the variable-length M68000 instruction stream is internally decoded into a fixed-length representation and then dispatched to dual pipelined RISC execution engines. That is not evidence of an ISA that was uniquely resistant to microarchitectural optimisation. It is evidence that Motorola used the same broad trick that became standard elsewhere: hide ISA ugliness behind a cleaner internal machine.

There is also a deeper point. The m68k ISA was rich, but it was comparatively regular and systematic at the architectural level. The m68k manuals show a clean register model and – notably – consistent condition-code behaviour across instruction forms. That kind of regularity is exactly what tends to help both compiler backends and hardware decode/control design. By contrast, x86’s biggest hardware pain historically came not from being «less CISC» than m68k, but from being more irregular and more burdened by backward compatibility.

Lastly, but not least importantly, CPU's were not the core business of Motorola – it was a large communications-and-semiconductors company, with the CPU's being just one product family within a much larger semiconductor business.

There was no clear understanding within the company of the rising importance of CPU's (and computing in general), hence the chronic underinvestment in the CPU product line – m68k did not see the light of highly advanced, performant designs purely because of that.
inkyoto
·3 เดือนที่ผ่านมา·discuss
Respectfully, this is nonsense.

«More CISC-y» does not by itself mean «harder to optimise for». For compilers, what matters far more is how regular the ISA is: how uniform the register file is, how consistent the condition codes are, how predictable the addressing modes are, and how many nasty special cases the backend has to tiptoe around.

The m68k family was certainly CISC, but it was also notably regular and fairly orthogonal (the legacy of the PDP-11 ISA, which was a major influence on m68k). Motorola’s own programming model gives one 16 programmer-visible 32-bit registers, with data and address registers used systematically, and consistent condition-code behaviour across instructions.

Contrast that with old x86, which was full of irregularities and quirks that compilers hate: segmented addressing, fewer truly general registers (5 general purpose registers), multiple implicit operands, and addressing rules tied to specific registers and modes. Even modern GCC documentation still has to mention x86 cases where a specific register role reduces register-allocation freedom, which is exactly the sort of target quirk that makes optimisation more awkward.

So…

  68k: complex, but tidy

  x86: complex, and grubby
What worked for x86, though, was the sheer size of the x86 market, which resulted in better compiler support, more tuning effort, and vastly more commercial optimisation work than m68k. But that is not the same claim as «68k was harder to optimise because it was more CISC-y».
inkyoto
·4 เดือนที่ผ่านมา·discuss
> Since when were payment networks latency sensitive?

Since the advent of e-commerce, POS-networking and fraud detection systems in 1990's-2000's.

User-facing and authorisation path are highly latency sensitive. It includes tap-to-pay, online checkout, issuer authorisation, fraud decisioning, and instant payment confirmation – even moreso for EFT payments.

> […] 2-5 seconds more from card presentation to getting approval back.

This is the mid-1990's level QoS when smaller merchants connected the acquirer bank via a modem connection, and larger ones via ISDN.

Today, payments are nearly instant in most cases, with longer than one-second card payment flows falling into the exceptions territory or inadequate condition of the payment infrastructure.
inkyoto
·4 เดือนที่ผ่านมา·discuss
As well as to eggplant and belladonna.
inkyoto
·4 เดือนที่ผ่านมา·discuss
PDP-11 was a major source of inspiration for m68k architecture designers. The influence can be seen in multiple places, starting from the orthogonal ISA design down to instruction mnemonics.

It is quite likely that not allowing the misaligned access was also influenced by PDP-11.
inkyoto
·4 เดือนที่ผ่านมา·discuss
PDP-11, m68k – to name a few, did not allow misaligned access to anything that was not a byte.

Neither are RISC nor modern.
inkyoto
·4 เดือนที่ผ่านมา·discuss
If I'm not mistaken, microcode is a thing at least on Intel CPU's, and that is how they patched Spectre, Meltdown and other vulnerabilities – Intel released a microcode update that BIOS applies at the cold start and hot patches the CPU.

Maybe other CPU's have it as well, though I do not have enough information on that.
inkyoto
·4 เดือนที่ผ่านมา·discuss
> In Linux the default swap behaviour is to also swap out the memory mapped to the executable file, not just memory allocated by the process […] I believe both Windows and macOS don't swap out code pages, so the applications remain responsive, at the of (potentially) lower swap efficiency

Linux does not page out code pages into the swap. You might be conflating page reclamation with swapping instead.

In Linux, executable «.text» pages are mapped[0] as file-backed pages, not anonymous memory, so when the kernel needs to reclaim RAM it normally drops those pages and reloads them from the executable file on the next page fault once they are accessed again (i.e. on demand) rather than writing them to swap.

In this particular regard, Linux is no different from any other modern UNIX[1] kernel (*BSD, Solaris, AIX and may others).

[0] Via mmap(2) in argv[0], essentially.

[1] Modern UNIX is mid-1990's and onwards.
inkyoto
·4 เดือนที่ผ่านมา·discuss
> In 1970 it might have been the only way to provide a flexible API, but nowadays we have a great variety of extensible serialization formats better than "struct".

Actually, fork(2) was very inefficient in the 1970's and for another decade, but that changed with BSD 4.3 which shipped an entirely new VMM in 1990 in 4.3-Reno BSD, which – subsequently – allowed a CoW fork(2) to come into existence in 4.4 BSD in 1993.

Two changes sped fork (2) up dramatically, but before then it entailed copying not just process' structs but also the entire memory space upon a fork.
inkyoto
·4 เดือนที่ผ่านมา·discuss
What are we comparing Ada to… PHP?