bartwr

Even "compiled" JAX or PyTorch can leave some performance even if you hit the common path (It's also "praying" that the compiler actually works if you do anything non-standard).

But memory wise, there is almost no optimization or reuse (and it's sacrificed for performance), which leads to insane memory usage.

And it's not that they are bad - but optimal compilation of a graph is combinatorially explosive problem, impossible without heuristics and guesswork (what to reuse and waste memory vs recompute). A good programmer can do a significantly better job.

There are two main paths to promotion and salary increase: - Becoming a super expert in one domain, or an expert in many. Rare, irreplaceable skillset that is recognized and valuable for the business. Yes, this is vague, but there are tons of different career paths where it's possible. Pick the one where you feel you can learn the fastest and are strongest at. (Often correlates with things you like!) Note: This involves some healthy self-promotion, advertising your work, blogs, conferences. Even if you're the best in the world but no one knows it - nobody will care.

- Focus on organizing other people's work, leadership, empathy, cross team communication. This is the way to get promoted into managerial and director positions at healthy companies. Obviously, a junior should not try dictate others what to do (lol, but I've seen some hyper ambitious ones like this - it didn't end well), but first very quickly becoming proactive and gathering requirements by yourself, working with many people and on many projects. Trying to expand the scope of work broad, instead of deep.

Choice of either depends on your skills and personality. The latter can eventually pay more (statistically - there are more highly paid directors than world class experts), but can be also more risky (if more senior people think you want to manage them, they might get upset).

This is kind of amazing given that obviously, GPT-4 never contained such tasks and data. I think it puts an end to the claim that "language models are only stochastic parrots and cannot do any reasoning". No, this is 100% a form of reasoning and furthermore, learning that is more similar to how humans learn (gradient-less).

I still don't understand it and it blows my mind - how such properties emerge just from compressing the task of next word prediction. (Yes, I know this is oversimplification, but not a misleading one).

Spinning up the Uber App is most likely trivial. Spinning up the legal structure, figuring out all the local regulations and getting permits (it's not 2010 anymore! Many countries and cities regulate ride sharing pretty heavily) in a sane timeline is close to impossible.

And it might be not something that an Alphabet company wants to do risk/ reputation-wise. Better to offload bad press (both related to ride sharing in general, and autonomous vehicles) onto an entity which is already "hated".

A new Siggrapg 2023 research paper from NVIDIA that improves the GPU compression by 10-16x while keeping random-access property. It exploits correlation in modern graphics texturing practices (multiple textures describing a single physical material) and at the lowest bitrates, it is competitive with entropy-coded JPEG XL and AVIF formats.

Despite using neural networks, compression time is approximately 1 minute for a 4K 9 channel texture, and the decompression overhead ~0.6ms at 2160p (4K) resolution.

This technique can substantially reduce the download and disk sizes of modern games, reduce the memory usage, or significantly improve the details and quality.

Furthermore, Jeff is not a great (or even good...) manager/director/leader. There were a lot of internal and external dramas because of his leadership, that he failed to address. How often you hear about dramas about other Chef Scientists at other, comparably sized, companies?

He should stay a Fellow, in a "brilliant consultant" role.

As someone who's been at Google Research ~5y, this nails is it 100%.

I was at the non-Brain part of Research and it was seen as Google Brain is the "cool", pure research one, dealing with some future abstract AI and not caring for the products, feasibility, or even if the research "could" be made practical any day.

Deepmind was an "extreme" version of it, with some animosities and politics between the two, which I didn't follow too closely. There were attempts at making Deepmind useful, called "Deepmind for Google", but the people there were... clueless. Though one really cool thing came out of it (XManager).

(I was at a closer to the product part, "Perception", which I loved. And still got to publish, explore, pursue my own research goals, etc.)

That's a super interesting idea and I think should work very well. If it was combined with the use of camera (for tracking the distance away from the monitor / screen) I think it could work very well; especially that noise / quantization / compression is not a problem in such a case.

I think it might be the classic distinction between "simple" and "easy". I do believe that most of those problems are "simple" - typically when you read solutions, it's under 20 Python lines of code; and not really complex or difficult to understand code. At the same time, I agree it's not very "easy" to do them well (come up with a solution, code it up, test it, and explain everything along the way considering trade-offs and pros and cons) under the interview stress and time pressure. Even the most brilliant and well prepared people do fail them for a reason.

I don't know if this translates to other FAANG companies as well, but "washed out too early" doesn't happen at Google. It's very very hard to get fired. You know all the stories of people just "resting and vesting"? It's definitely a thing.

On the other hand, you might be getting "average" ratings (where average translates in practice to poor - a paradox culture of everyone always expecting you to exceed the expectations ;) ), and after 4 years when the initial equity grant runs out, refreshed will be lower and you will start having significantly less stock (which is definitely more than half of the total compensation on higher levels).

(Also IMO it's rather impossible to get overleveled.)

Typically it's based on self reported domain expertise and general hiring interests that you express to the recruiter - to check your competence in what you claim your competence is. But overall the hiring process is slowly changing and now you're more likely to be targeting more specific area of the company, and then your interviewers have a high chance to later be ones during team matching calls. When I started interviewing, I went for a year of ~2 interviews a week and never saw anyone I'd know on the list of other interviewers. Now it's getting more and more likely (other interviewers for example also work at Research and we are interviewing candidates targeting Research).

Thank you! :) Yes, I spent quite some time preparing for that post. If you disagree with some of the guidance, I'm happy to discuss (and/or revisit some of the advice)!

My point of reference is very European. In most of Europe you get very distinctive four seasons - cold, sometimes snowy, almost always frosty and depressing winter, fresh and optimistic spring bringing some change, muggy and sweaty, but exciting summer that you spend outdoors with your friends and 'white nights', nostalgic, colorful and beautiful smelling autumn reminding you of passage of time. And all of those are sometimes dry, sometimes muggy, often raining/snowing. To me (growing up in central-eastern Europe) it's essential to add some "rhythm" of life, otherwise I get into "day of the groundhog" workaholic mode. I'm sure though that people who grew up in those non-seasonal climates have internalized some different ways of marking the passage of time. :)

OP here. I loved most of those, I'd add DNA Lounge (though it seems based on the selection you're not into electronic music :) ). All of those are fond memories of some nice shows. Still was hard to justify a 1h (one way!) drive. :( An to me, the essential part is the local scene/culture. I didn't see too much of it in SF, maybe I didn't stick for long enough (my brutal commute to MTV took away my will to live and I had to move).

To be honest, all your points sound scary/depressing/unappealing to me. Like the last point - helicopter parenting - kind of creepy to be honest, yikes. But this might be a difference in our cultural backgrounds and how we grew up.

But one thing that is not just matter of cultural background and preferences, but of facts and ongoing research - is that pressure, high expectations etc. do have a devastating effect on teenagers' mental health and mental wellbeing.

Hey, it's the OP here - I explicitly mention in my post issues with having kids in the SFBA / SV (competition, high suicide rates) and being a teenager in the suburbs (I grew up in the city center until moving to suburbs as a ~14yo and hated it - totally isolating and depressing) as things that I consider and think it's a myth. I think it might be a great place for a few year olds, but once the school starts, I personally wouldn't want to grow up in SV. But obviously YMMV.

Hey, I'm the author of the post and I wish I could simply write I disagree with you and how - but you haven't explained how the integer coordinates help aligning the grids, so hard for me to disagree with any specifics. I show how integer coordinates work in my post and what is the problem ("hanging" pixels on the right, problems with resampling). Integer coordinates lead to all those nasty bugs with resampling like the original Tensorflow. There is a reason why all libraries and GPUs switch to this convention; as it's most sane from the POV of signal processing - and for the most common box reconstruction filter.

I obviously agree with Alvy Ray Smith and his work is super influential. I like his essay (as it's not really a paper!) a lot, and think that programmers don't think about reconstruction filters enough (I have a few blogs posts touching lightly on the topic as well). But this is very different - pixel being a square or not and the optimal reconstruction filters for filtering Monte Carlo renderings don't answer how to align pixel the grids when resampling images and useful conventions.

Finally, I also emphasize at least a few times that while my "default" convention of half pixel offsets is reasonable (i.e. you can multiply UVs by 2 and get decent resampling behavior with any filter - including windowed sincs, Cat-Rom etc), it's just important to understand the one your signal is already represented in and follow it.

In image processing we often call those "binomial filters" due to this binomial distribution / Pascal triangle connection. Cool thing is that they both a) sum up to powers of 2, making the normalization divisions in fixed point super efficient - just bit shift! b) due to central limit theorem, they approximate Gaussian better and better. Very useful tool in image processing, especially on DSPs where fixed point / shorter integer arithmetic might be faster or wider vector sizes than floats.

The whole point of my post was trying to answer why such approaches won't dominate (at least short and mid term, who knows long term!). :) We know "costs" of such a change - rewriting every single existing system, tool, offline software like Maya, retraining artists, figuring out from scratch how to do things like open world this new way... At the same time, do you know the benefits? Do you know if it's better, faster, have you measured it? I haven't and MM's goal also wasn't to be better or faster, IIUC the main drive was user editing content in new ways + painterly style of rendering.

And btw. artists absolutely hate modeling with nurbs, splines and anything similar. :) They love sculpting in ZBrush, or editing polys directly (for man-made and city objects). SDFs are +/- compatible with it (but come at huge memory and disk space costs - think of it this way, with meshes you encode "surface", so O(N^2) complexity, with SDFs volume, O(N^3), implicit representations not really...

My path to research is very uncommon - at least in the US. Being honest it was very disappointing when I tried to switch the industries. Getting a SWE position was very easy (and many ex-gamedevs do it and are very successful at FAANG; many of them consider new jobs boring, but not toxic like gamedev, no crunch, a few times larger salaries, stability...), but any inquiries about anything research related to recruiter were met with "you don't have a PhD? we will not even interview you for such a position".

My "way in" was to just accept a generic offer and then later switch team to work inside Research (when you don't need to pass N layers of "recruiter abstraction" and can talk with colleagues and present your past work freely it becomes much easier). But still, among my collaborators maybe 5% don't have a PhD?

All of this was a surprise to me and made me question my life path and life choices. I'm originally from Poland in Eastern Europe and the only reason to consider a CS PhD would be if you wanted to teach. And I even considered it, but never occurred to me to do it for any kind of R&D work - mostly because of quality of Polish academic "research" being very low, much worse than the industry. And I am still in lots of self-doubt and questioning if I belong in this environment. Questions like "who was your advisor / what was your grad group?" when introducing yourself to new people become almost micro-aggressions. Also my focus on R&D ("solving unsolved problems") is very different than academic incentives ("use PhD interns to do projects, then write papers and get citations").

You are right that "off-the-shelf" engines have tooling and features rich enough that even a single person can make a pretty and fun game.

But I disagree with the higher level idea - that this means that things become simple. It's the other way around - they became so complex that a few person studio cannot write a new, general engine (see how many people programmed Doom or Quake which were state of the art back then!). At Unity there are a few thousands of just programmers working on the engine (yes!). This is not FAANG size, but I don't know if there is a team at FAANG that has a few thousands of engineers working on a single product. You need a team of this size to make a multi-platform, universal engine that is still not good enough to make AAA or open-world games.

Also my personal experience at my last games job (I left games) was the complete opposite of what you suggest as "engines being commodities" (at least this is at odds with you writing that they are working on AAA engines- sounds like they might be "using" engines and not writing in-house ones?). At Sony Santa Monica we had a team of ~30 programmers, out of which ~8 graphics people (just for a single platform and a single game) and I was constantly frustrated with how impossible it was just to catch up on all necessary state of the art techniques with a team of that size.

There are people much smarter than me who spend for example a half of a year on something as obscure as "multiscattering rough diffuse BRDF" - and a larger engine has hundreds of "features" like this.

So I don't know how HN really works, but FWIW I posted it here 10mins after the post went live. Then it just went down into obscurity (almost always my submissions to HN do), so I just ignored it, later saw a repost and ignored it, "oh well, whatever". Then I was really surprised next dat that it went back to life and with "posted 2 hours ago", I thought it was some bug or some mod interaction, but most likely I just don't understand how HN as a platform works...

I mention the Dreams in the passing - as it is such a special gem and special case that it would require much more care and analysis, probably material for multiple posts. What makes Dreams special is that it is a platform for creativity and content creation by its players. It's not a machine for making AAA products that cost 100s of millions of dollars and takes teams of hundreds people. (Also - I don't have any data nor insider knowledge despite working at Sony, but I am almost sure this project lost Sony money because of never-ending production... Which only speaks great of Sony for supporting it)

Brilliant creators of Dreams didn't care if software like Maya or 3ds Max are not compatible with their approach - as it wasn't the target audience. They didn't care for scalability of the tools, pipelines, and the renderer in terms of business practices, parallelism, finishing on time, reusing existing technology, packing with certain features. If your core feature is something unique like this, many other constraints can just go away. Is it the future of rendering? I don't think so. Btw. Media Molecule's Alex Evans (amazing person, he used to create beautiful art for demoscene) has long history of innovative rendering tech - like LBP used lots of voxel and volumetric representations (look for "Voxels in LittleBigPlanet 2" Siggraph talk) on PS3 and it also didn't catch up. Different use-cases = different constraint.

See also another example I mentioned in the post - Claybook, it uses SDFs for rendering representation (and physics!), but is also a very unique and special case.

In the article, I mention a few ways of dealing with it - from "old school" impostors/billboards (think of precomputed sprites), simplified representation, to finally temporal anti-aliasing (reusing pixels in screen space). All of those work well under some strong constraints and are used today, however all have problems, trade-offs, artifacts - whole point of the post.

Temporal AA is the most general and mature solution, but at the same time, many gamers hate it due to introducing some blurriness through imperfect resampling (and makes some very small population motion sick) - just web-search for "temporal antialiasing reddit" and see the sentiment of many users.

Hey, I'm Bart, author of the blog post that got linked in this HN. :) Your points re error diffusion being way better are true; the difference is night-and-day, especially on some thin features / lines.

At the same time, error diffusion is not GPU-friendly at all, especially in arbitrary pixel shaders due to its sequential pixel dependency chain (pixel xn, yn usually requires computing errors for pixels xn-1, yn; xn, yn-1 etc.). Those are much better implemented as recursive filters on CPU or even in hardware. There are some hybrid algorithms that work in tiles, but then require compute shaders and more sophisticated engineering (~orders of magnitude slower and impossible to compute "in place").

While writing that blog post series I was working in video games industry and therefore focused on real-time scenarios and "tricks".