2023 -- 2022 -- 2021 -- 2020 -- 2019 -- 2018 -- 2017 -- 2016
A new article is out: A Fast Image Scaler for ARM Neon.
It features a completely new Neon implementation of a Lanczos-2 scaler in C and intrinsics. The old ARMv7 Assembler version is updated. Based on the theory presented in the 2018 article Exploiting the Cache: Faster Separable Filters.
We're not just banging rocks together here at Igno Labs!
I've been blowing dust off some old and new ARMs. (Well, they're usually from Sjur's bag of holding.)
The Xavier is running, Sjur's Pi 3 Pi 2 hasn't melted yet, the Nano is around here somewhere,
and a Rockchip is stuttering along with that
stupid piece of shit that doesn't fucking work [youtube.com]: Android.
Long story short: I've been trying to update the old ARM Neon Assembler image scaler for classic ARMs and make an improved
version for modern ARMs. Should be ready soon. Right now, it's down to a compiler problem. Really. I did see that one coming.
Casey Muratori has published an interesting article called Performance Excuses Debunked [computerenhance.com]. Here's a quote from the introduction:
Whenever I point out that a common software practice is bad for performance, arguments ensue. That’s good! People should argue about these things. It helps illuminate both sides of the issue. It’s productive, and it leads to a better understanding of how software performance fits into the priorities of our industry.
What's not good is that some segments of the developer community don’t even want to have discussions, let alone arguments, about software performance. Among certain developers, there is a pervasive attitude that software simply doesn't have performance concerns anymore. They believe we are past the point in software development history where anyone should still be thinking about performance.
Though I am a staunch supporter of writing everything in Assembly language, I completely agree with him. Gonna print out a copy and keep it in my briefcase for the next time some dingwad claims code performance is not important anymore.
Sjur was interviewed on the Norwegian radio show Nitimen today. He talks about rollerblading, turning 50, 3D graphics, and programming in C. Among other things.
Listen to the entire show here [radio.nrk.no].
(It's a rather long show and I can't figure out how to link directly to the segment or fast forward. Hmm. We have Top Men [youtube.com] working on it!)
Sjur got some new old toys in the mail! An AOC battery-powered screen and NVidia Jetson Nano Developer Kit [sparkfun.com]. It's a cut-down TX1 with 128 GPU cores and 4xA57, integrated cooling, 10W, at a price of just 149 dollars. Time to build a killbot [en.wikipedia.org]! We hooked it up for a test run:
I recovered some old images during the weekend.
From 2018: I rendered the last fractal video [youtube.com] that uses the DFA algorithm, smooth coloring and 32/64 bit CPU/GPU switching on the fly on a remote TX2. Sort of. The axeman was making his way to my office, so I had to wing it: Just start more processes rendering frames spaced 6 apart and hope nothing catches fire. The Denver cores managed to stay ahead of their game. Fun times.
From Xmas 2017: The Xmas Demo running live on prototype TX2 hardware:
From Xmas 2015: Quake on prototype TX1 hardware. RayMan on T150MXP on the left:
More old recovered images from the TANDBERG and PCTVNet days. Warning: Super low quality shots from 1999-2006.
The Norwegian version of Real Programming has received wide coverage in the Norwegian digital press lately. It's been hilarious: Lots of people meaning a lot about a book they have never read. I've quoted some of those articles on the (Norwegian) book page, so you can have a laugh too.
What's not hilarious is that DNB's technology director Nicolay Rygh claims that it's ok to copy code from StackOverflow and call it your own: English by Google Translate, original Norwegian version [kode24.no].
Source code licensing is a serious matter. I sincerely hope that this is not the official stance of DNB. DNB happens to be the largest bank in Norway.
I'm taking steps to improve source code visibility. Most of the code salted down in zip archives should be browsable soon: The browse button will show source files that are not automatically generated. I'm also reviewing licenses to make sure they're correct and readily available. That means updating the comments at the start of several source files.
It has been brought to my attention that some readers seem to have misunderstood the writing style used in Real Programming: We use black humor, sarcasm, and exaggerations to drive our points through in an entertaining way. It should be obvious after reading the back cover, but obviously it wasn't. (It should also be noted that "obvious" is one of the most frequently used words in the book. Obviously.) To remedy that, I'm adding some warning labels. The code can still be read for free without being exposed to our acerbic writing style.
Kode24 has an article today about our book and methods. Kode24 is one of very few Norwegian-only programming news sites. Have a look if you can read Norwegian!
Dårlige utviklere tror jobben er ferdig klokka fem [kode24.no]
Codon: It never ends, this shit [youtube.com]
I'm not gonna link to it since I'm not gonna promote it more than necessary. Check out some of the popular tech news sites on the interwebs, or scoot over to Github if you missed it.
Here's what they claim in their code pit:
Codon is a high-performance Python compiler that compiles Python code to native machine code without any runtime overhead. Typical speedups over Python are on the order of 10-100x or more, on a single thread. Codon's performance is typically on par with (and sometimes better than) that of C/C++.
One of the persons behind Codon was also behind Halide. Halide was an earlier "faster-than-C" programming language. I published a critique of their rigged example code and suspicious test equipment back in 2012: A look at Halide's SSE2 3x3 Box Filter. The subject was revisited in the book Real Programming. Get the chapter freely here: Chapter 7: Research is Hard.
Now, 11 years later, they're at it again. Claiming that some new programming language or interpreter or "compiler" is faster than C is like claiming it runs faster than the CPU. So, by reduction, a multiply should take 0 cycles, or maybe -1. I hear they're also working on a rocket that goes faster than the speed of light and a car that runs on willpower.
There are no shortcuts in programming. I wonder what they'll come up with in 2034. No, I don't care. Never mind.
Today marks the two year anniversary of the launch of Ekte Programmering, the initial Norwegian version of Real Programming.
To mark the occasion, we have decided to release Real Programming Condensed (PDF, 368KB): A 10-page summary of the book. Read it, send it to friends, copy it, and quote from it.
Happy new year! It's been a fun 2022 with the launch of the new Xmas demo, the remastering of the previous Xmas demo, the guest lecture at the University of Oslo, Real Programming (the Norwegian version) sneaking into the National Library of Norway (it's a mandatory optional process which requires submitting three copies, so not that hard, but it sounds cool), the rebuilding of the lab in the new offices, and the arrival of the NVidia AGX Orin Developer Kit. We also had some (professional) fun at Huddly where we did top secret stuff involving their excellent cameras.
Stay tuned for more awesomely great stuff in 2023! (May be considered regular stuff in some regions)
