1,066 karma · joined February 12, 2013
The JS support is really weird. It's only JS 1.6 (from 2005), and had weird glitches (like loading two instances of the same device causing the first device to stop working), and I couldn't get the timing tighter than about 30ms. Ideally you could write code that runs at audio rate.
There's also "gen", which is a Max-specific scripting language that is presumably real-time suitable through a JIT. Unfortunately you need a separate Max license to use it, even the full Ableton Live Suite doesn't give you gen support. You can sorta hack around and use it by manually editing the .maxpat files (which are almost JSON), copying from a device that uses gen, but there are lots of weird glitches going this route.
A list of a few annoying things about M4L:
* Documentation is pretty sparse and/or low quality, and weirdly split into two (help and references).
* All variables are global across devices by default, local (device-specific) variables need the prefix "---", which is barely documented
* Tons of annoying UX issues, like entering an invalid value in the inspector just reverts to the old value. You can't enter an empty string for parameter values, that reverts too (you need to enter a literal ""). Certain functionality is only available depending on whether the device is "locked", so you have to lock/unlock the view all the time if you're working with e.g. subpatchers
* Abstraction is quite annoying to do. There's three different types of patches, and it's not really clear what the difference is between them. Creating subpatches and then duplicating them creates two different subpatches--changes in one are not shared with others.
* ...and a ton of other things. I have a big text document of these gripes I was intending to turn into a blog post, but haven't gotten around to it.
Maybe I'm wrong and there's better ways to do some of these things, but overall my experience learning M4L was pretty bad. If it wasn't the only way to do certain advanced things in Ableton, I'd never touch it again.
Incidentally, I browse Twitter while logged in, but the autoplay settings are "per-browser", and Firefox's anti-fingerprinting mode makes Twitter think you're using a new browser on each visit, and thus keeps autoplaying all the time without the above setting. Pretty irritating.
There's a ton of gorgeous high resolution die shots of (mostly) modern chips, all in the public domain.
I have an old, abandoned project that translates Python to C++ "from scratch", with no runtime dependencies beyond the STL[0]. It's very incomplete, and probably has plenty of bugs, but might be interesting for anybody looking for something more self-contained/embeddable. It has its own implementations of lists, dicts, etc., and a basic garbage collector.
An interesting story related to rep movsb was how the original Pentium-based Larrabee supported gather/scatter, as described in this slide deck from Tom Forsyth: http://tomforsyth1000.github.io/papers/LRBNI%20origins%20v4%... (gather/scatter info on slides 48-61, important background about virtual memory/pipeline in slides 21-28)
A summary:
The original Pentium had a very simple pipeline that could only access one cache line per instruction, and had to determine if there was a page fault early in the pipeline. This presented a problem for the Larrabee design, which needed to support gathers/scatters (which are vectorized loads/stores, and can read/write up to 16 different cache lines in one instruction). Additionally, the Pentium microcode system was quite slow, and gather/scatter performance was very important for many workloads.
To solve this, they looked at how rep movsb (which can read/write an arbitrary number of cache lines) works: as it executes, rep movsb modifies the cx, si, and di registers in place (or their 32/64-bit counterparts). This side effect actually helps keep the implementation simple, because if an interrupt occurs in the middle of the instruction, the registers keep all the state needed to continue executing after control returns to the instruction--it just keeps copying from where it left off.
So gathers/scatters used the mask registers from the Larrabee vector instructions to keep state: a bit in the mask indicates that a vector lane still needs to be read/written. The instruction is then run in a manual loop (not a microcoded rep prefix) until all bits in the mask are cleared. Interestingly, this implementation can be faster than gather/scatter in a modern AVX-512 out-of-order core: whenever multiple vector lanes point to addresses in the same cache line, those loads/stores can all execute at once; in contrast, in the big cores gather/scatter are split into one load/store micro-op for each lane, that each execute independently. And the masking isn't taken into account before the uop split, so gathering with only a single address unmasked can still take more than 16 uops (see https://mobile.twitter.com/trav_downs/status/122333322625875...)
Looking forward to that paper, too!
A one-instruction variant I've seen that gets you the negated value of the carry flag is sbb rax, rax. This doesn't depend on the previous value of rax in a mathematical sense, though I'm unsure if it depends in an out-of-order sense; that is, if it's recognized as a zeroing idiom (or rather, zeroing or all-one-ing in this case). Probably not.
EDIT: did a quick test, and sbb rax, rax etc are not recognized to be a zeroing idiom, at least on my old Haswell. So it's still one instruction, but has a dependency on the previous register value.
One method for doing this manually is to do an interactive rebase and re-order all the relevant commits to the end. You basically create a new branch that has all the other commits first, and then you can diff between that point and the branch head. With the example commits from the post, you'd order them A B D F G C E H; then git diff G H would show just the changes from C E H.
This is a bit annoying in that it needs to use the working tree to apply all the commits in sequence, and you have to manually resolve any conflicts that arise, which gets more difficult the larger and more-intertwined the commits get. But maybe it's better than nothing...
> the now-defunct "chessprogramming.wikispaces.com"
It's not defunct, it moved to https://www.chessprogramming.org
Do you have any plans to release this? I could understand if you don't want to, since it might violate fb's ToS or get blocked in some way. But certainly many others would find it useful.
From my perspective, as someone who was once on one of the Larrabee graphics teams (but not the same one as Matt), I'd agree that the programming model was a big issue. For us, even C++ with intrinsics wasn't fast enough for the most important code, since we didn't control the compiler (note that I'm only speaking anecdotally here, these decisions pre-date my involvement). So we had our own programming language that was more like Python with intrinsics, that hooked into the back end of the shader compiler (which handled register allocation and scheduling).
This probably wasn't the best call for a Larrabee programming model "for the masses" (even lots of people on the team were skeptical of it)... But damn, that was a fun project. We needed the ability to try any crazy idea we could think of, because that's the only thing that could work.
I think it's also safe to assume that, given the lead time to design an ISA and integrate it into an architecture (many years), the merging of AVX-512 into Skylake wasn't done "in a desperate attempt to give KL more software".
These slides from Tom Forsyth provide lots of interesting background on the evolution of the instructions: http://tomforsyth1000.github.io/papers/LRBNI%20origins%20v4%...
Simply put, it's to move the blue-greenish block off the right side of the grid. You clear the path by moving all the other pieces around as necessary. Each piece can only slide horizontally or vertically, depending on its orientation (they move along their longer dimension).
I'll throw in one I made for myself and never really showed to anyone. It's a clone of Unblock Me/Rush Hour, but with no ads and undo+redo support. It's only a website since I don't want to bother with app stores (I just save the page to my home screen).
https://zwegner.github.io/slidey-blocky-thingy/base.html
The puzzle variety isn't great, my generation method sorta sucks. I had started to build an exhaustive generator after reading Michael Fogleman's article[1] on it, but haven't finished.