Hacker News Reader

Comment by d33 | Hacker News Reader

Makes me wonder how much AI we could fit into ZX Spectrum, an old Amiga or 80386...

Not much. Even a tiny arm cortex M4, which could live in a hearing aid for a week on battery life, are often 64MHz with single cycle MACs.

Z80 I believe was something like 4 cycles per instruction and only a megahertz, so we would be talking at least 16x slower than a M4. You would need something between a 486 and Pentium to get close to the M4, and then evenn further to get to the M7. If I remember correctly you couldn't even decode MP3s in realtime until the faster 90+MHz 486.

These things are slow (by modern standards), yeah, but it was possible to get the model this far down ... how far can we go?

Must be a way to prune the nn with some reduction of quality. Probably a means to reduce the quality until it is on an Arduino and some like an anonymous video.

There was speech synethsis on the apple iie in like 64k of RAM and a 1mhz CPU.

> There was speech synethsis on the apple iie in like 64k of RAM and a 1mhz CPU.

Speech synthesis is far far far easier than parsing a human voice, especially when it doesn’t need to sound realistic (as was the case back then).

Current approach of speech recognition is about as old (maximum likelihood using WFST).

In the old papers about problem, there was vocabulary size of 64K words, because nothing was working for bigger vocabularies.

Pruning is a great idea to reduce memory usage. One thing to be careful with is that pruned matrices use irregular memory access and they might be slower as we don't have SIMD support for sparse matrix multiplication on generic CPU's (e.g. ARM) yet.

You may decompose matrix for each layer into two matrices with a bottleneck layer. E.g., A=BC (approximately) where A is MxN matrix and B and C are MxK and KxN matrices, where K is small enough.

It is done using SVD and improves speed without sacrificing memory access patterns.

Maybe it is unimportant, but I once compiled amp on an old SGI Indigo Elan. 30Mhz MIPS R4k something...

It would decode mp3, up to 256Kbps, over NFS, 95 percent CPU utilization.

I was quite surprised.

Considering the 80386 needed two clock cycles for just an INC or ADD, let alone the 12-27 needed for an IMUL/IDIV/memory fetch, I’d say an 80386 would be a bad target. While faster than most others in its time, the 386 was a rather poorly designed CPU.

Reply on news.ycombinator.com