2,580 karma · joined June 23, 2011
In the second table, LoL esports is explicitly highlighted as a success by mindshare, but not profitability. And below that:
> LoL Esports: loses hundreds of millions of dollars annually, exists solely as a marketing mechanism to get people to play the actual game
Annoyingly, it depends on the type, sometimes with unintuitive consequences.
Move a unique_ptr? Guaranteed that the moved-from object is now null (fine). Move a std::optional? It remains engaged, but the wrapped object is moved-from (weird).
Move a vector? Unspecified.
> Just intuitively, in such a high dimensional space, two random vectors are basically orthogonal.
What's the intuition here? Law of large numbers?
And how is orthogonality related to distance? Expansion of |a-b|^2 = |a|^2 + |b|^2 - 2<a,b> = 2 - 2<a,b> which is roughly 2 if the unit vectors are basically orthogonal?
> Since the outputs are normalized, that corresponds to a ridiculously tiny patch on the surface of the unit sphere. Since the outputs are normalized, that corresponds to a ridiculously tiny patch on the surface of the unit sphere.
I also have no intuition regarding the surface of the unit sphere in high-dimensional vector spaces. I believe it vanishes. I suppose this patch also vanishes in terms of area. But what's the relative rate of those terms going to zero?
Yes.
If a game is marked with Linux, that means it has a native Linux port. However, Proton has gotten so good in recent years that some of the native Linux ports actually perform _worse_ than just downloading the Windows exe and running it with the compatibility layer.
The investment in Proton makes sense in retrospect, since SteamOS is based on Arch Linux, and most of these games you mention should run just fine on a Steam Deck.
Now, if you asked the same about Pakistan or Nigeria (#5 and #6 in terms of population, but far smaller and with far shorter sea borders), I'd bet that far fewer people would be able to pinpoint those with the same accuracy (whether in the English-speaking world or not).
https://en.wikipedia.org/wiki/Michael_Andreas_Barclay_de_Tol... - moved to St Petersburg around the age of 3
https://en.wikipedia.org/wiki/Pyotr_Bagration - born in Russia
https://en.wikipedia.org/wiki/Peter_Wittgenstein - born near Kyiv
https://en.wikipedia.org/wiki/Alexander_Ivanovich_Ostermann-... - part of Russian nobility; the Ostermann name came from his great-uncles.
Common culprits include chemicals added during the bleaching process and addition of "enzyme" / other ingredients that help improve baking consistency. Some examples:
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...
For reference: xanthan gum specifically would fall afoul of the rules, as... a (ii) stabilizer or thickener, (iv) coloring or coloring adjunct, and (v) emulsifier.
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...
It's quite silly that it's classified as a coloring agent and an emulsifier, when it's neither of those things.
Note that C++23 brings std::move_only_function if you're storing a callback for later use, as well as std::function_ref if you don't need lifetime extension.
https://en.cppreference.com/w/cpp/utility/functional/move_on...
Of those, it's 50/50. The acquisitions were YT, Android, Maps. Search was obviously Google's original product, Chrome was an in-house effort to rejuvenate the web after IE had caused years of stagnation, and Gmail famously started as a 20% project.
There are of course criticisms that Google has not really created any major (say, billion-user) in-house products in the past 15 years.
Actually, we do have some of that data. You can just look at the H-1B employer datahub, filter by Google (or whichever other employer you want to scrutinize), and then look at the crosstab.
https://www.uscis.gov/tools/reports-and-studies/h-1b-employe...
Looking at Google specifically, I observe two things:
1. The number of new approvals has gone down drastically since 2019 (2019: 2706, 2020: 1680, 2021: 1445, 2022: 1573, 2023: 1263, 2024: 1065, 2025: 1250). (These numbers were derived by summing up all the rows for a given year, but it's close enough to just look at the biggest number that represents HQ.)
Compared to the overall change in total employees as reported in the earnings calls (which was accelerating up through 2022 but then stagnated around 2025), we don't actually see much anything noteworthy.
2. Most approvals are either renewals ("Continuation Approval"), external hires who are just transferring their existing H-1B visas ("Change of Employer Approval"), and internal transfers ("Amended Approval").
Either way, I guess my implementation had a bug -- A* does yield a significant speedup, but adding the 0.25x scaling factor to ensure that the heuristic is admissible loses almost all of those gains.
For some concrete numbers: with the bug that basically reduced to BFS, it ran in about 7s; with the bug fixed but a wildly inadmissible heuristic, it ran in about 0.01s; with the heuristic scaled down by 4x to guarantee its admissibility, it ran in about 5s.
I think scaling it down by 2x would be sufficient: that lower bound would be tight if the problem is one row move and one column move away from the goal state, but potentially all four rows and columns would not match. In that case, it ran in about 1.6s.
I then switched to pure Dijkstra which ended up being faster because evaluation was much cheaper at each step, and despite these heuristics being inadmissible, they didn't result in substantially fewer nodes expanded.
That's almost certainly a function of the problem size -- if it were 5x5, this approach would not have been as successful.
I don't see logarithmic scaling, actually. From the table for GRU performance, going from 16384 -> 65536 (namely: increasing the input by 4x) is roughly a 4x increase in time whether looking at CPU-scan or GPU-scan. Okay, maybe the inputs need to be bigger. Looking at the next plot, which goes up to 524288, we see the same behavior: the delta between CPU-scan and GPU-scan doubles as we double the input. That's a constant multiplicative factor. Same holds for LSTM performance.
Is this an artifact of the benchmark setup? Are we actually measuring the amount of time needed to load the full context into RAM? Or perhaps we're bottlenecked on memory bandwidth?
> Success: The gate extraction kernel, which was a huge bottleneck, now only takes 8% of the total time and is memory-bandwidth bound, saturating L2 bandwidth at 1.9 TB/s. This is a good place to be.
Sounds like that might be the case.
Surely you're describing metro areas? There's no way those five cities add up to 34 million people within city limits, given that none of them have 6 million people.
The MSAs added up to 27 million based on the 2020 census, so "close enough". https://en.wikipedia.org/wiki/Metropolitan_statistical_area
That said, Waymo's service areas are nowhere close to covering the full MSAs: https://support.google.com/waymo/answer/9059119?hl=en
- SF doesn't cover East Bay (two thirds of the MSA by population).
- Silicon Valley doesn't cover San Jose, and barely reaches into Sunnyvale (basically just covering the Google Moffett Park office buildings).
- The Phoenix area is missing most of the densest parts of Phoenix itself, as well as anything north / west of the city.
- Los Angeles doesn't even come close to covering the city, much less the rest of LA County or any of Orange County. (Maybe 2-3 million out of 13, from just eyeballing the region.)
On Uber (https://support.google.com/waymo/answer/16011725?hl=en) there's also Atlanta (which looks like it actually has very nice coverage, other than the western half of the city) and Austin (again focused on downtown / commercial districts) which help drive up the numbers.
The population that's had opportunity to see Waymo in the wild is probably higher because they're testing in quite a few cities now (a sibling commenter mentions NYC, for instance).
Whether an argument is passed in a register or not is unfortunately much more nuanced than this: it depends on the ABI calling conventions (which vary depending on OS as well as CPU architecture). There are some examples where the argument will not be passed in a register despite being "small enough", and some examples where the argument may be split across two or more registers.
For instance, in the x86-64 ELF ABI spec [0], the type needs to be <= 16 bytes (despite registers only being 8 bytes), and it must not have any nontrivial copy / move constructors. And, of course, only some registers are used in this way, and if those are used up, your value params will be passed on the stack regardless.
[0] Section 3.2.3 of https://gitlab.com/x86-psABIs/x86-64-ABI
Unless of course this is going to be met with a price hike for Prime...
> • The curved sides of the projection suggest the spherical form of Earth.
> • Straight parallels that make it easier to compare how far north or south places are from the equator.
So why pick this over, say, Eckert IV or something from the Tobler Hyperelliptical family?
There is perhaps an additional argument (present on the wiki page [1], and elaborated on the paper introducing the projection [2]) that the equal earth projection is computationally easier to translate between lat/long and map coordinates, as it explicitly uses a polynomial equation instead of strict elliptical arcs. (This is the main argument presented against Eckert IV.)
The paper also lists some additional aesthetic goals: poles do not converge to points (ruling out Tobler Hyperelliptical), and meridians do not bulge excessively.
In fact, the paper describes Equal Area to be a blend of Craster parabolic and Eckert IV (then aesthetically tuned to avoid being stretched too much in either direction). It is also notable that the Equal Area paper measures both lower scale distortion and angular deformation for Eckert IV.
[0] https://en.wikipedia.org/wiki/List_of_map_projections#pseudo...
[1] https://en.wikipedia.org/wiki/Equal_Earth_projection
[2] https://scholar.google.com/scholar?q=doi.org%2F10.1080%2F136...
edit: I found https://map-projections.net/singleview.php which you can view a bunch of other possible candidates by selecting Pseudocylindric + Equal-Area.
Note: Support for the <applet> element has been removed by all browsers. Therefore, calling document.applets always returns an empty collection.
For instance: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
The <applet> element has been removed (Firefox bug 1279218).
<font> and <frameset> are still implemented in browsers, though, even if they are fully deprecated and marked by WHATWG as obsolete and non-conforming: https://html.spec.whatwg.org/multipage/obsolete.html#non-con...
Most figures I see peg 1mL of CO2 at closer to 2mg (it's about 50% heavier than the equivalent atmospheric volume, since that's mostly N2 with some O2). Your estimate of 240 mL / minute is about 346L per day, or about 700g of CO2. That's roughly the same order of magnitude as the cited 1 kg / person / day.
edit: Another way of thinking about it: if you scale up your numbers to grams per day, you'd end up with a ludicrous 346 kg / human / day. Multiply that by 12/44 (mass of Carbon-12 vs CO2), and that's the equivalent of a human shedding 100kg of carbon every day from just breathing. Most humans don't even weigh that much.
That said, when you're dealing with 256-bit integers, you're almost assuredly not working with signed arithmetic.
Okay. It seems that the cited numbers are from https://en.wikipedia.org/wiki/List_of_countries_by_average_a... which in turn is derived from OECD data, which also allows you to view employees by bands of hours worked per week:
https://data-explorer.oecd.org/vis?lc=en&df[ds]=DisseminateF...
In particular, it looks like as mentioned, most employees in Denmark fall in the 35-39h bucket (nearly 4x the size of the next biggest bucket, 40+ hours). Meanwhile, if you look at the US, the 40+ bucket is more than 10x the size of any other. But it's not exactly a US vs Scandinavia situation -- Sweden has just under 70% of its workforce also working 40+ hour weeks, higher than the UK or Germany.
It might be more interesting to discuss the median hours worked (or any of a number of other percentiles), but it's not obvious those figures are public.
In particular, counting unemployed labor force participants feels wrong, even if you're counting how many hours a week they're spending on job seeking activities (applying to jobs, prepping resumes, interviewing, etc). I know I would burn out if I spent even 5+ hours a day doing just that, 5 days a week, even if I didn't have a full-time job.
There's also a pernicious thing that certain companies do (I'm thinking retail) where they just won't schedule you for enough hours to qualify you as full-time, since if they exceed that threshold, then (gasp) they have to pay benefits like health insurance. I also would prefer not to count that in the discussion of "how much does a typical employee work?"
On the flip side, I'm also less interested in considering the workaholic lawyers and consultants who are putting in 60-80 hours a week (or more!). There are far fewer of them, but they still skew the numbers.
From my perspective, the stereotypical US workweek is and has been 9 to 5 (whether you count that as 35 or 40 hours after accounting for lunch) for the past 50+ years. We certainly fall behind when it comes to vacation, since we still have no legally mandated minimum (I think 2-4 weeks is typical; anything higher is good but not unheard of).
I have seen it go one of several ways.
- Technically count the person as 35 hours per week, giving a 1-hour lunch break. (Or 37.5, with a half-hour unpaid lunch break)
- Add an extra half hour to the day, e.g. have the employee work 8:30-5 or 9-5:30.
- Salaried employees aren't explicitly punching in and out of the clock each day, so there's nothing stopping them from working 8-6 or even longer hours. They don't get overtime, but at the same time the company doesn't care what hours they work as long as they get their work done.
Out of curiosity, what drove that shift? Shorter workweek, fewer hours per day, drastically more vacation, or some combination of the above?
Based on a 40-hour workweek, this would be 34 workweeks. Adding on 2-3 weeks worth of paid holidays, that leaves the equivalent of 15-16 weeks of vacation a year? I know my coworkers in Europe get more vacation than we do, but somehow I don't think it's that much more.
With a 32-hour workweek, this instead looks like ~6 weeks of vacation, which is more believable.
https://www.amazon.com/dp/B07GBM7TZJ seems like a totally normal price to pay for eggs these days, although you probably wouldn't just buy a dozen eggs in isolation, given delivery fees and driver tip.
I think the "best" approach here would be to make it a function-like macro, and also change the name to all caps.
(Also, I tend to agree that `defer { ... };` is still cursed -- it requires the trailing semicolon, which further breaks the illusion of a keyword that takes a block scope.)
Would it have looked any less cursed if it just read `defer { CoUninitialize(); };`?
Agreed that the simplest "fix" would be to just rename the macro to be all-caps.
Meanwhile the thing that stood out to me in the initial recording were the vowel sounds: for instance, "young" sounded almost like it rhymed with "long" before training. (That makes sense, since Mandarin similarly has a word with that sound, as can be found in the common last name Yang [2].)
Incidentally, Mandarin has words that sound like "lung" (e.g. the word for "cold" [3]), but if you replace the "l" sound at the front with a "y" sound, depending on which of two transformations you use, it turns the vowel sound into a long o [4] (near rhyme with "lone"). (There is another transformation that you can use that results in a leading "y" in pinyin, but in that specific case, the vowel turns into a long e, and the "y" is largely silent (e.g. the word for "solid" [5]).)
In the last recording, Victor is clearly rushing through the sentence, and you can tell that where he previously had a clear "s" ending for the word "days", it's now slurred into a "th" sound. Agreed that that's actually a net negative for intelligibility.
The wiktionary links below have clips of pronunciation. I will note that not all native speakers have a Standard Chinese accent [6,7], so there are assuredly some differences in pronunciation to be expected depending on exactly which region said individual hails from.
[0] https://en.wiktionary.org/wiki/%E6%B5%AA
[1] https://en.wiktionary.org/wiki/long
[2] https://en.wiktionary.org/wiki/y%C3%A1ng#Mandarin
[3] https://en.wiktionary.org/wiki/%E5%86%B7
[4] https://en.wiktionary.org/wiki/%E7%94%A8
[5] https://en.wiktionary.org/wiki/%E7%A1%AC