A similar project is rr[0], which is freely available. Like you said, I find that reversible debuggers are a huge improvement over regular debuggers because of the ability to record an execution and then effectively bisect the trace for issues.
Unfortunately I haven’t had the time to do a proper benchmark, and the fpng test executable only decodes/encodes a single image which produces very noisy/inconclusive results. However, I’m under the impression that it doesn’t make a large difference in terms of overall time.
fpnge (which I wasn’t aware of until now) appears to already be using a very similar (identical?) algorithm, so I suspect the relative performance of fpng and fpnge would not be significantly impacted by this change.
Not sure if any of these would result in meaningful performance gains, but a few ideas I had:
* An avx96/avx128 version, which requires more care than avx32/avx64 because you will overflow a 16 bit signed number if you simply extend the coefficient vectors from 0..32 to 0..96/128 (e.g. 255*96 + 254*96 > 32767), but looking at it now, I realize you shouldn't actually need more than one 0..32 coefficient vector.
* The chunk length could be longer because there are 8 separate 32 bit counters in each vector, which can be summed into a uint64_t instead of a uint32_t when computing the modulo.
* As you said, aligning the loads and deferring the `_mm256_madd_epi16` outside of the loop. For deferring the madd specifically, using two separate sum2 vectors and splitting the `mad` vector into two by using `_mm256_and_si256(mad, _mm256_set1_epi32(0xFFFF)` and `_mm256_srli(mad, 16)` which should improve upon the 5 cycle latency hit incurred by the madd.
Plus I am sure there are many other opportunities to optimize this I have not thought of :)
You can debug programs that ran in the past using debuggers like rr[0], which support both recording execution for later debugging, or stepping backward in a running process.
#3 really resonates with me, writing about topics that I think I know well enough to share online often reveals gaps in my understanding and new insights.
I used to think that application was the best way to fully understand a topic, but I think writing is equally important and effective.
* Solidify my knowledge in a given topic (the best way to find out how well you really know something is to try to teach it)
* Improve at technical writing
* Create reference material that will be useful for myself (which may be useful to other people)
While it’s certainly nice to see that others visit my sites, it’s not the primary reason that I continue to produce content. However, knowing that it’s public, even if it’s possible that nobody will see it forces me to a higher standard.
I also just happen to enjoy writing about things I am passionate about, after thinking writing wasn’t for me after working on countless overly restrictive school essays.
edit: I also use it in an attempt to create the resources I wish I had when I was researching something for the first time. Many topics I find myself interested in can be hard to approach due to requiring some area of math I am not familiar with, but I feel I can explain in a simpler way compared to the encyclopedic descriptions, lecture notes, etc available online which assume some level of domain knowledge.
I think they have the same issues as any other popular science publication, where they are trying to tiptoe between making it palatable for a general (math/science inclined?) audience and people familiar with the field, and end up in an awkward middle ground.
While I'm not a massive fan of their writing, they cover quite a few interesting topics. I generally find clicking straight through to the paper/research they are covering is a much better use of my time.
Probably the most common way people interact with Tcl is through python, ironically. Tcl has a GUI library called Tk, through tkinter, available as part of the python standard library.
Outside of Tk, Tcl pops up in a couple of odd places, usually as part of some testing system (expect(1) and SQLite use it) or build system, though use has fallen off quite a bit since the 1990s.
Placing somewhere between a lisp and shell, it's incredibly effective as a language for gluing things together and creating DSLs, and is fairly easy to embed in a manner similar to Lua.
Definitely not a perfect language, but one that I find extremely comfortable to work in and iterate quickly for certain projects.
Antirez's blog has a pretty concise explanation of Tcl's features and what makes it special:
Wow, that's held up really well for being a couple of decades old. I really like the 2 column layout, makes it really easy to skim sections.
The format of your machine learning notes is also nice, I like the loose structure of it.
The colorscheme is also pleasant, nice to see something that isn't the typical light/dark mode, though you may want to change the color of your copyright notice though, it has very low contrast with the background.
Yeah, I feel similarly. I think one of the major issues is that niche forums seem to have disappeared almost entirely, and most people discover new pages through through a couple of fairly large, impersonal, content aggregators, so you see this sort of personal "web 1.0"-esque content much less often, even if they still exist.