I always felt the implication of power was a lot more valuable to US interests than exercising it, cheaper too for that matter. And even very recent history revealed that with the greatest military strength ever seen, the US cannot achieve all of its desires through force.
> "Audio modality is really challenging to comprehend because of how limited our hearing is"
Would it help to significantly lower the hearing capabilities of the AI system? At Juvoly, we always encouraged GPs to invest in high quality microphone like Jabra Speak, connected through USB. A good mic results in much better audio transcriptions, but maybe that was all for the wrong reasons?
Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted.
Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.
There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me.
It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful.
Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine.
I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!
git's mental model is very, very small, if you care to learn it. Then all the commands and their "inconsistencies" start to make sense - they operate on the model almost without any magic, and not on whatever is user's intent (it can vary a lot)
What? Subversion is by far the most complex versioning software I've ever used.
> Git has so many gotchas, bells and whistles
The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.
Subversion pre-1.5 was a nightmare. Branch merges were by convention in commit messages. To merge 20 commits from your branch, you would do `svn merge -r 125:140 /branches/my-feature` and then note in the commit message which range you merged.
1.5 made that tracking automatic but just shoved it into a metadata field that just percolated through every directory in a project.
And if someone tried to rename a core path? In the distance, sirens.
I found that doing anything even slightly unusual in Git was pretty incomprehensible until I learned its internals, and pretty easy once I did. Fortunately as you say the internals are conceptually pretty simple to learn.
Increasingly (for instance ADSP podcast [1]) those in nvidia's inner circle are advocating against writing your own CUDA kernels. (Unless that's your full time job at nvidia, that is).
That would be cool but nvidia released blackwell and still have not released unbroken kernels for sm120. Sm120 is not the data center gpu, so it doesn't get its love. So we can't depend on nvidia to do the right thing is my point unfortunately
It’s not about whether you work at Nvidia. Avoid writing CUDA kernels if there are higher level libraries that do what you need. Do write CUDA kernels if you want to learn how, or if you need the low level control, or to micro-optimize. Being able to fuse kernels to avoid memory traffic or get better specialization is also a reason to reach for raw CUDA. Just consider what’s the right tool for the job…
Writing efficient CUDA code is very, very difficult; most CUDA code is not actually good at utilizing the hardware. It is much easier to write performant code in higher level languages (and most people are doing exactly this).
That all depends on what you’re doing. Like I said, if a high level lang or lib supports and fits your goal well, then yes you should use it. I don’t know what most people are doing, but it’s fair to say that a lot of people can use a higher level language.
If you’re trying to learn CUDA, then using a higher level language is not the best approach. If you already used a high level language and found that your performance is lacking and could be better if you could fuse some of your kernels, and avoid some of the memory round-trips, then moving to something lower level is called for.
I’m suggesting it’s better to think about your goals for one minute and understand the basic choices than it is to assume there’s something that works for everyone’s goals, and higher level languages don’t meet everyone’s goals.
That advice seems like nonsense. It's like saying avoid C because you can use Python, or avoid writing a graphics engine because you can license Unreal.
can very much agree about not writing stuff like reductions yourself, unless you have good reason to.
but this sort of feels like another "implement everything with <nvidia stuff> and you'll have a great time!! (but also coincidentally get locked in even more to Nvidia hardware)"
reply