5,190 karma · joined May 19, 2011
Research interests: programming languages, compilers and runtimes; parallel, distributed and high-performance computing. Feel free to contact me (see about page below) if you have interesting problems to talk about.
https://elliottslaughter.com/
Contact: https://elliottslaughter.com/about/
[ my public key: https://keybase.io/slaughter; my proof: https://keybase.io/slaughter/sigs/pfzdOL11OUYKphzUo2UqlDmZz37F1iYPq7omhhQtgjM ]
If you could only drive electric-based cars around your own neighborhood, the usage modes would also be entirely different and they never would have taken off either. (As, case in point, did effectively happen in the era of electric golf carts. It wasn't until they got real cars with real car range that things were comparable enough to challenge the status quo.)
https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
Thanks for the suggestion.
The optimal size will depend on the application. It's certainly reasonable that in some applications, many/most strings would be under 24 bytes and thus the small string optimization in many of these implementations would be beneficial. Perhaps in some other application strings are closer to 32 bytes (or something else) and then a larger stack size would be warranted. And in yet other applications, strings are large and no small string optimizations will make any difference, and if anything will slow the application down with unnecessary bookkeeping.
I do find it surprising that none of the implementations in the various comments linked in this thread seem to provide user-tunable sizes; or at least I haven't seen it. Because I can certainly imagine cases where the optimal size is > 24.
For context, I write over 100k words a year. That's something like 150 pages depending on how you format it. This includes both technical documents (which I mainly do in Latex) and more traditional long-form writing (which I do in Markdown).
For technical documents, formatting is very much a key part of the presentation, so I want to see the markup. I mainly use Emacs and I render the PDF from the terminal when I want to see it. Fidelity to the final result is essential, so I don't bother with Latex IDEs (unless I'm doing collaborative editing on Overleaf).
For my long-form writing, I want the markup to get out of the way. I use Markdown because it's simple and portable and generates a large number of formats (via Pandoc); that does NOT mean that I want the asterisks and hash signs and so on staring me in the face. Also, frankly, it's just easier to write when the text looks pretty. For most of this writing I write in Typora (with a nice variable-width font), and then edit in Emacs with the generated PDF side-by-side.
Why bother with Markdown at all? Because Word ultimately gets in the way of me producing nice documents. The fact that I can move my cursor to see exactly what the markup is, and that this markup is simple and straightforward and maps well into what I'm trying to generate, helps me focus on content and avoid distractions. Word has far too many knobs, far too many ways to do something that looks visually correct but generates the wrong markup (especially when you're going to do post-processing in some other tool), and really hinders refactoring (when you need to make global style changes). So I use Markdown, but again, that doesn't mean I want markup staring me in the face.
I'm not sure why people are so incredulous that this is a desirable goal? I mean it should be pretty obvious that the apps would not exist if there wasn't a market for it, so clearly I'm not the only one who feels this way.
https://en.wikipedia.org/wiki/Fat_tree
https://www.cs.umd.edu/class/spring2021/cmsc714/readings/Kim...
I'm sure there are innovations here, but most of this has been standard in HPC for decades. (Fat trees since 1985, Dragonfly since 2008.) This is not new science, folks.
1. Create a private repo R
2. Create a private fork F of R
3. Push commits to the fork F
4. Make R public
So basically, if you ever intend to open source anything, never do it to an existing private repo. Always start a from-scratch repo to be the root of your new public project.
https://github.com/emilk/eframe_template
Demo of an application built with Trunk (this is a profiler for a distributed runtime system):
https://legion.stanford.edu/prof-viewer/?url=https://sapling...
In the case of these abstraction layers, then it would be the responsibility of the abstraction maintainers (or AMD) to port them. Obviously, someone who does not even use CUDA would not use HIP either.
To be honest, I have a hard time believing that a truly zero-effort solution exists. Especially one that gets high performance. Once you start talking about the full stack, there are too many potholes and sharp edges to believe that it will really work. So I am highly skeptical of original article. Not that I wouldn't want to be proved wrong. But what they're claiming to do is a big lift, even taking HIP as a starting point.
The easiest, fastest (for end users), highest-performance solution for ML will come when the ecosystem integrates it natively. HIP would be a way to get there faster, but it will take nonzero effort from CUDA-proficient engineers to get there.
Don't believe me? Include this at the top of your CUDA code, build with hipcc, and see what happens:
https://gitlab.com/StanfordLegion/legion/-/blob/master/runti...
It's incomplete because I'm lazy but you can see most things are just a single #ifdef away in the implementation.
My experience is that the persistent people I know have at least some degree (and often a large degree) of internal motivation. They do things because the process of problem solving is rewarding in and of itself, and/or they have some intrinsic motivation about solving the problem. They are not out to please anyone else except themselves.
Maybe no one is purely 100% internally motivated. But my experience is that the more persistent people I know generally have a higher percentage of internal motivation. In contrast the people who give up more easily generally have a lower percentage of internal motivation; if they really only care about the external reward, it often turns out there are lots of ways to do that, and many are shorter than solving "hard" problems.
alias: Elliott
interests: science fiction, mental health, programming (of course), writing, and an eclectic assortment of other topics; happy to talk about just about anything
language(s): English
link to something you think is cool: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
contact info: run the program at https://elliottslaughter.com/about/ or see my profile for Keybase (can be used to bootstrap Signal if you want)Not to be pendantic, but you can't you achieve motion blur by blending frames? That is, shoot at 1/240 and either average or add 10 frames together in an overlapping sequence to get 240 FPS with motion blur that looks like 24 FPS?
I'm only half convinced about lighting. Certainly, if a great deal of light is already required, then running a faster shutter speed means you need more light. That's basic physics. But I've been doing still photography indoors, with horrible lighting, and often I don't need to shoot any slower than 1/90 or so (and often can't, depending on the lens I'm using, since I shoot handheld). Maybe I'm using a larger aperture? Not sure what gives because with modern digital camera bodies, sensors have gotten really, really good.
Can you explain this?
Each frame is a effectively a still taken at some shutter speed. Suppose you shoot at 1/1000 shutter speed and you're comparing 60 vs 120 FPS. In theory you get twice as many frames at 120 FPS, but every other frame should be identical to what you'd capture at 60 FPS (in a hypothetical world where you can position two cameras simultaneously in the same physical space).
I just don't get how changing FPS influences lighting unless you're making an assumption that FPS and shutter speed are entangled somehow. But I don't see how that fundamentally needs to be true except at the very slow end of shutter speeds.
https://global.honda/en/common/content/dam/site/global/innov...
Kranner also intentionally set up his referral network to filter out the lower end of the spectrum of cases, such that he missed what Asperger has correctly identified before him: that is, that it's a spectrum.
Being a spectrum means that there is an extreme end where things are really, really difficult. I'm sorry to hear you're experiencing that, but that's not to say the spectrum isn't real or there hasn't been a battle to get to the point of recognizing that it exists.
As to the GP's comments specifically, NeuroTribes provides a lot of evidence that searches for autism "cures" have almost universally hurt autistic people, and I mean this is a very practical, and frankly horrifying, sense, not in the "my feelings are being hurt" sense. The piercing irony of a lot of these cases was that Kranner's own follow up to some of his methods indicated that his own techniques were actually making children's lives worse, not better. Some of the children who did the best were frankly just left alone---which says a lot about what we've done for them.
So, I don't know what the answer is, but I think it's worth being at least aware of the history, because a lot of it is frankly really dark.
Overall, combinators (almost by definition) have the property that you can plug anything into anything else. Haskell encourages a "zero-point" style where you don't even name the parameters (this is sort of the point of parser combinator libraries) and provides a bunch of fancy operators to glue them together in various ways.
I think the mistakes I was making were mainly in just gluing the combinators together in the wrong way. It's not that the grammar was ambiguous, I just messed it up.
You could say some of the same things about CFGs, and I guess that's true at some level. But in my opinion the syntax is more obvious and you don't usually spend time squinting at the syntax to remember how $ works or what order things execute in. And like I said, with parser combinators, there is no feedback (because everything compiles, more or less), so the only way to tell if it's working is to run it, which is a very un-Haskell-like experience.
However, I also think that there is a legitimate point here. Which is that parser combinators, even in languages like Haskell, are shockingly tricky to use correctly. In particular, they violate the usual Haskell principle that "if it compiles, then it will probably run correctly". Having written multiple parsers in multiple languages with multiple parsing frameworks (including direct recursive descent), using Parsec in Haskell was the only time I had to write a test suite for the parser specifically. And that's because there were so many footguns that I was repeatedly making mistakes despite the fact that this was a port of a parser I'd already written (and therefore, ought to know backward and forward). (For the record, this was not my first Haskell project either, which is why I was so shocked it went so poorly.)
I'm sure it's possible to make mistakes in CFGs too, but practically speaking I can't remember running into that situation myself. Whereas with Parsec I ran into it repeatedly.
Re-reading your comment above, I had missed that you were assigning the output of the hash function back into the state. I.e., something like:
state = initial_seed
def random():
state = hash(state)
return state
seq_num = 0
def random():
result = hash([initial_seed, seq_num])
seq_num += 1
return result
For what it's worth, I did a (very informal) comparison of MurmurHash3 vs SipHash when I started my approach and found that MurmurHash3 (despite being advertised as passing the avalanche test) gave very statistically biased results. Something that should have generated a uniform distribution definitely did not. Whereas when I tested SipHash the output looked (at least to an untrained eye) essentially indistinguishable from a true random source.
Your parallel comment seems to indicate that there isn't a lot of great practical reading on this topic; I don't suppose you've seen a discussion anywhere going through anything like the approaches above, and whether there is a way to do it "properly"?
Given this is 2020, I'm guessing you probably already solved this one, but this is something I had to do for a concurrent fuzzer I wrote recently.
Basically my solution is to make SipHash the PRNG. The way this works is you make a tuple of your seed and any other information you want to hash (at minimum, a "channel" number, so you get different streams of random numbers, and a sequence number). You hash the tuple and increment the sequence number and return.
Because it's literally just a hash function, it's easy to reason about its properties: same input in, same output out. As long as the hash function is high enough quality, you avoid bias in the output even when the input has low entropy (thus why I chose SipHash).
There's an Apache-licensed implementation here for anyone who cares. My implementation has streams inside each channel associated with hashable objects, just to make it easier to subdivide the channels.
https://github.com/StanfordLegion/fuzzer/blob/master/src/det...
https://github.com/StanfordLegion/fuzzer/blob/master/src/det...
https://github.com/StanfordLegion/fuzzer/blob/master/src/det...
I could be wrong, but I don't think PC chairs are paid, by anybody. Maybe they get free housing at the conference, but this is more of a consolation prize given the amount of work involved.
Certainly the rank and file PC members don't get anything. I was on one PC mailing list where one of the organizers accidentally let slip that (some) organizers get free housing, and there was a big uproar in the PC. None of us get anything like that.
So this is literally a system where the expert reviewers get nothing, and even the chairs in charge do it nearly for free. What part of this needs to cost money?
The peer review comes from the community. The exclusivity and filter comes from the community. Even the funding comes from the community, because community members pay to go to the conference.
What the publisher does is, as GP noted, mainly to host PDFs on a website and make sure they stay up. That costs something, but nothing like what the licensing fees for these services are (or the so-called "open access" fees that we now pay).
The modern version is two's complement. It still has a sign bit, but negating a number involves more than just changing the sign bit since the representation is modular.
1. I usually have Bluetooth turned off on my phone for security reasons, will this respect that?
2. While Google tells us that the information will be encrypted, it seems to me that having your phone constantly pinging on Bluetooth (if this cannot be disabled per #1) is still a security/privacy leak in some situations, and something users should be aware of.
At any rate, I wanted to see this get more discussion before it goes live on a bunch of devices.