rcgorton

Re: register windows. I disagree: code size wasn't the killer here, it was how DEEP the stack got. If your architectural register window spilled at 4 deep, then calls 3 deep were fine, but if you had a set of code attempting to iterate over a tight loop which had 8 calls deep, you were in [performance] trouble.

Another divot: asymmetric functional units. Some versions of Alpha supported a PopCount instruction, but it only worked in a single functional unit, which made scheduling a pain, esp. if you had to write in assembly language.

I'm not convinced that AVX 256 and AVX 512 are useful for non-matrix operations. Most strings (more importantly, parsing bounded by whitespace) are much shorter than 512 bits (32 bytes). In English, I cannot come up with many words longer than 16 bytes (some place names, antidisestablishmentarianism, chemical compound names, and some other stuff)

No. Professional farmers had enclosed cabs even around 1975.

Proposal: emacs is now irrelevant. Stabilize it, freeze and kill "future development". Oh, sorry, emacs 'development' is solely about emacs, rather than being about productivity. Too bad that emacs is more about DECs TECO than reality.

It is also incredibly useful for doing string scanning - look at strlen/strchr in various libc imp lementations

First hit on google: SBLC == Stand By Letter of Credit. Clearly, Common LISP is not important/relevant according to google. It seems like "Common Lisp" implementations may be stuck in the mid 1980s and the implementors do not have any idea about how to use shared libraries. So sad

"tired and Cosmopolitan wired" This poster needs to be banned. Only relevant if you want an interpreter which runs an secondary interpreter, encapsulated in a .zip file.

If you live the twitter life, you ARE A TWIT

strcpy, strlen, strchr, memcpy, and their varients

many MANY reasons VPs who insist on micro-managing technical decisions even though they really do ignore technical recommendations of highly skilled engineers. (Tom Hamilton, formerly of Digital Guardian)<br> VPs who refuse to share technical aspects of the business plans/goals (for a small company) with engineering because "well I can't share that with you" Steve Weingart when @ Liant<br> Anything involving/supervised by Ben Bar-Haim formerly AMD. Ben successfully constructed an incredibly monolithic bureaucracy in AMD - with a huge amount of overhead. Software groups not based in Markham Ontario got Trashed. <br> So yes, lots of Manager/VP reasons to hate programming

NO, NO, NO. Scala is NOT a 'great' language. It is implemented in Java, so suffers ALL of the performance issues of Java (and then some). I would be THRILLED to see a new, straightforward language (vs. C++) which is strongly typed. From my personal perspective, GOLang is the best improvement so far, but suffers from a worse case of 'rpm hell' equivalant than general linux rpm packages do. Secondly, "Functional Programming" is best described as "DisFunctional Programming". The primary precept of functional programming is that there are ZERO side effects. Well, welcome to the real world of hardware/network failures. Please stop pitching garbage ideas to the rest of us realists.

Thank you - I will listen to the album

Interesting thought. I was just listening to some Wendy Carlos. Not sure that the rest of the audience actually understands the reference.

Feel free to downvote it. I expressed my honest, unbiased opinion. Until the OP, I had never heard of SOPHIE, so attempted to listen with an unbiased mindset.

I watched most of the video attached to the article. It feels to me like a rehash of Tangerine Dream and Kitaro.

I found some of the 'sizing' snippets in the example came across as disingenuous: if you KNOW the size of the file, mmap it initially using that without the looping overhead. And you presumably know how much memory you have on a given system. The description (at least as how I read the article) implies bolt is a truly naive implementation of a key/value DB

I'm concerned about these 'benchmarks'. They are using nanosecond timing intervals. By design, CPU clocks have jitter to resist timing attacks. Secondly, a single clock tick is much more than a nanosecond. I would feel much more comfortable with performance comparisons (in ANY language) when the duration is on the order of minutes.

For an overview of static translators: https://www.hpl.hp.com/hpjournal/dtj/vol4num4/toc.htm, article 9 ('Binary Translation')

Out of curiosity, what is the use case? RISC-V is new enough that it is unlikely to be needed for 'dusty-deck' (source code long lost) that was needed for the VAX --> Alpha binary translators, or for Univac (ones complement!) to X86_64. Why require a JIT? For static binary translators (based upon experience) the biggest difficulty is a combination of variable-length instruction decode and/or self-modifying code (requires an interpreter) and/or re-entrant-into-the-middle-of-an-instruction (easiest to handle with an interpreter).

Most recent job was 60+/week. Probably closer to 80. A stealth startup. And yes, I did get burned out: total COVID isolation + hours + steep learning curve. (got let go)

It seems to require a vacuum to spin. And then it needs to launch at Hypersonic speeds and then meets atmosphere. Instant encounter with a solid barrier == blow-up. I am thoroughly skeptical about the technology both on the incredible G forces, and then hitting atmosphere at huge rates of speed.

It is now Alexia Massalin

I'm not sure I understand why power is a limiter. Free solar power and heat during the lunar cycle...

Well, Mr. Creosote is annoying

The 'only' reasons (plural) that your laptop does not run Itanium: - battery life: an Itanium in a laptop would run for less than an your - too hot: Itanium servers ran incredibly hot due to power. A laptop would probably catch fire in short order - Windows was not supported on Itanium - cost: would you pay $5K for an Itanium laptop?

The author incorrectly assumes: - completely rectangular - all columns/rows have the same 'length'

Go try a pre-1950s 'pasttime puzzle' (wood). Most are rectangular, but certainly not some absurd same-length rows and columns.

This seems to be a legitimate business move on the part of Microsoft. What is not legitimate is The-Donald/Twitler objecting simply because one of his rallies was oversubscribed by US Tik-Tok members. He is being a petulant toddler (ass-hat) and wants revenge.

Did you consider NOT using NVidia? Both the capital cost and operational costs are huge compared to fairly high end Radeon cards (NO, I"m not an AMD employee - I merely choose based upon my personal budget)

In the early days, there was no such thing as an editor. Punch cards were used for every separate line of code. And along came editors. I had no familiarity with mainframe editors, but DEC systems had EDT/TPU (and another macro scripting thing I forget the name of). Enter 1980s with UNIX. This gave us ed/ex/vi/emacs. I entered the workforce in 1985, and had to edit files on a 1MB memory 68010 system. Emacs was such a memory hog that it would not run on said UNIX system. Fast-forward 15ish years: I have watched seasoned developers spend 2x-3x the time to perform simple editing actions in emacs than it takes to do in vi. Personally, I now have muscle memory for vi/vim, but if I need to edit a binary file, emacs or a hexeditor is the only way to go. IDEs add another level of context & capabilities to editors, as they typically understand the syntax of the language in question and often offer hints.

I have multiple disagreements: "ARM is becoming the dominant architecture". No - while a valid statement in 2012-ish, the truth (since about 2016) is "ARM is the dominant architecture". If disassembling binaries without symbols is a problem, then your skills/methods need improvement. Been there, dealt with that: binary translation of VAX/VMS, Mips/Ultrix, Sparc/Solaris to Alpha (various OS's)

A one pass compiler is going to generate code which is slower than a modern JIT/interpreter. Why is a one pass compiler interesting?