Ridiculous Simplicity Demands Ridiculous Resources

The flip side of RidiculousSimplicityGivesRidiculousResources. It's a good thing that it does, because those ridiculous resources will be needed (in many cases) to do anything useful with a ridiculously simple system.

Sometimes, the trade-off is worth it, other time it isn't.

Examples:

• RiscVsCisc. On a RISC machine, the CPU cycles can be made shorter (and the clock speed faster), but each instruction does less than a CISC instruction, so programs written on RISC architectures need more instructions to do the same work. In this case, the advantage went to simplicity, as pipelining and tractable compiler optimization proved to benefit RISC greatly.
  • Did it? The ExEightySix is still the dominant desktop processor.
  • "The advantage" here is technical, whereas desktop dominance is a business issue. RISC processors did in fact prove to be the technically superior architecture, so much so that backward compatibility is almost the only reason to consider doing CISC these days (with occasional exceptional cases for individual instructions, rather than for whole instruction set architectures, such as the widespread decision to include single instruction multiply and divide).
  • And in fact, x86 processors these days are very RISC-y on their interior, with instruction decode of the legacy CISC encoding frequently being used more to convert to the internal pseudo-RISC architecture (most especially on the Transmeta, but to a lesser extent AMD and Intel as well) than as simply the first phase of direct execution.
  • The comment above says "RISC architectures need more instructions to do the same work", which is often true (although interestingly, not universally true), but counter-intuitively those instructions do not always take up more space, depending on the CPU in question. For instance, the older 32 bit CISC Motorola 680x0 (e.g. 68020) has a large number of very fancy addressing modes, which take up sometimes a large number of extra bytes, often more than the number of bytes required to implement the same memory addressing in a sequence of RISC instructions -- and in fact, usually is at least as big (and at least as slow) as the number of bytes required for simpler 68020 instructions to do the same thing. I.e. in some cases the extra CISC features offer literally no advantage at all, and may even suffer a penalty, for both time and space, whether compared with the same CISC cpu's simpler instructions or compared with a RISC cpu's equivalent.
  • It's unclear what the original point of bringing up RISC on this page was. Technically, RISC won the battle hands-down, and could be called an example of "ridiculous simplicity". But RISC doesn't "demand ridiculous resources"; that appears to be a misunderstanding. -- DougMerritt

• ReallySimpleSyndication. Can be a big drag on servers.... Yes, but would this be reduced by ReallyComplexSyndication??

• Many minimalist programming languages. There's a name for these: TuringTarpit. The medium-to-large size languages, with lots of well-maintained libraries, tend to be more productive overall than the simple-and-elegant variety where you have to write your own networking libraries (often through a buggy ForeignFunctionInterface).

The point of this page is not to trash simplicity--OccamsRazor is still frequently good advice. Rather, the point is to emphasize that such matters are trade-offs.

---

"Rapport plans to develop a version of its current KC256 chip that contains more than 1,000 separate eight-bit processing elements. ... The Kilocore1025 ..." http://news.com.com/2061-10791_3-6057551.html http://www.technologyreview.com/read_article.aspx?id=17076&ch=infotech http://www.power.org/news/pr/view?item_key=fcd9c09211203606ccd22996702dd8426a826712

Sure, 8 bit processors are "simple". Are 1 000 of them "ridiculous" ?

---

"Indoor GPS: The No-Chip Challenge" by Frank van Diggelen, Charles Abraham Sep 1, 2001 http://uc.gpsworld.com/gpsuc/article/articleDetail.jsp?id=308334

describes GPS reciever hardware that requires a much simpler CPU (and CPU software) than traditional GPS reciever. Also, instead of the traditional complicated correlators that have all kinds of options for tweaking Doppler frequency and code offset, it uses much simpler correlators that are hard-wired for a fixed Doppler frequency and code offset.

Yet it works better (can lock onto a weak signal faster; also uses less power) than GPS recievers using traditional designs.

Instead of the traditional 24 correlators (an "early" and a "late" correlator for each of 12 satellites), it uses 16 000 correlators. Ridiculous, right?

---

But that are all hardware related trade-offs of simplicity. Any software examples?

Hmmm... well, BrainfuckLanguage is ridiculously simple. It's quite minimal, really. Therefore, according to this thesis, programming in BrainfuckLanguage should demand ridiculous resources. Oh! I think it does! So, what else might we observe?... the interpretation or compilation of BrainfuckLanguage? Yes, that also seems a simple task, but if you wish to make it run very fast (e.g. recognizing repeated addition and substituting it for multiplication), I imagine that the compiler will require ridiculous effort to write and verify.

Discussion about ForthLanguage moved to RidiculousSimplicityGivesRidiculousResources due to a misunderstanding on my part. Sorry! --SamuelFalvo?

---

I just thought about something that is mentioned by a college every now and then:

"There is no problem in computer science which cannot be solved by one more level of indirection." (OneMoreLevelOfIndirection)

(I think this could even be generalized to science at large.)

And then I just stumbled over this page here. Can the problem of simplicity be solved by another level of indirection? Sounds like a contradiction. What do you think?

{In general, concerns that are described by constraint of behavior cannot ever be solved by another layer of indirection. This includes: security, privacy, safety, ensuring correctness, performance guarantees (hard realtime, strict space requirements), parallelism and synchronization, deadlock resistance, simplicity (especially ease of comprehension), optimization, and, of course, too many layers of indirection.}

{However, a great many 'positively' stated behaviors can be solved by clever use and appropriate placement of an additional layer of indirection, dispatch and delegation, or abstraction. I do find it a valuable maxim. One typically adds: "[...] except too many levels of indirection." - perhaps representing the general inability to support behavioral constraint.}