eslaught

I've been reading about 5-10 books a year for the last 10 years or so, after having not read anything of substance (outside of school) for some years prior to that.

Since my reading time is limited, I want to read books that are really good. I have to say, quite frankly, that many books just aren't that amazing (and I'm including both traditional and self-published in this). That makes me reluctant to pick up a book unless it's from an author I already know, comes with a really strong recommendation, or just has a superb opening. If a book doesn't have at least one of those three (or ideally two), I'm just not going to pick it up.

This is all anecdata, but my point is the demand side is more complicated. Even given the competition, the vast availability of both traditionally and self-published books doesn't guarantee that quality goes up, at least in aggregate.

No, the abstractions are not sufficient. We do care about these details, a lot.

Of course, not every application is optimized to the hilt. But if you want to so optimize an application, exactly things you're talking about are what come into play.

So yes, I would expect every competent HPC practitioner to have a solid (if not necessarily intimate) grasp of hardware architecture.

Maybe open source means different things to different people?

To me, open source isn't a transaction (even one with "nothing owed" as it were), as much as a community. What I get from participating in open source is to be a part of that community. You just don't get the same interactions working on a closed-source, proprietary code, no matter how deep and rigorous your process is. Ironically, I have stronger bonds with some of my collaborators at other companies/institutions than I do in my own, and that's all thanks to open source.

The fact that some of these open source communities happen to have built world-class software that is used by FAANGs and Fortune 500 companies is cool and a testament to the power of this process. But it's also sort of tangential. And I think we're missing something when we reduce open source down to the licenses and code transfer, as if that's all it is.

It's more like you always had a disease and just didn't know it. Celiac comes to mind as a common example. I know people who improved a lot once they got diagnosed, and just never realized the symptoms meant anything before that.

I can see this if you go from site X to site Y where you're logged in on both X and Y, and you can correlate (say) the email. But if you're logged into Y (the store) but not X some random referrer, how do you attribute the conversion?

The early, cheap phase of streaming was funded on the back of overpriced, bundle cable subscriptions. I think it's underappreciated how much streaming gutted this business model. Not that it was justified per se, but streaming went from a nice bonus on top to an "oh shit, we killed the golden goose" for the content industry.

Therefore, I think what we're seeing is inevitable. Higher prices, more silos, and a possible return to bundling or similar. And probably with less content to go around. That will push some into piracy, but we all know that never made up a substantial fraction of users in the first place.

It's worth noting that was a turning point: the "more wood behind fewer arrows" policy adopted by Larry [1] initiated the die-off cycle of Google products. Prior to that, as far as I am aware, they were much more tolerant of products staying around in a mature-but-not-wildly-successful state. Afterwards, it seemed as if they would only keep things that maintained a trajectory to become as successful as their core products.

Again, this was not entirely unpredictable. While I don't remember the details of that lecture, I remember the professor calling out these sorts of big shifts in cultural values as being typical of startups transforming into large companies. And Larry himself was part of the transformation, turning into (presumably, what he believed to be) what was needed to lead Google into its next stage as a large company.

[1]: https://googleblog.blogspot.com/2011/07/more-wood-behind-few...

When I was an intern at Google circa 2010, there was a guest lecture from a business professor who described exactly this process. At the end of it, he made a comment like, "Of course none of this will happen to Google. You're too innovative." But literally every single prediction of his came true, and I witnessed some of them happening in front of my own eyes even in just the months that I was there (and certainly in the years that followed, though I was no longer with the company).

Ok, serious question. If you think the threat is real, how are we not already screwed?

OpenAI is one of half a dozen teams [0] actively working on this problem, all funded by large public companies with lots of money and lots of talent. They made unique contributions, sure. But they're not that far ahead. If they stumble, surely one of the others will take the lead. Or maybe they will anyway, because who's to say where the next major innovation will come from?

So what I don't get about these reactions (allegedly from the board, and expressed here) is, if you interpret the threat as a real one, why are you acting like OpenAI has some infallible lead? This is not an excuse to govern OpenAI poorly, but let's be honest: if the company slows down the most likely outcome by far is that they'll cede the lead to someone else.

[0]: To be clear, there are definitely more. Those are just the large and public teams with existing products within some reasonable margin of OpenAI's quality.

This doesn't make any sense. If it was a disagreement, they could have gone the "quiet" route and just made no substantive comment in the press release. But they made accusations that are specific enough to be legally enforceable if they're wrong, and in an official statement no less.

If their case isn't 100% rock solid, they just handed Sam a lawsuit that he's virtually guaranteed to win.

Or cuNumeric: https://developer.nvidia.com/cunumeric

How do you know what kind you are?

I have zero response to caffeine up to a certain point, and then past that I get shaky and anxious. One cup of tea, no response. Two is too much. Coffee is often on the edge. But no effect on alertness no matter how much or little I take.

Just FYI, the direct answer to your question (about text editors) is Typora:

https://typora.io/

It's not totally clear what you're looking for.

As you noted, polyhedral compilers work on a pretty restricted subset of programs, but are fairly impressive in what they do. There has been research on distributed code generation [1] as well as GPUs [2]. While there has been work on generalizing the model [3], I think the amount of parallelization that a compiler can do is still very limited by its ability to analyze the code (which is to say, highly restricted).

Then you've got a large class of data-parallel-ish constructs like Rayon [4] as well as executors which may work their way into the C++ standard at some point [5]. How much safety these provide depends greatly on the underlying language. Generally speaking, the constructs here are usually pretty restricted (think parallel map), but often you can write more-or-less arbitrary code inside, which is often not the case in the polyhedral compilers.

If you don't care so much about safety and just want access to every parallel programming construct under the sun, Chapel [6] may be interesting to you. There is no attempt here, as best I can tell, to offer any sort of safety guarantees, but maybe that's fine.

On the other end of the spectrum you have languages like Pony [7] that do very much care about safety, but (I assume, haven't looked deeply) this comes with tradeoffs in expressiveness.

(I work in this area too [8].)

Overall, there are some very stringent tradeoffs involved in parallelizing code and while it certainly has been and continues to be a very active area of research, there's only so much you can do to tackle fundamentally intractable analysis problems that pop up in the area of program parallelization.

[1]: https://www.csa.iisc.ac.in/~udayb/publications/uday-sc13.pdf

[2]: https://arxiv.org/pdf/1804.10694.pdf

[3]: https://inria.hal.science/file/index/docid/551087/filename/B...

[4]: https://docs.rs/rayon/latest/rayon/

[5]: https://github.com/NVIDIA/stdexec (disclaimer: I did a quick Google search on this, not 100% sure this is the best link)

[6]: https://chapel-lang.org/

[7]: https://www.ponylang.io/

[8]: https://regent-lang.org/

I feel like it's the exact opposite. We're drowning in data.

Consider: the Library of Congress has (literally) a copy of every work that has ever been in print in the U.S. The Internet Archive has archived much of the public internet. There are other resources like arXiv, Zenodo, etc. Many of these organizations are very conscientious about data retention and longevity.

Is there even more data that could be saved in principle? Of course. But the amount of data we're talking about is already so much dramatically larger than what we have about, say, the antiquities, that it seems like an absurd comparison. The problem in the future (excluding extinction-level events) will be wading through that data, which even in the handful of resources I've mentioned above will be so far beyond any single human's ability to understand that it's just unfathomable.

Let's not exaggerate here. I've got the M2 Pro Mac Mini, and it is nearly silent, but depending on your workload you still generate nontrivial heat and the fans do need to run to keep it cool. Maybe I notice more because I build a lot of software, but this is not some magic bullet that avoids the need for traditional heat management.

Legion is a C++ runtime system. It exposes APIs in C++ and C. You can write code directly to it with C++ (and CUDA/HIP/SyCL if you want to use GPUs). But the only requirement is a C++ compiler and standard build system (Make/CMake).

Regent is a programming language. The compiler for Regent generates Legion code. Semantically, Regent is mostly a simplification of Legion. There are fewer moving pieces, so fewer things you need to worry about. Many of the "gotchas" that exist in Legion are taken care of by the language/compiler so idiomatic code usually "just works". It also does GPU code generation for you so you don't need to hand-write CUDA/HIP/etc. The tradeoff is that you're using a new programming language, so you have to be willing to take that risk.

Parallelism in CS is a bit like security in CS. People know it matters in the abstract senses but you really only get into it if you look for the training specifically. We're getting better at both over time: just as more languages/libraries/etc. are secure by default, more now are parallel by default. There's a ways to go, but I'm glad we didn't do this prematurely, because the technology has improved a lot in the last decade. Look for example at what we can do (safely!) with Rayon in Rust vs (unsafely!) with OpenMP in C++.

And there are things even further afield like what I work on [1][2][3].

[1]: https://legion.stanford.edu/

[2]: https://regent-lang.org/

[3]: https://github.com/nv-legate/cunumeric

I don't think people object to de-duping true duplicates. The problem is near duplicates, where the original question/answer didn't quite cover what you're asking. In those cases, it can be frustrating getting past the SO duplicate filter, which can sometimes be too aggressive.

Or, when searching for answers, you keep chasing your tail because the mods kept killing off the variants of the question you cared about, and you have to cobble together answers from the comments because those will often be all you get.

Or (and arguably worse), you'll find a relevant question but the answers are inundated with "like the real answer, but variation for situation X" because people are posting to the main question because they know the almost-but-actually-not dupes will all get closed out.

We already have townhouses (that share a wall but own their own land) and condos (which share land and the building). There are also well-established legal precedents for things like easements (e.g., for access, water, sewer, see [1]).

I'm not saying this is a good idea, but is it really that different?

[1]: https://en.wikipedia.org/wiki/Easement

Yes, we're focus mostly on scientific computing. One of our major apps is S3D, which we ported to Regent from Legion C++ [1]. This has been the first time the domain scientists have been able to modify the code themselves; previously the C++ was too much for them. There are other examples of Regent apps elsewhere in this thread.

If by "industry" you mean in areas related to HPC, then Regent is likely to be applicable to what you want. The further you get away from HPC, the less likely that would be. You probably wouldn't use Regent to write a web server, though it's not impossible....

Right now my biggest item is making sure we support all the DOE supercomputers, which means adding support for Intel GPUs. (Regent currently supports NVIDIA and AMD.)

[1]: https://theory.stanford.edu/~aiken/LegionRetreat22/slides/ch...

I should also note that there is Pygion if you want to use Python. Not a lot of great reference material right now, but there's the paper:

https://legion.stanford.edu/pdfs/pygion2019.pdf

And code samples:

https://github.com/StanfordLegion/legion/tree/stable/binding...

Chapel's killer feature, in my opinion, is being able to take something that looks like a simple loop and turn it into distributed code (via domain maps). To the extent that you can write your program in terms of that feature, you can get very clean programs. But once you step outside of that feature, you've basically back to full-on parallel programming (i.e., explicit PGAS programming with nearly every parallel programming construct under the sun). Chapel offers a nice syntax, but it's semantically not so different from writing SHMEM or MPI or one of these other explicitly parallel programming models.

Regent does also support loop auto-parallelization, though it's not the focus of the language and not generally how people write idiomatic Regent programs. Regent fundamentally is a task-based programming model. "Task" is a fancy word for a function that can run in parallel. The key is that (a) tasks execute with sequential semantics, and (b) inside of a task, you can do basically whatever you want. The compiler doesn't need to analyze the code aside from verifying that you're passing data around correctly. This means the set of programs you can write in the "nice" subset of the language is much, much larger. The vast majority of Regent programmers never encounter any explicitly parallel programming constructs, there is no way to make code that deadlocks or races, etc. On the other hand, organizing programs in terms of tasks does still take effort and a degree of cognitive shift. You still have to divide the program into parts that can be parallelized, even if you're not responsible for parallelizing them.

Hey, I'm the creator of Regent. Feel free to ask me questions.

It's more like they flood the results so you literally can't find the quality product unless you know the brand name to search for. I can't be an expert in every vertical, so either I go to some sort of trusted review platform like Wirecutter, or I give up and buy whatever I can find on Amazon return decent reviews and hope for the best.

Again, not a physicist. But my understanding is that on a femptosecond timescale (the duration of the x-ray pulse generated by LCLS-II), effectively no reactions occur. The pulse destroys the sample, so that means you have to pump through a steady stream of sample particles to image. So for any given experiment, you'll get a stream of what are effectively snapshots of the reaction occurring at a given moment in time, and then it's up to software post-processing to figure out what you're looking at in a given snapshot and how far progressed the chemical reaction is at that point.

I don't work on this directly, but I do adjacent stuff in the computer science research group at SLAC.

Feel free to ask me questions, I guess? (I will not be able to say much about the physics.)

LuaJIT is in a very weird place overall. Some years ago, the main developer announced that they were stepping down. A bunch of forks sprang up as a result. Meanwhile, the main developer declined to put anyone else in charge of the project, and basically kept developing it on their own (albeit at a slower pace). The forks eventually died; no one was able to build enough momentum to keep a community going.

So this policy was basically where we were anyway. I'm glad the project hasn't died, and in my practical usage it's been very stable, so I haven't had trouble grabbing random development commits off the Git repo. My impression was the release process was very high overhead, and I'd rather that the main developer stick around to work on the code rather than leave due to burning out.

Hm? They appear to have Stripe and crypto options too, as well as Alipay.

Doesn't hydrogen have issues with embrittlement [1]? I'm no expert, but why are they choosing that as the propellant instead of something else?

[1]: https://en.wikipedia.org/wiki/Hydrogen_embrittlement