Premature optimization is the root of all evil

[vak]

Here is a more detailed elaboration.

1. Make it work.
2. Make it right (the code is readable [uses intention revealing names] and every idea is expressed once and only once).
3. Make everything work.
4. Make everything right.
5. Use the system and find performance bottlenecks.
6. Use a profiler in those bottlenecks to determine what needs to be optimized. See Profile Before Optimizing.
7. Make it fast. You maintained unit tests, right? Then you can refactor the code mercilessly in order to improve the performance.

-- Guillermo Schwarz

Comments

[sobriquet9]

I considered FORTH for that use and decided against it. C with inline assembly resulted in code that ran faster on the hardware that we had at the time, but more importantly the standard library was way better.

[juan_gandhi]

I find this ridiculous. My Forth implementation of FPP was about 40% faster than Borland's C implementation - the "standard library". The reason being, in Forth, using macros, you can manipulate the contents of registers semi-automatically, the knowledge spreading over a thousand lines. You can't optimize your C code like this; your scope is just several lines, and your manually-written assembly scope is probably just dozens of lines. You need macros to manage it better.

Of course, in small solutions, like `strlen`, it does not matter in small functions (saying it as I'm the one who made Borland's `strlen` about 4 times faster.)

[sobriquet9]

You're arguing with a stopwatch. There was an interrupt triggered by hardware every 20 milliseconds. Interrupt handler then read accumulated data from the sensor, processed it, and updated display buffer directly. C code could do it in time, after I hand optimised it to use string operations that were supported by the CPU (but not the compiler). FORTH was not even close.

And it was much easier to write the rest of the logic (polling the keyboard, user interface, calculating necessary metrics) in plain C, using the expansive C standard library.

[juan_gandhi]

What I read here:
- you were. more comfortable with C than with Forth
- your Forth was not good enough to write fast code
- you didn't have enough experience with Forth to write ui and calculations in Forth.

Ok, but it's not the problem with Forth. Once we two, me and my colleague, had snapped together a drilling site simulator (including ui, sensors interactions, formulas interpretation (formulas entered by the user). We spent one week on it. Before that we spent three weeks writing a dedicated Forth system and drivers, all in Forth. And of course our code was pretty fast.

But again, we already had over a year of Forth experience, with our one Forth core, and with an experience of its industrial use (in drilling control).

What I want to say, that it's not about Forth at all, it's about one's tastes and experiences. Those days I could use C, and I've always respected C.

[sobriquet9]

My FORTH was as bad as my C or my assembler, but it does not really matter because the operation in question was so simple. There isn't that many ways to copy from one memory area to another. Whichever language you use, if your compiler does not convert the loop to string opcode and does not give you ability to do so, it's not going to be as fast. Back then there was no speculative execution so I could look up the number of clock ticks it would take from the opcode table, and even see read operations with oscilloscope to confirm. And it wasn't a small difference, it was the difference between a device that worked and device that didn't.

[juan_gandhi]

A more open mind may help solving problems.