SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
SoylentNews
On Youtube I watched a Mac user who had bought an iMac last year. It was maxed out with 40 GB of RAM costing him about $4000. He watched in disbelief how his hyper expensive iMac was being demolished by his new M1 Mac Mini, which he had paid a measly $700 for.
In real world test after test, the M1 Macs are not merely inching past top of the line Intel Macs, they are destroying them. In disbelief people have started asking how on earth this is possible?
If you are one of those people, you have come to the right place. Here I plan to break it down into digestible pieces exactly what it is that Apple has done with the M1.
Related:
What Does RISC and CISC Mean in 2020?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
My LESLIE GORE record is BROKEN ...
(Score: 2) by JoeMerchant on Wednesday December 02 2020, @04:04PM (17 children)
What is RISC? If the instructions in the pipeline are CISC can the processor be called RISC if the pipeline instructions get decomposed to RISC?
If RISC is really so great, shouldn't GCC be outputting RISC instructions?
At the lowest level, all (commercial) processors evaluate 0s and 1s to do what they do, can't get much more reduced than that.
🌻🌻 [google.com]
(Score: 5, Informative) by Anonymous Coward on Wednesday December 02 2020, @05:04PM (1 child)
RISC really means a load-store architecture with simple instructions that execute in a single clock cycle, with operands and even data in the same machine word. For example, 32-bit SPARC has to use 2 instructions to read a 32-bit value from memory. Where RISC wins is there's more room on the chip for more registers, cache, branch prediction, speculation, additional pipelines and so on. And because of the simplicity they can run at higher clock speeds.
Modern x86 CPUs since Cyrix brought out the 6x86 are internally RISC with a CISC decoder layer on. This is also a win, because some CISC opcodes are very small (1 byte) saving RAM and bus bandwidth, but also because the decoder knows the state of the whole CPU at execution time and can make on-the-fly optimizations. Note that intel itanic couldn't do this in hardware...
(Score: 1, Interesting) by Anonymous Coward on Wednesday December 02 2020, @10:59PM
Thank you for straightening out poor Joe Merchant.
X86 was an exciting way to work when you had 4000 transistors and 16K of RAM - sometimes a whole lot less than that. I programmed in MASM for a very long time, and always felt great for solving those intricate puzzles in as few clocks and bytes as possible. I'm sure some of my libraries are still in use today, though mostly transmogrified for wider CPU registers.
I didn't think much of ARM when it first came out - too byte-wasteful for those times, and too wordy for assembly language programming. I Was short-sighted. So many things are eternal, but it's time to move to a more rational instruction set, on a platform for these times. Besides, it'll take Redmond a decade to almost get it right, but Linux will be running first, because there are a lot of people rooting for the future.
(Score: 2) by mobydisk on Wednesday December 02 2020, @05:37PM (14 children)
Read the article. It explains what you need to know.
It does, but only when compiling for a RISC processor. It cannot output ARM's RISC instructions and expect them to run on an x86 CPU.
(Score: 5, Informative) by JoeMerchant on Wednesday December 02 2020, @05:58PM (13 children)
I was in "Digital Design" graduate studies when the big RISC hype hit in the late 1980s. At that time, RISC was pretty clearly defined as a Reduced Instruction Set Computer: fewer (implicitly simpler) op codes, with the purported advantage of running at faster clock rates / instruction execution times. At that time, RISC architectures resulted in larger object code files to achieve the same ends as CISC competitors, and the faster clock rate was mostly a wash with the increased number of instructions that needed to execute, with all kinds of niches giving advantage to one or the other architecture school.
Since then the definitions have evolved along with technology, it's not the clear R vs C distinction that it once was. To me, it feels like RISC has finally "won" by changing the definition of what RISC is until it has met that sweet spot between the two where the most advantage is.
🌻🌻 [google.com]
(Score: 3, Interesting) by anubi on Wednesday December 02 2020, @10:54PM (11 children)
I understand the 6502 was among the first RISC chips out there.
It's great appeal to me was it was much simpler to determine how long it took for each piece of code to execute. One instruction, one clock.
I was doing a lot of real-time programming. Stepper motor control and positioning systems where physical inertial dynamics was an integral part of the design.
I still cling to my Arduinos for the exact same reason.
I don't like multitasking on my robotics.
I'd much rather design in another cpu for each real-time thingie I have to do, then use yet another for supervisory tasks. And make each one capable of standalone manual terminal input for checking them out on the bench so I can verify its doing what it's supposed to do.
I get too many things going on at once, and it soon becomes damn near impossible for me to track down timing gremlins.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 3, Informative) by JoeMerchant on Thursday December 03 2020, @02:31AM (9 children)
I developed a couple of "Deterministic Real Time" systems on 6811 processors, very similar to 6502. I programmed it in C, but would check the assembly code to ensure that no real-time path would take longer than the allotted time (usually 500uS). The system would have a single timed interrupt that ran various processes in deterministic real time, and then a main loop that would handle all the non real time stuff. Very simple, very reliable, no surprises ever and powerful enough to do basically anything I've ever needed an embedded system to do.
Years before I did that, and continuing through to today, I see otherwise bright software engineers fall down the RTOS prioritized interrupt rabbit hole and get mauled time and time again down there where it's dark and they can't really see what's happening to them.
🌻🌻 [google.com]
(Score: 1) by anubi on Thursday December 03 2020, @08:57AM (8 children)
I kinda cheated...
The Commodore64 had made it's debut... And they sold the assembler for it as well.
I used that for many years to develop code...using oscilloscopes to time my code.
Like you say...interrupt handling...once my time critical code launched, it had the machine's undivided attention.
I worked on one thingie, part of a high speed data acquisition system, where I phaselocked the processor clock with an analog phase locked loop 74HC7046, so I could sync my reception of data in lock step to the geophysical sensor that was streaming the data to me. To eliminate sampling artifacts.
Gee, I miss those old days.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by JoeMerchant on Thursday December 03 2020, @12:33PM (7 children)
Checking the assembly was pretty easy - the C compiler would show you the assembly code, complete with cycle time for each instruction. All I had to do was run the paths through the real time handlers and make sure nothing added up to (umm... 4MHz = 250nS, 500uS per slice) ~1900 or more. Avoid loops and crazy branching schemes and it all goes pretty easily. If I did it for much longer it wouldn't have been too hard to make a tool that auto-processed the assembly dumps to do the summations for me.
We were (primarily) reading an inductive plethysmograph, basically period counting a ~400KHz oscillator with a 96MHz crystal clock using a CPLD with counter/latches to get high precision readings of changes in inductance. The 6811 would pull the counts off the latches at 2KHz multiplexing through 2 to 5 different inductors, depending, then reconstruct that into 2 to 5 signals with a 50 to 200Hz sample rate, again depending on configuration. 2 years of graduate studies in digital design and that's the most complex digital project I ever did design for in 30 years in the general field. Seems like the career has been 0.2% hardware design, 24% software design, 2.8% software maintenance, 3% mechanical design, 5% research/lab work, 25% documentation and 40% meetings.
🌻🌻 [google.com]
(Score: 1) by anubi on Thursday December 03 2020, @02:00PM (6 children)
Thanks. Quite interesting.
Inexpensive and simple microprocessors have made it possible to make some really unusual custom designs.
Talking about inductance, a radio amateur, Neil Hecht came up with a quite nifty scheme for a simple technique for measuring inductance.
https://www.mtechnologies.com/aade/lcmeter.htm [mtechnologies.com]
Just for what it's worth. I found his research insightful. It's not particularly fast, but by taking advantage of how precise a microprocessor can measure time intervals, I was able to make some inexpensive yet accurate position sensors that are quite resistant to environmental factors.
I am trying to build stuff for the small farm. Arduino based so the farmer can maintain the thing without being held hostage to terms, conditions, licensing, monthly fees, and DRM enforced ignorance.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 1) by anubi on Thursday December 03 2020, @02:32PM
Whoops. No schematic.
https://pic-microcontroller.com/very-accurate-lc-meter-based-on-pic16f628a/ [pic-microcontroller.com]
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by JoeMerchant on Thursday December 03 2020, @03:26PM (4 children)
Yeah, stuff like this: https://www.freightfarms.com/ [freightfarms.com] is very attractive, except for the lock-in style software subscriptions, etc. I think that the power of open source really needs to be applied to reproducible farming techniques like containers. $2 per quart locally sourced high sugar and flavor strawberries and similar goodies are very possible, if people can succeed in marketing them.
🌻🌻 [google.com]
(Score: 1) by anubi on Friday December 04 2020, @03:05AM
Here's another one
https://farmhack.org/tools [farmhack.org]
I intend to involve myself here when I get my act together.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 1) by anubi on Friday December 04 2020, @03:12AM (2 children)
Oh, Incidentally, the main reason for my Arduino bent is OPEN SOURCE. I hate "terms and conditions" to the end user with a purple plague.
This is all about sharing technology.
Take it, do what you will with it, and if you made it better, let the rest of us benefit too.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by JoeMerchant on Friday December 04 2020, @03:35AM
In my opinion, an open (source) container farming movement should hit critical mass much faster and bigger than any for-profit commercial operations are capable of, once the barriers to entry get low enough.
Container: $5K delivered
Insulation: $3K (spray on)
Interior framework: $1K - 2x4s should do most of the work quite well
Power: can be solar (up front investment with payback in a couple of years or less), grid or most likely hybrid.
Water: should be minimal / largely recycled as compared to open farming systems
LED lighting: figures I read ask for 40W/square foot, so a ~300 square foot container needs ~12KW of LEDs, which might run $1 to 2K
So, anybody with $15K, a very little land and the time to put in the work should be able to run a container farm, as opposed to $115K+ for the Freight Farm commercial solution. The real trick is getting effective information sharing going on among the builder/farmers. Once the open community gets 2-3x as many active contributors as a typical commercial operation has, I think you've got a sustainable revolution going on.
🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Friday December 04 2020, @03:37AM
By the way, I respect the Arduino choice, but find myself firmly planted in the Raspberry Pi camp. When you can get a Pi Zero with WiFi & Bluetooth for $15, why mess around with anything less powerful?
🌻🌻 [google.com]
(Score: 2) by dry on Monday December 21 2020, @03:18AM
The 6502 wasn't RISC, though it was simple. RISC is supposed to do an instruction a cycle, consider some 6502 instructions.
LDA $0008
LDA $08
LDA $08,Y
all taking different number of cycles, 3,2 and 4 IIRC in the above example, and I'm probably not remembering correctly.
It did run about 4 times faster then the 8008 so a 1Mhz 6502 was about equivalent to a 4Mhz 8008.
(Score: 0) by Anonymous Coward on Thursday December 03 2020, @02:17AM
Religion is like that. I think "Byte" articles of the time talked RISC and CISC, and found there was not one true savior. The right tool for the job. The huge instruction set for the M1 must be a nightmare to try to remember, and I'd fear they'd deprecate some and canonize others, between releases. Certainly couldn't write assembly without code completion and an incredible text editor.
I figured I'd be down-modded for that dig at "JM." That was the point of doing it. I'm not by nature like that. It's too bad when somebody is over-modded when logged-in, while another who might have more to say, can be modded to oblivion for being an AC. Nothing personal.