For my thesis I trained a classifier on text from internal messaging systems and forums from a large consultancy company.
Most universities have had their own corpora to work with, for example: the Brown Corpus, the British National Corpus, and the Penn Treebank.
Similar corpora exist for images and video, usually created in association with national broadcasting services. News video is particularly interesting because they usually contain closed captions, which allows for multi-modal training.
We used Redis in a project where we also manage hosting on a semi-public cloud infrastructure and I had troubled figuring out if license change applied to our situation. We didn't want to pay a lawyer to figure this out, so we switched to Valkey.
You could argue that running through the woods doesn't teach you about trees, but it's really effective when you bring a book along.
Linux From Scratch is a fun way to explore what parts make up a Linux distribution. I did this a few time long ago before switching to Gentoo and it really helped with appreciating the freedom to pick and choose details of your operating system without actually writing it from scratch.
I support the goals of the article and I understand that social interaction doesn't come natural to all people, but if someone would lean in an nod to me like described in the second part I would freak out because that feels like sociopathic behavior.
> At least in the context of x86 emulation, among all 3 architectures we support, RISC-V is the least expressive one.
RISC was explained to me as a reduced instruction set computer in computer science history classes, but I see a lot of articles and proposed new RISC-V profiles about "we just need a few more instructions to get feature parity".
I understand that RISC-V is just a convenient alternative to other platforms for most people, but does this also mean the RISC dream is dead?
As I've heard it explained, RISC in practise is less about "an absolutely minimalist instruction set" and more about "don't add any assembly programmer conveniences or other such cleverness, rely on compilers instead of frontend silicon when possible".
Although as I recall from reading the RISC-V spec, RISC-V was rather particular about not adding "combo" instructions when common instruction sequences can be fused by the frontend.
My (far from expert) impression of RISC-V's shortcomings versus x86/ARM is more that the specs were written starting with the very basic embedded-chip stuff, and then over time more application-cpu extensions were added. (The base RV32I spec doesn't even include integer multiplication.) Unfortunately they took a long time to get around to finishing the bikeshedding on bit-twiddling and simd/vector extensions, which resulted in the current functionality gaps we're talking about.
So I don't think those gaps are due to RISC fundamentalism; there's no such thing.
But that's not even close to true, either, eg any division or memory operation.
In practice there's no such thing as "RISC" or "CISC" anymore really, they've all pretty much converged. At best you can say "RISC" now just means that there aren't any mixed load + alu instructions, but those aren't really used in x86 much, either
You've hit the nail on the head. Really, when people complain about CISC vs RISC, they are mostly complaining about two particular things. The first is that x86 processors carry legacy baggage (aka they have had a long history of success that continues to this day) and the second is that x86 has a lot of variable length instructions. After that, most of the complaints are very nit-picky, such as the number of general purpose registers and how they are named.
It shifts implementation complexity from hardware onto software. It's not an inherent advantage, but an extra compiler pass is generally cheaper than increased silicon die area, for example.
On a slight tangent, from a security perspective, if your silicon is "too clever" in a way that introduces security bugs, you're screwed. On the other hand, software can be patched.
I honestly find the lack of compiler/interpreter complexity disheartening.
It often feels like as a community we don't have an interest in making better tools than those we started with.
Communicating with the compiler, and generating code with code, and getting information back from the compiler should all be standard things. In general they shouldn't be used, but if we also had better general access to profiling across our services, we could then have specialists within our teams break out the special tools and improve critical sections.
I understand that many of us work on projects with already absurd build times, but I feel that is a side effect of refusal to improve ci/cd/build tools in a similar way.
If you have ever worked on a modern TypeScript framework app, you'll understand what I mean. You can create decorators and macros talking to the TypeScript compiler and asking it to generate some extra JS or modify what it generates. And the whole framework sits there running partial re-builds and refreshing your browser for you.
It makes things like golang feel like they were made in the 80s.
Freaking golang... I get it, macros and decorators and generics are over-used. But I am making a library to standardize something across all 2,100 developers within my company... I need some meta-programming tools please.
I usually talk a lot about Oberon, or Limbo, however their designs were constrained by hardware costs of the 1990's, and how much more the alternatives asked for in resources.
We are three decades away from those days, with more than enough hardware to run those systems, only available in universities or companies with very deep pockets.
Yet, the Go culture hasn't updated themselves, or very reluctantly, with the usual mistakes that were already to be seen when 1.0 came out.
And since they hit gold with CNCF projects, pretty much unavoidable for some work.
it is in the sense that those are programmer conveniences only for assembly programmers and Riscv's view is that to the extent possible the assembly programmer interface should largely be handled by psuedo-instructions that disappear when your go to machine code rather than making the chip deal with them
That's not exactly it; quite a few RISC-style instructions require multiple (sometimes many) clock cycles to complete, such as mul/div, floating point math, and branching instructions can often take more than one clock cycle as well, and then once you throw in pipelining, caches, MMUs, atomics... "one clock cycle" doesn't really mean a lot. Especially since more advanced CPUs will ideally retire multiple instructions per clock.
Sure, addition and moving bits between registers takes one clock cycle, but those kinds of instructions take one clock cycle on CISC as well. And very tiny RISC microcontrollers can take more than one cycle for adds and shifts if you're really stingy with the silicon.
(Memory operations will of course take multiple cycles too, but that's not the CPU's fault.)
The biggest divide is that no more than a single exception can occur in a RISC instruction, but you can have an indefinite number of page faults in something like an x86 rep mov.
That's not even true as you can get lots of exceptions for the same instruction. For example a load can all of these and more (but only one will be reported at a time): instruction fetch page fault, load misaligned, and load page fault.
More characteristic are assumptions about side effects (none for integer, and cumulative flags for FP) and number of register file ports needed.
In order to have an instruction set that a student can implement in a single semester class you need to make simplifications like having all instructions have two inputs and one output. That also makes the lives of researchers experimenting one processor design a lot simpler as well. But it does mean that some convenient instructions are off the table for getting to higher performance.
That's not the whole story, a simpler pipeline takes less engineering resources for teams going to a high performance design so they can spend more time optimizing.
RISC is generally a philosophy of simplification but you can take it further or less far. MIPS is almost as simplified as RISC-V but ARM and POWER are more moderate in their simplifications and seem to have no trouble going toe to toe with x86 in high performance arenas.
But remember there are many niches for processors out there besides running applications. Embedded, accelerators, etc. In the specific niche of application cores I'm a bit pessimistic about RISC-V but from a broader view I think it has a lot of potential and will probably come to dominate at least a few commercial niches as well as being a wonderful teaching and research tool.
The RISC dream was to simplify CPU design because most software was written using compilers and not direct assembly.
Characteristics of classical RISC:
- Most data manipulation instructions work only with registers.
- Memory instructions are generally load/store to registers only.
- That means you need lots of registers.
- Do your own stack because you have to manually manipulate it to pass parameters anyway. So no CALL/JSR instruction. Implement the stack yourself using some basic instructions that load/store to the instruction pointer register directly.
- Instruction encoding is predictable and each instruction is the same size.
- More than one RISC arch has a register that always reads 0 and can't be written. Used for setting things to 0.
This worked, but then the following made it less important:
- Out-of-order execution - generally the raw instruction stream is a declaration of a path to desired results, but isn't necessarily what the CPU is really doing. Things like speculative execution, branch prediction and register renaming are behind this.
- SIMD - basically a separate wide register space with instructions that work on all values within those wide registers.
Is there a RISC dream? I think there is an efficiency "dream", there is a performance "dream", there is a cost "dream" — there are even low-complexity relative to cost, performance and efficiency "dreams" — but a RISC dream? Who cares more about RISC than cost, performance, efficiency and simplicity?
There was such dream. It was about getting the mind-bogglingly simple CPU, put caches into the now empty place where all the control logic used to be, and clock it up the wazoo, and let the software deal with load/branch delays, efficiently using all 64 registers, etc. That'll beat the hell out of those silly CISC architectures at performance, and at the fraction of the design and production costs!
This didn't work out, for two main reasons: first, just being able to turn clocks hella high is still not enough to get great performance: you really do want your CPU to be super-scalar, out-of-order, and with great branch predictor, if you need amazing performance. But when you do all that, the simplicity of RISC decoding stops mattering all that much, as Pentium II demonstrated when it equalled DEC Alpha on performance, while still having practically useful things like e.g. byte loads/stores. Yes, it's RISC-like instructions under the hood but that's an implementation detail, no reason to expose it to the user in the ISA, just as you don't have to expose the branch delay slots in your ISA because it's a bad idea to do so: e.g. MIPS II added 1 additional pipeline stage, and now they needed two branch/load delay slots. Whoops! So they added interlocks anyway (MIPS originally stood for "Microprocessor without Interlocked Pipelined Stages", ha-ha) and got rid of the load delays; they still left 1 branch delay slot exposed due to backwards compatibility, and the circuitry required was arguably silly.
The second reason was that the software (or compilers, to be more precise) can't really deal very well with all that stuff from the first paragraph. That's what sank Itanium. That's why nobody makes CPUs with register windows any more. And static instruction scheduling in the compilers still can't beat dynamic instruction reordering.
Great post as it is also directly applicable to invalidate the myth that the arm instruction set somehow makes the whole cpu better than analogous x86 silicon. It might be true and responsible for like 0.1% (guesstimate) of the total advantage; it's actually all RISC under the hood and both ISAs need decoders, x86 might need a slightly bigger one which amounts to accounting noise in terms of area.
You had literal students design chips that outperformed industry cores that took huge teams and huge investment.
Acorn had a team of just a few people build a core that outperformed an i460 with likely 1/100 investment. Not to mention the even more expensive VAX chips.
Can you imagine how fucking baffled the DEC engineers at the time were when their absurdly complex and absurdly expensive VAX chip were smocked by a bunch of first time chip designers?
> as Pentium II demonstrated
That chip came out in 1997. The original RISC chip research happened in the early 80s or even earlier. It did work, its just that x86 was bound to the PC market and Intel had the finances huge teams hammer away at the problem. x86 was able to overtake Alpha because DEC was not doing well and they couldn't invest the required amount.
> no reason to expose it to the user in the ISA
Except that hidden the implementation is costly.
If you give 2 equal teams the same amount of money, what results in a faster chip. A team that does a simply RISC instruction set. Or a team that does a complex CISC instruction set, transforms that into an underlying simpler instruction set?
Now of course for Intel, they had backward comparability so they had to do what they had to do. They were just lucky they were able to invest so much more then all the other competitors.
> If you give 2 equal teams the same amount of money, what results in a faster chip.
Depends on the amount of money. If it's less a certain amount, RISC design will be faster. If it's above, both designs will perform about the same.
I mean, look at ARM: they too have decode their instructions into micro-ops and cache those in their high-performance models. What RISC buys you is the ability to be competitive at the low end of the market, with simplistic implementations. That's why we won't ever see e.g. a stack-like machine — no exposed general-purpose registers, but with flexible addressing modes for the stack, even something like [SP+[SP+12]]; stack is mirrored onto the hidden register file which is used as an "L0" cache which neatly solves the problem that register windows were supposed to solve, — such a design can be made as fast as server-grade x86 or ARM, but only by throwing billions of dollars and several man-millenia at it; and if you try to do it cheaper and quicker, its performance would absolutely suck. That's why e.g. System/360 didn't make that design choice although IBM seriously considered it for half a year — they then found out that the low-level machines would be unacceptably slow so they went with "registers with base-plus-offset addressed memory" design.
To add on to what the sibling said, ignoring that CISC chips have a separate frontend to break complex instructions down into an internal RISC-like instruction set and thus the difference is blurred, more RISC instruction sets do tend to win on performance and power for the main reason that the instruction set has a fixed width. This means that you can fetch a line of cache and 4 byte instructions you could start decoding 32 instructions in parallel whereas x86’d variableness makes it harder to keep the super scalar pipeline full (it’s decoder is significantly more complex to try to still extract parallelism which further slows it down). This is a bit more complex on ARM (and maybe RISCV?) where you have two widths but even then in practice it’s easier to extract performance out of it because x86 can be anywhere from 1-4 bytes (or 1-8? Can’t remember) which makes it hard to find boundary instructions in parallel.
There’s a reason that Apple is whooping AMD and Intel on performance/watt and it’s not solely because they’re on a newer fab process (it’s also why AMD and Intel utterly failed to get mobile CPU variants of their chips off the ground).
Any reading resources? I’d love to learn better the techniques they’re using to get better parsllelism. The most obvious solution I can imagine is that they’d just try to brute force starting to execute every possible boundary and rely on it either decoding an invalid instruction or late latching the result until it got confirmed that it was a valid instruction boundary. Is that generally the technique or are they doing more than even that? The challenge with this technique of course is that you risk wasting energy & execution units on phantom stuff vs an architecture that didn’t have as much phantomness potential in the first place.
Not small instruction sets, simplified instruction sets. RISC’s main trick is to reduce the number of addressing modes (eg, no memory indirect instructions) and reduce the number of memory operands per instruction to 0 or 1. Use the instruction encoding space for more registers instead.
The surviving CISCs, x86 and z390 are the least CISCy CISCs. The surviving RISCs, arm and power, are the least RISCy RISCs.
RISC V is a weird throwback in some aspects of its instruction set design.
Lets be real, its about business models. POWER was and is backed by IBM. ARM won on mobile. Does this mean POWER and ARM are better then MIPS, SPARC, PA-RISC, Am29000, i860? I don't think so.
In this particular context, they're trying to run code compiled for x86_64 on RISCV5. The need from "we just need a few more instructions to get feature parity" comes from trying to run code that is already compiled for an architecture with all those extra instructions.
In theory, if you compiled the original _source_ code for RISC, you'd get an entirely binary and wouldn't need those specific instructions.
In practice, I doubt anyone is going to actually compile these games for RISCV5.
Beyond the most trivial of microcontrollers and experimental designs there are no RISC chips under the original understanding of RISC. The justification for RISC evaporated when we became able to put 1 million, 100 million, and so on, transistors on a chip. Now all the chips called "RISC" include vector, media, encryption, network, FPUs, and etc. instructions. Someone might want to argue that some elements of RISC designs (orthogonal instruction encoding, numerous registers, etc.) make a particular chip a RISC chip. But they really aren't instances of the literal concept of RISC.
To me, the whole RISC-V interest is all just marketing. As an end user I don't make my own chips and I can't think of any particular reason I should care whether a machine has RISC-V, ARM, x86, SPARC, or POWER. In the end my cost will be based on market scale and performance. The licensing cost of the design will not be passed on to me as a customer.
It's a fine meant to be a punishment, not damage settlement.
> All DPAs in Europe calculate the amount of fines for businesses in the same manner. Those fines amount to a maximum of 4% of the worldwide annual turnover of a business.
I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.
I don't know anyone who isn't optimising for development time in some way. That said, most frameworks don't provide any worthwhile error handling infrastructure, and it's a problem.
In a Jetpack Compose app I wrote, I created generic "error barrier" components, so that error messages display over relevant parts of the app, with just a few lines each time, timeouts included. I think this is the best approach, easy for developers and informative for users. Too many apps just ignore errors.
I meant optimizing for developer time over usability in the context of the story, that mostly shows products from Google. Google being the opposite of a small development team that could be forced to choose developer time over usability.
In my experience the overwhelming majority of teams out there are understaffed (especially when it comes to good and productive professionals) so your example is the rule, not the exception.
Unfortunately it's very likely the button will be gone in favor of Face ID and it's going to use the case design of a previous model so it will get bigger. It's going to suck to operate when wearing a helmet and glasses.
They could somewhat sidestep this problem if they did what some Android phones do and put a fingerprint sensor into the power button. Not that I think they will do that, but in a different world, they could.
They did this on some of the iPads. Even with Face ID, I think having a power button sensor is nice for people who often have their face covered and want an alternative biometric auth method.
That is an additional SKU to manage, and Apple is extremely ruthless in minimizing redundant components, as this was a major reason Apple had horrid margin in the 1990s.
All manufacturers are moving away from buttons for that reason - from automotive to consumer electronics.
The same money spent on a dedicated SKU for buttons can be spent on a better optimized OLED display to reduce lag.
It's also surprising how quickly companies are giving up their strict access control by letting employees basically search through everything. I'm used to customers asking for more fine-grained access rules, not less strict.
Given the widespread misuse of these systems (eg. "I'm going to look up my friend's bank account for fun"), that doesn't seem like a great strategy.
Employees can already search through everything. Copilot makes it easier to find things but it runs with the user’s permissions and obeys the existing access rules
> Employees can already search through everything.
Not in the places I worked. Not at all! There were confidential matters that only people with dedicated responsibility can access and act on. Otherwise it would be a disaster whenever a less honest employee come accross data useful to act on the companies behalf or worse, act directly pretending being one of those eligible people.
Then I wonder how this bots handle the info. Are those scanning through what's there and build the knowledge into self? I guess so, otherwise how would know what is what when asked about, if something is a thing and being there at all. And then if having limited access then the bot would be clueless about some important things the people with elevated credentials need. Or, if can scan everything, I mean everything!, then that data is built into the bot, it 'knows' it, so it is just time tricking to give it out to those not eligible. Pretending being someone, or pretending getting received elevated credentails, or who knows what ways could be there to trick and squeeze that knowledge out from these chatty things. Or can be there several different bots, training multitude of bots, some left clueless like an ordinary employee and not let talk to, the CEO having an administrative bot that knows it all? I am jut trying to imagine being complete outsider how these things work.
Employees can already search through everything _they have permission to _
Copilot only has access to whatever the user has access to - it uses the same permissions.
The copilot bots in the article are slightly different from normal copilot so might have elevated permissions but if you are creating a service with access to your data then you should make sure it has the correct restrictions in place - there is nothing special about copilot in this regard.
But bots need to be trained on data before use. That the bot will 'soak in'. And have acces to the specific set of data allowed during the training. Which then will be given out at the time being used. Either those bots have access to the very same set of data at training time as the user will have at using time, or there will be trouble (not working with right set of data and miss things, or giving too much not having privilege to normally). Right? Jut trying to understand.
So then each user need to use a specific bot trained precisely to the level of acces the user is having. And need proper matching mechanism the right bot to the right user without glitch. Right? Switching bots at changing privilege levels, deserting previously used one for a - for the user - brand new one. Like this?
Most universities have had their own corpora to work with, for example: the Brown Corpus, the British National Corpus, and the Penn Treebank.
Similar corpora exist for images and video, usually created in association with national broadcasting services. News video is particularly interesting because they usually contain closed captions, which allows for multi-modal training.