I heard a rumor that REP MOVSB is now one of the slower ways to copy memory.
Code: Select all
grep erms /proc/cpuinfo
I suspect he is more an expert than me. A 20-fold performance improve in the speed of complicated softwares like Scratch and Smalltalk doesn't happen by accident.
I like to think so.You are stating the obvious ...
We all know that choosing the best algorithm is far more effective than any micro-optimization.
That is not so clear to me.If you have been programming for decades, the best algorithms and data structures are often readily apparent.
Who gets to do that?
Certainly as broad a knowledge base as possible. That's what a CS course at uni should be doing.
Wait a minute...Finally, successful optimizations are usually indicative of poor code to start with.
Good clean code maybe, but if the result is terrible, and unacceptably slow, then the algorithm (or something) is unsuitable.Heater wrote: ↑Thu Mar 28, 2019 6:47 pmMy Fibonacci challenge, to calculate the first Fibonacci number with 1 million digits, might have taken forever if I was using the schoolboy fibo algorithm, and the school boy multiplication. No matter how brilliant my code was. No matter if it was Python or C or hand crafted assembler. Code good, result terrible.
You’ll have to forgive me - after all I’ve only been doing this stuff professionally for 40-some years.
It does seem a strange dichotomy that the Raspberry Pi is for school children but the Raspberry Pi Forum is for the over-50 crowd.timrowledge wrote: ↑Thu Mar 28, 2019 8:11 pmYou’ll have to forgive me - after all I’ve only been doing this stuff professionally for 40-some years.
Linus Torvalds wrote:Sometimes "pi = 3.14" is (a) infinitely faster than the "correct" answer and (b) the difference between the "correct" and the "wrong" answer is meaningless. And this is why I get upset when somebody dismisses performance issues based on "correctness". The thing is, some specious value of "correctness" is often irrelevant because it doesn't matter. While performance almost always matters. And I absolutely detest the fact that people so often dismiss performance concerns so readily.
--Git mailing list, Fri, 8 Aug 2008
Therein lies a paradox. In some ideal world high level languages, compilers, interpreters make the instruction set irrelevant. However in the real world the vast majority of desktop system and servers are x86 based, whilst the vast majority of mobile devices are ARM based. Looks like the instruction set is the critical difference between these ecosystems.Compilers.
Compilers mean you really don't need to worry about the instruction set at all. So for Intel, ARM, RISC-V, the majority of people who use them don't give a flying whotsit about the ISA.
In my opinion, the free (but not open source) NVIDIA GPU libraries and the associated CUDA programming language are the main reasons NVIDIA dominates high-performance computing. For example, the current fastest supercomputer Summit obtains much of it's performance from NVIDIA V100 GPU accelerators.
Sounds like my college CS course had that down. There we were introduced to programming my means of BASIC, but a lot of the course was numerical methods and statistics along with some discussion of computer architecture, were had to get to grips with assembler....a curriculum needs to advance students beyond Python and Scratch.
I wonder if the above statement should replace the current slogan
on the official MIT page. Maybe we are all doomed, not just ARM. To be certain, it would be necessary to know how well Scratch runs on RISC-V.Scratch website wrote:Scratch - Imagine, Program, Share
Create stories, games, and animations
Share with others around the world
The part which reads