2021-10-19 02:45:15 <veltas      > MrMobius_: It's counter-intuitive but mostly true. Python is just as fast as C if all the critical paths are being done in a properly optimised library, i.e. numpy
2021-10-19 02:46:01 <veltas      > And likewise FORTH (which I'd like to think is faster than Python) is just as fast as C if you actually care about optimisation. If not, then C will run faster, but you didn't care anyway
2021-10-19 02:46:52 <veltas      > Because there's always a tiny part of the code that is critical, that needs to be optimised. Unless your choice of algorithms is bad
2021-10-19 02:48:27 <veltas      > Yeah the end result might always be 1-2% slower because the non-critical parts are running in FORTH rather than C, but that is not a significant difference
2021-10-19 09:25:16 <MrMobius_   > veltas, the numpy example is not an accurate comparison. numpy is written in C and not Python. there is no possible way to rewrite numpy in Python that would be anywhere near as fast. in the same way, there is no way to write Forth anywhere near as fast as C
2021-10-19 09:25:39 <MrMobius_   > the equivalent would be writing words in pure assembly or C then jumping to them from Forth. i agree that that would be as fast
2021-10-19 09:27:08 <MrMobius_   > so if you choose the ideal algorithm and optimize as much as humanly possible, Forth will be dramatically slower than C unless by Forth you mean rewriting the critical code path in assembly
2021-10-19 09:29:32 <MrMobius    > im not anti-Forth by the way. i just think you should be realistic whether you hate the language or like me enjoy playing with it
2021-10-19 11:04:57 <veltas      > MrMobius: I don't take criticism of FORTH as dislike, certainly I've got a lot to criticise as well
2021-10-19 11:05:12 <veltas      > The comparison I'm making is about writing critical parts in assembly
2021-10-19 11:05:47 <veltas      > If we restrict to only using the language (and IMO that means you may not use intrinsics either), then generally that means you don't care about performance
2021-10-19 11:06:23 <veltas      > If you are willing to optimise critical code in assembly or with intrinsics then it stops making as much difference which language you use
2021-10-19 11:06:57 <veltas      > That's why I mention numpy, where the hard critical parts are done in C (or assembly, actually, since so many intrinsics are probably used that it will be *faster* than a dumb C attempt)
2021-10-19 11:07:38 <veltas      > And intrinsics don't count as C unless you count FORTH assembly/CODE words as FORTH, because they're both about as usable in their respective languages
2021-10-19 11:08:28 <veltas      > I do generally buy into "it's the programmer, not the language, that counts" for things like this. Of course there are situations where that breaks down
2021-10-19 11:37:06 <MrMobius    > "it's the programmer, not the language, that counts" - that is a good point but only as long as there is room to optimize which you may quickly run out of especially in embedded. then the language absolutely does count
2021-10-19 11:38:28 <MrMobius    > ya doesnt much matter what language you use if youre willing to write your own assembly but this is why you should be picking C over forth if you need performance
2021-10-19 11:39:13 <MrMobius    > since the assembly generated will probably be about as good on most architectures as what you handcraft to go along with your forth code
2021-10-19 11:39:52 <MrMobius    > assuming you can write C code faster and with less mistakes than you can write assembly
2021-10-19 12:37:33 <veltas      > So on the main platforms I use, x86 and other normal systems platforms, C code does not generate high-performance code. Because to get close to theoretical throughput you generally need heavy vectorisation, the compiler can't do that for you.
2021-10-19 12:38:18 <veltas      > I don't know what situation's like on embedded but I'm used to C compilers letting me down
2021-10-19 12:38:39 <veltas      > I think in embedded the issue is usually more about code size than the 'performance' of individual code snippets
2021-10-19 12:45:07 <veltas      > The sort of stuff being done in numpy is probably like 20 to 100 times faster on a single core than the equivalent optimised C code (not counting intrinsics)
2021-10-19 12:45:43 <veltas      > And when your program spends 99% of its runtime in that code, it doesn't matter if it's C++ or PHP calling it
2021-10-19 13:33:05 <MrMobius    > veltas, probably of the majority of code cant be vectorized. for most situations, the C compiler does produce ideal code on x86
2021-10-19 13:34:05 <MrMobius    > and no it isn't about code size. you can get enormous amounts of flash for pennies. when you have chips that only work at a few mhz then performance can be very important. you cant waste 95% of performance on overhead like you can on x86 without noticing
2021-10-19 13:34:38 <MrMobius    > what do you mean about numpy being faster? are you saying it's written in assembly and is faster than C?
2021-10-19 15:16:34 <siraben     > probably the use of vector instructions that makes it really fast
2021-10-19 15:17:10 <siraben     > on modern hardware things like cache hits and vectorization matter more for performance than hand-tuned assembly (not mutually exclusive of course)
2021-10-19 15:17:46 <siraben     > veltas++