this post was submitted on 12 Nov 2023
99 points (93.0% liked)
Technology
58303 readers
11 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Seems interesting but it has the stink of "buzzword marketing" all over it. The example given in the article about using it for wake words is just using a microphone connected to the device. Microphones and speakers are both analog devices that all digital phones have already. Also the fact that it's an IC that's programmable leads me to believe it's not analog at all, or else how can it be programmed?
I also thought it was funny to talk about environmental damage from all these digital sensors and then using thermometers filled with mercury as an example of an analog sensor. Mercury is a heavy metal and extremely toxic to most lifeforms, which is why we don't use it in thermometers anymore.
Lots of buzzwords indeed, author apparently doesn't even know what a smart sensor is, as they described a regular sensor in their first paragraph.
That said, you can absolutely program analog ICs, such as by using a Field Programmable Gate Array instead of just your regular Gate Array (your usual, 'stupid' IC). Though, while a random IC might cost you less than half a dollar, a FPGA will cost you around 100$ for a simple chip.
On the other hand, skipping any GPU or CPU and their limitations by clock speed should speed up the AI considerably, though parallel programming (not concurrent programming, and not multi-core "parallel" programming either) is much harder and comes with almost no safety when compared to serial programming.
What do you mean by "almost no safety"?
Edit: OP edited his comment to clarify. He only had "parallel" without the "no multi-thread/multi-core" bit.
A CPU is a very complex gate array which handles bothersome tasks such as synchronization (run conditions) and memory access, and presents you with a very limited set of instructions. All serial programming builds upon this very limited set of instructions, and the instructions have been thoroughly tested over the past 6 decades.
Not to say that CPU architecture or microcode is fail-safe, but the chance of your computer blue-screening because of a failure of your CPU is rather small.
Now, parallel programming (the low level variant, not the hijacked definition) is the art of "wiring" those gate arrays. A CPU is actually made using parallel programming, so all the safeties it presents for serial programming will not be present in parallel programming, as parallel programming does not use a CPU.
EDIT: the above is of course simplified, there exist multiple architectures, collected into more common instructions sets such as amd64, armhf, arm64, etc. but even the most barebone processing unit contains a lot of securities and nicities that parallel does not have.
You lost me at parallel programming not using a CPU.
Perhaps you mean that it uses the lower levels of the CPU.
But regardless, I see that you mean that parallel programming involves almost no safety at the hardware level. Which is a weird thing to say since "serial programming" at the assembly level also offers no safety (e.g. if your program runs at ring 0.)
I think you are misunderstanding me. Are you perhaps thinking about multithreading or multi core? Because some people have also started calling that "parallel", even if it is nothing like low-level parallel.
A CPU does not build upon a CPU, a CPU builds upon transistors which are collected into gates, and which can be assembled into the correct order using parallel programming.
EDIT: as an example, you do not actually need a computer to parallel program. Get yourself a box of transistor, some cable, and a soldering iron, and you can build some very rudimentary gate arrays, like a flip-flop.
This link might give a better understanding of our confusion.
EDIT 2: One could perhaps illustrate the confusion which this topic is often victim of as such:
Transistors are part of the hardware and are parallel programmed to form complex gate arrays called "Processors", which feature instruction sets used by machine code, which is made using assembly, which is called "serial programming", which enables high-complexity operations such as multi-core "parallel" programming.
I'm talking about the former "PGA parallel programming", and not the latter "multi-core parallel programming".
I understand all that. I wrote my first 6502 assembler program in 1989 - and it was fun, by the way!
I am also aware that today's CPUs are nothing like the 8-bit CPUs of the 80s. So we're on the same page in that respect.
I understand what you're saying now. You're talking about programmable gate arrays, which is cool. But I still don't understand how "parallel programming" gate arrays comes with almost no safety compared to "serial programming" gate arrays. If you are not careful in either mode, you can introduce serious bugs in the programming.
Right, apologies for dumping it down so far, I find it hard to properly gauge the knowledge of others on the internet, and just try and play safe.
I wasn't aware that one could serial program gate arrays, as, as far as I know, the definition of serial programming is code that is governed by a processor, and which prohibits anything but serial execution of commands. So it's new to me that gate arrays can run serial code without any governance or serialization process, since gate arrays by themselves are anything but serial. Or rather, you need to synchronize anything and everything that is supposed to be serial by yourself, or use pre-built and pre-synced blocks, I guess.
Anyway, going by the definition that serial programming can only be performed using some kind of governance or synchronizing authority, that alone would be another layer of security.
As serial implies, it rid us, or lessened the burden, of those timing related issues, some of which included:
And the list goes on, but you know.
Serial also has a lot of pitfalls, and you can definitely screw things up bad, but at least you don't have to think much about clock or timing, or memory placement, unless communicating between devices or cores, and those sync problems tend to be rather tame and simple compared to intra-processor problems.
At least from my experience.
Oh if serial programming is not a thing in the electronics low level realm, then all is well. It's not news. It just doesn't exist. Apologies. I just assumed it was a thing since you said "parallel programming comes with almost no safety," and in my eyes, that implied that there existed other kinds of programming besides parallel in the context you were referring to.