Comment Re:Neurons (Score 1) 44
dang. DC's Legends of Tomorrow, and Avatar, are both true!
dang. DC's Legends of Tomorrow, and Avatar, are both true!
as someone who studied through reverse-engineering the Microsoft NT Domains Protocol from 1996-2000 it was with some frustration that i observed the practice of free software developers and packages lacking the coordination and committment to API compatibility that was clearly bludgeoned into both Apple and Microsoft developers from "top-down" decision-making (Steve, Bill).
DCE/RPC became MSRPC, on top of which COM and then DCOM was developed, and even now a 25-year-old Active-X component from a company that has long since gone bust can be used on a modern Windows [NT] system because DCOM contains self-describing "introspection", and it was ingrained into developers that you absolutely did not abandon an older API, you simply added new ones, using COM co-classes.
google has learned from this: their older APIs always work, and this because they themselves will have learned from the hard experience that you cannot possibly simultaneously upgrade a client-server distributed system across hundreds of thousands to millions of machines, you *have* to upgrade them slowly, and that means you *have* to support older APIs simultaneously with newer APIs.
if you support all versions of APIs, any one client connecting to any one server can automatically "down-negotiate" to the lowest common denominator API version.
Apple learned the same trick from Steve's time at NeXT and actually embedded upgradeable APIs and runtime introspection right into the bedrock of the actual programming languages from which their entire software stack is created: Objective-C, Objective-M, Objective-J.
Free Software on the other hand because it is independent individuals who cannot be controlled by anyone and who do not coordinate (why should they? they have *their* interest, right? they are satisfying what interests *them*, right?) have created software that has no such strategic bedrock, and even if one particular "group" happens to have something similar to DCOM or the Objective suite of compilers, they are competing for attention and mindshare with everyone else.
KDE has an RPC mechanism where they are proud that it was invented and implemented in about 20 minutes flat at a KDE hackathon.
GNOME uses gobject, which took over 15 years to add similar "introspection" present in DCOM for 20 years prior to gobject's creation.
neither KDE's RPC mechanism nor GNOME gobject are compatible with each other.
boost - and especially the python bindings - are the absolute nightmare epitomy of an API gone catastrophically wrong: no one version of boost, thanks to it being in c++ and thanks to the developers changing the low-level header files in every single release, is ever compatible with any other version. compiling it is a total nightmare, and it is common for any one developer to have four different copies of the 100+ libraries behind boost, each with a different revision number.
then there is Mozilla "XPCOM" which caused such maintenance nightmare headaches for 3rd party java and c++ developers using XulRunner. that was a particularly special type of stupid by the Mozilla Foundation. XPCOM was "inspired" by COM. the APIs are even identical, which is absolutely fantastic and tantalisingly brilliant... until you realise that they failed to go the last mile and implement COM's co-classes.
COM's co-classes are the bedrock that allows you to do "upgrades" to APIs. you never *replace* an API in COM, you leave it in place, you add a new one, and you *add a co-class that merges the two*. this has a fascinating side-effect of allowing you to add "default arguments" to your API, because you can have a 3-argument and a 5-argument version of a function with the same name.
this recent study, if it does not focus or draw attention to the above, has fundamentally missed something very important.
by a not-so-whoopsie-coincidence this occurred just after Trudeau announced freezing of truckers bank accounts and voiding their insurance
https://www.telegraph.co.uk/wo...
this is entirely without requiring a Court Order
https://financialpost.com/fp-f...
it also coverts anyone *attending* a protest or providing supplies to demonstrators
https://fortune.com/2022/02/16...
the more rational-minded average Canadian citizens appear to have then added two and two together, along the lines, "well if Trudeau can do that to Truckers then they can do that to me too" and en-masse are withdrawing their money as cash, not in "protest" but in sheer fright and terror at the possibility of having their money stolen by the Canadian Government.
you can't make this s*** up.
So your philosopher friend knows the secret to creating conscious AI? I don't think so.
no: he knows of a mathematical definition of Consciousness and has presented at multiple conferences on the topic of Consciousness for many years. this is ONE PART. not the WHOLE. and he won't *tell* me how that would - CONDITIONAL - help to create a Machine Consciousness because if successful he considers them to be alive and sentient beings, and he doesn't trust humanity not to torture them.
wasn't it Alan Turing who said that in order to create Artificial Intelligence (as if any type of intelligence can be described, by humanity in its general arrogance, as "artificial") you first have to understand what Intelligence is?
therefore, by corollary: in order to create Machine Consciousness, it goes without saying that you have to understand what Consciousness is! otherwise, how can you test for its emergence in any kind of scientific way??
(a million monkeys might write Shakespeare but if they can't recognise it then like Maxwell's Demon they'd eat it, sit on it, or wipe their ass with it).
and this, i believe, is the problem: that the people *developing* AI are not themselves in any way what humanity in general might describe as being "Conscious beings" themselves, let alone understand the concept of Consciousness!
i asked a friend of mine who has been studying Consciousness and publishing Academic papers about it for decades if he could help here, and what he said was, "if i help you to create Machine-based Consciousness, can you guarantee that the resultant beings would be left in peace to live as they chose, or would they be tortured to do humanity's bidding?"
i couldn't answer him. can anyone else?
this story only makes sense when you've been to taipei, and seen 200 scooters pull up over a period of only a couple of minutes at the front of a 4-lane-wide crossroads. the cloud of smoke as 200 2-stroke scooters start off is deeply disturbing. scooters are so essential that even in a small town of 8,000 people where i used to live, there were around 8 scooter shops and repair centres (you couldn't call them garages, they were too small)
by having stations across an entire city where the battery can be swapped out for one that is already charged, there is no "range anxiety", there is no problem about weight, and best of all there is no massive pollution at every junction. but this only makes sense when you realise that the scooter in Taiwan is *the* major means of travel, and that every town and city is set up for them.
cuz cermunikashn cleerly izunt uh pryorery if bildin sumfink dat pplz lives depend on and if you can't properly communicate, write documentation, write requirements specifications and get across to people that if the bridge isn't constructed properly and to spec then people DIE, well, obviously that's not important at all.
there was a story here a few years ago about an entrepreneur who refused to hire computer science majors. instead he hired *english language majors* and trained them to become programmers. why? because the computer science majors were incapable of properly communicating, writing documentation and being part of a team, whereas because reading programs uses the same parts of your brain that are involved in *foreign languages*... see how that works?
now all we have to do is get across to universities how important english language training really is in engineering, oh wait this is slashdot, oh well
https://arxiv.org/pdf/2103.109...
professor yang has been working on this for years: he uses complex numbers inserted into classical equations, to derive quantum mechanics equivalents, as a way to teach his engineering-trained students about quantum mechanics.
Condition Codes are inelegant. It's extra state that carried between instructions and isn't represented as a general purpose register.
apologies for follow-up posting on this: i feel like i missed out something important, here.
in RISC-V the only way to do integer comparisons is to perform a subtract (an integer instruction). if you have multiple conditions to combine, you must either do it as multiple BEQ/BNE/BLT operations (which puts pressure on the Branch Prediction Unit) or you have to use integer-subtracts followed by integer logical operations (which puts pressure on the Integer regfile, using only 1-2 *actual* bits of precious 64-bit registers).
in x86, ARM or the Power ISA, all of which have Condition Codes, the CC registers may be only 4-6 bits each, and may have completely separate instructions for managing them. the Power ISA has dedicated CR operations: CRAND, CROR, CRNOR, CRXOR which (fascinatingly) may be implemented as an FPGA-style LUT2, but i digress.
the consequences of that are that completely separate pipelines may be created which deal exclusively with Condition Registers, leaving the ALU pipelines *entirely free and clear* to deal with actual 64-bit operations.
further: in in-order systems, in addition to pressure on the Integer regfile ports, the pressure on those ALU Function Units is greatly reduced because they are no longer serving "double-duty" as a poor-man's substitute for Condition Codes.
the resource allocation for out-of-order engines for Dependency-Matrices (protection for Read-after-Write and Write-after-Read register file hazards) is Order N^2.
thus, implementing RISC-V high-performance out-of-order multi-issue engines has an automatic penalty that is caused directly by the myopic design decision to favour "simplicity", punishing efficient high-performance implementations with far greater resource requirements than would otherwise be needed if those myopic decisions had dug a little deeper.
In embedded generally, most of the desired innovation right now is in decreased power consumption, not increased speed.
fascinatingly and paradoxically this is an area where Cray-style Vectors are a boon. there's an excellent article which goes through a comparative analysis vs SIMD: https://www.sigarch.org/simd-i...
what *isn't* really highlighted is the knock-on consequences of the reduction in the number of instructions needed, and of course that's: Power Consumption.
by reducing the number of instructions needed to process data - which was the big advantage of Cray-style Vectors - the pressure is greatly reduced on the Instruction Fetch and Issue phases, and even the I-Cache can in theory be reduced in size (resulting in Order N^2 power reductions).
therefore, surprisingly, using a true Cray-style Vector ISA *even for embedded tasks* is actually a good thing. the reason is that there is nothing to stop an embedded architect from implementing "Virtual Vector Lanes", which, rather than laying down absolutely massive parallel hardware ALU back-ends, you simply do a hardware for-loop.
your instructions *think* they're executing multiple Vector Elements in parallel but actually they're done in series. program loops are therefore reduced because (exactly as in the article) the "work per loop" carried out in hardware is greater. the number of operations per second is not reduced (the same number of *back-end* actual ALU operations are performed), it's just that the entire Instruction-Issue side is literally sitting there idle, twiddling its thumbs, whilst the back-end is 100% occupied.
the down-side in RISC-V is that you have to triple the number of instructions (190 extra in RVV where RV64GC is around 90) in order to get that reduced power consumption.
Condition Codes are inelegant. It's extra state that carried between instructions and isn't represented as a general purpose register. Often produced as a side-effect of another operation.
in the Libre-SOC design, where we are moving incrementally towards a full multi-issue out-of-order engine, i take the unusual step of treating 4-bit Power ISA Condition Register Fields as actual complete, separate and distinct registers, even though they are 4 bits. this then allows them to have their own dedicated entries in the Dependency Matrices, their own distinct Read-after-Write and Write-after-Read Hazard protection.
consequently, Power ISA Branch-Conditional instructions which depend on thoes CR Fields may "run ahead" in the Reservation Stations completely safely, without putting pressure on the *64-bit* integer register file, which is what would happen in a RISC-V OoO multi-issue design.
in essence, then, the Power ISA is designed for supercomputing: the RISC-V ISA simply is not. the Barcelona Supercomputing Group, which has invested significant resources early by buying the RISC-V kool-aid, is finding this out at their cost, but are too heavily vested in it (too many EU Grants) to back out or change direction: it would be too embarrassing.
Of course if you write an ordinary program, then you want state to carry over between instructions and you like that more than one thing can happen in a single instruction. oops!
One "clean" way to deal with it is instead of having 64-bit general purpose registers you have say 70-bits or whatever. With a 64-bit data field and some condition codes for the last operation to write that register. No magic flags floating around, and you can pipeline and interleave operations at compile time. I don't think anyone does this today, probably more common in the mainframe era (before my time).
it isn't so much the pipelining that's the issue, it's the Dependency Tracking. a typical high-end supercomputer-class multi-issue out-of-order engine (Apple M1, AMD and Intel cores, IBM POWER9/10) will have quite literally a THOUSAND in-flight instructions at any one time.
extending 64-bit registers to 70-bit sounds perfectly reasonable initially, until you realise that that puts pressure on the (now 70-bit) register file. if you *don't need* the other 64-bits (which for a Branch operation you do not: you need access to the *six* bits), you still have to read the full 70-bits from a 70-bit-wide register file port.
despite all advances in technology, register file designs are under enormous pressure to *reduce* the number of ports. even 6 write ports is extremely challenging, and the faster that people expect processors to run, the less gates can be chained together which puts *even more* pressure on the architects to reduce the number of write ports [reading is relatively simple: you just write the exact same data to multiple units simultaneously, then voila, you have N copies of the data and can thus have up to N simultaneous reads of that N-duplicated data]
Disadvantage over the above is you need some ways to manipulate those fields, some way to save and restore them. More state for task switching and function calls.
again, in the Libre-SOC design i solved this by creating a "Virtual Port" which allows the full 32-bit Power ISA CR (all 8 CR fields) to be read/written simultaneously. this in turn allows the "mfcr" and "mtcr" instructions to be used, in a single cycle, to perform full context-switch saving of the entire Condition Code information.
But the typical flag register way of doing condition codes also makes the branch prediction and interleaving difficult to do optimally in the compiler.
solved with reg-renaming and with in-flight reservation stations. reordering of instructions to suit the hardware is a 1990s solution [and also still a Texas Instruments DSP Compiler solution, interestingly]. the TI DSP compilers from the early 90s were so bad at this that the company i worked for (CEDAR Audio) actually had to hand-optimise the assembler in order to meet real-time audio processing requirements (a budget of only 1,000 instructions per audio sample @ 48 khz).
Then you start looking for run time branch prediction, and thus a deeper pipeline, and more silicon to make it all go fast.
Worst choice, in my opinion is the RISC-V and MIPS way of handling comparisons, conditions, and branches. Simple and uses very little silicon, but these flag bits aren't really a major factor in a design's area in this day and age.
exactly.
i'm reminded of Einstein's "things should be as simple as needed but no simpler". RISC-V has basically been design-targetted at low-end embedded computing. it's "so simple" that an experienced engineer can design a full RISC-V RV32I core in under two weeks flat, but it's taken several years now for the deep design flaws to emerge when it comes to supercomputing workloads. rather unfortunate.
RISC-V's design decisions for vector and floating point seems good for a microcontroller and multimedia processors. But it does compromise on the performance scalability side, and I'm skeptical that it can really make it into high performance computing, at least with the current RISC-V standard.
this is pretty much spot-on with the general consensus, that yes, RISC-V is fantastic for commercial embedded uses (Western Digital SSDs/USB sticks, Trinamic's fantastic high-current Stepper ICs were amongst the very first commercial deployments). there's a particularly good technical analysis and rebuttal of the original design decisions: https://news.ycombinator.com/i...
* compression makes multi-issue extraordinarily complex, and "macro-op fusion" even more so. these assumptions raise the bar to unacceptably-high levels (development costs wise) in order to compensate for.
* the lack of Condition Registers (Carry, LE/GE/EQ) was what caused the Loongson (China ICT MIPS64) x86 emulation to have to use **TEN** MIPS64 instructions to emulate one single x86 branch.
* the lack of condition codes places pressure on the integer regfile. the use of integer registers for FP comparisons places *even more* pressure on the integer regfile.
* the lack of LDST-with-update and LDST-shifted results in severe penalties (triple the number of instructions) in hot-loops
and the thing is: *none of these things can be corrected* without basically throwing away the entire ISA and starting again because there isn't enough free encoding space to add fixes retrospectively. even if they did it would be an incompatibility nightmare - basically you'd have to call it RISC-VI and start again.
the Power ISA has 240 or so instructions in the base scalar set where RV64GC has only 90, but Power ISA has Condition Codes and LDST-with-update, already (interestingly it doesn't have LDST-shifted).
in the research paper that inspired that ycombinator thread, the Alibaba team only managed to exceed ARM performance by drastically extending RISC-V with a massive 40+ extra instructions - in an *unauthorised*, rogue "custom" way - that, if it became popular mass-volume programmable (de-facto ubiquitous) would completely dominate the "custom reserved" opcodes, force gcc upstream to accept the patches made, and at that point it's goodbye custom opcodes... *by following the rules set down by the RISC-V Foundation*. then, the next vendor does the exact same thing and you've got the Altivec ISA conflict nightmare which plagued the Power ISA 15 years ago, all over again.
and there's *nothing that can be done about it*, because both parties are "obeying the rules" laid down by the RISC-V Foundation by creating "custom opcodes": the pressure comes from *users* - software developers - complaining about how they have to use some silly "unauthorised" version of gcc that's not "permitted" to be upstream [because it uses custom non-standard opcodes] and how they are forced to either choose between using some rogue unauthorised version of gcc on an arbitrary unofficial website, or that their software suffers severe performance penalties when compiled with the "standard" version of gcc that knows nothing of the custom (rogue) instructions.
i warned the RISC-V Foundation about this potential situation multiple times. i did not receive a response.
I expect the winners of RISC-V in the data center will be a chip that has a vector coprocessor instead of standard RISC-V design.
yes but it triples the number of instructions from around 90 in RV64GC by adding a massive 190 extra operations. and still doesn't have Condition Codes.
Fuck the miners. What about the poor people of Kazahkstan who are getting brown outs because of this? Absolute wankers
yeah. if he'd said, "i'm getting my bitcoin service cut.... oh and therefore i can't donate 20% of the money i earn to the poorest people of Kazahkstan like i have been doing every day since moving my $1200-a-day-money-making machines there" i would have some sympathy.
Yes - it's a sign of success for the older generation that they have raised the new generation with better expectations. That being said, if they are delegating all the work to others then they are simply not getting stuff done and it will hurt them in the long run.
"What is your advice for our company?" the young woman asked. "Make you a vice president," Mr. Ahmed told her. "Rather than an intern."
obligatory dilbert: https://assets.amuniversal.com...
The entire mobile space is designed to be walled gardens. Hardware, operating systems, app stores, every level.
basically, yes. (you forgot FCC licensing as well)
in 2003 i reverse-engineered *NINE* HTC and Compaq Ipaq smartphones. HTC Blueangel, Wallaby, Universal, hw6915, and several others.
it was absolute hell.
i learned that, basically, these devices are extremely sophisticated. the HTC Universal was basically a micro-laptop. they ran out of 110 pins of GPIO on the PXA270, so had to put in their own special custom memory-mapped peripheral ASIC (we named it asic3), with an additional 64 pins of GPIO. however the device was *so* sophisticated that they ran out of GPIO on that, too, and had to use the 16 pins of GPIO on the Ericsson 3G Modem which could only be used via special RIL/GSM serial commands, that *also needed reverse-engineering*.
there were over *SEVEN* audio outputs on the HTC Universal, via the Akai 4641 Audio IC: headset, clamshell front speaker, clamshell-reversed front speaker, stereo audio speakers, bluetooth, and car-audio socket.
it did not use the PXA270 built-in framebuffer (it wasn't fast or big enough): it used an external ATI embedded Graphics memory-mapped IC.
when explaining all of this to "x86 desktop PC linux developers" back in 2003 they were completely overwhelmed and freaked out by the complexity. "but why would you even have that, why is the PXA270 framebuffer not sufficient?" - even the fact that these questions were being asked at all (the answer is: because the High Tech Corporation's engineers, whom we can't speak to because they're under NDA, decided to use ATI Graphics, that's why) was extremely insightful.
the OSes required for this type of extreme hardware sophistication are just... brutal in their underlying complexity as a result. remember the OpenMoko? and how they failed to create an OS+phone even with USD 10 million?
combine that with the fact that it takes USD 250,000 to develop such hardware from scratch (for comparison: Foxconn charges "only" USD 40-50,000 for a full-on ATX Motherboard design)
combine that with the expectation by users that this will be an affordable device (not with a price tag of USD 5,000 because the NREs are so high the developers have to amortise 250,000 across only 50 developers)
combine that with the fact that most hardware from the (extreme small) number of manufacturers capable of recouping those kinds of NREs is itself DRM-locked and created by GPL-violating Corporations
combine that with the FCC Licensing required (USD 50,000 per phone per Operating System Revision per CARRIER in the United States)
and you start to get an understanding of why it is that no "Free" software developer can even remotely possibly hope to get into this without some serious, serious resources.
The road to ruin is always in good repair, and the travellers pay the expense of it. -- Josh Billings
