2,142 karma · joined June 28, 2022
NVidia market cap: 2.64T
Antitrust issues aside, NVidia could acquire Intel for about 1/30th of their stock. That would result in having an end-to-end platform play like AMD/ATI, about 5x the number of employees, a tremendous number of technologies (compilers, numerical libraries, etc.), massive diversification, and actually rather better fab access in both directions.
Thoughts?
I think the key difference was that in the early days, one could only afford a single-pass compiler. Then, double-pass (but it was slow). Itanium was just at the time when compilers could _practically_ do deeper program analysis.
There is no individual piece in making a good compiler for Itanium which I can't solve. At the time, most interesting CS problems that smart people were working on are what we called "microprogramming" in my college jargon -- optimizing individual algorithms, optimizing an assembly loop, etc. What made an Itanium compiler hard was (again in local jargon) "macroprogramming" -- making all those things work together.
> I'm quoting from memory, but I saw a great statement somewhere that fans of RISC tended to be people forced to program assembly in university, which was painful on CISC architectures. This often clouded their judgement that extra instructions can dramatically speed up computing and the complexity can be abstracted by higher level languages and compilers/JITs. The real world is a harsh mistress (this is not to say RISC CPUs didn't have performance benefits in many cases, but it was mostly where large amounts of data needed to be computed on like databases).
This doesn't match my history.
The hypothetical difference was the other way around. CISC had complex instructions (which might take many cycles to run, like a string copy). RISC has simple instructions. Ergo, "reduced instruction set." The technical difference in early processors was RISC was pipelined and CISC was microcode (where all instructions took many cycles).
The reason for CISC was largely so programs could be smaller. This made a huge difference if a computer has e.g. 8k of RAM. CISC, circa Pentium days, was hard to make fast because:
- CISC variable length instructions were hard to decode, and RISC fixed-length ones were easy. This mostly disappeared as decode units became smaller perhaps circa 2005.
- CISC was hard to pipeline. Again, circa 2005, it became easy to (1) avoid annoying instructions in code and treat them as very slow backwards-compatibility special cases in hardware; or (2) do a translation.
For the most part, the practical distinction disappeared around then.
> The big difference is that GPUs, which are a fundamentally different paradigm of computing from CPUs, provided an immediate improvement even before heavy optimizations could be done. GPU development was kickstarted by games and it took decades for it to branch out to other large markets (first crypto, then AI).
True. Although that's more of a business distinction than a technical one.
> But the real benefit of GPUs is that it didn't replace CPUs, but operated in parallel. You could even run quake without one, at obviously reduced performance.
I'm betting 50% on convergence, as number of CPU cores grows, and GPU cores become increasingly complex. I think the M1 may be the track we eventually converge on, with diverse cores optimized for diverse tasks.
> But intel also screwed up with GPUs...
True. Although they seem on an okay track if they can get the software right. A770 16GB can be had for $300. NVidia 4060 16GB is $450 (and faster). For a lot of non-gaming users (ML, CAD, etc.), the A770 is ideal.
> I'm a big believer in incentives. Intel's incentives were to make a CPU that nobody else could copy like x86. The complexity was probably internally seen as a benefit so it'd be harder to copy. Intel thought it could dictate to the market what it was going to get and it arrogantly saw its market domination as being stronger than it was, leaving AMD to create 64 bit extensions to x86 on its terms (hilariously most compilers call the architecture amd64).
I am too -- although that's a business rather than technical argument -- but I'm not sure that's exactly what happened here; I think it's about half-right. I think Intel simply overestimated the amount of time it would stay dominant in the market, underestimated the competition, and underestimated the time Itanium would take to develop.
I don't think they were intentionally making the CPU either easy or hard to copy.
We were in the golden years of Java bytecode translations, real-world JITs, and Transmeta (which made a similar bet in hardware). That was the era we were starting to introduce rather complex transformations and optimizations. Computers were just starting to become powerful enough to where this kind of analysis and optimization felt possible and practical.
The compiler problem felt complex, but not unsolvable.
There were no good, obvious reasons I recall why the Itanium optimization problem couldn't be solved. The basic philosophy was make the hardware as fast as possible, even if it was hard to program, just rely on the compiler to deal with it.
Now, in hindsight, I can give all the reasons it didn't work. Key among them is that we drastically underestimated the degree to which complex software systems are hard to build and the way code messiness grows exponentially for these kinds of systems.
However, that wasn't really knowable in hindsight, though. Around the time, a lot of firms were making similar bets, and in 2001, I likely would have made the exact same bet with what was known at the time.
As a footnote, the anticipated progress in compilers is being made, but much more slowly than anticipated. NVidia reached its market cap on architectures being explored at that time. I had plenty of faculty promise similar SIMD/MIMD architectures would be increasingly important, but __dramatically__ underestimating the time it would take to get there.
* Intel foundry services were perhaps a decade or two too late. Running a fab needs scale. That had to come before they lost the technology edge.
* Intel treatment and mismanagement of engineers was well-known in 2000, and you need the best and brightest.
* Leadership needs to understand core business / technology. Bob Swan. Arguably Brian Krzanich. Paul Otellini. Just a lot of clueless at the top.
Etc. The point is Intel wasn't "everyone." Intel was at the very top of the game a quarter-century ago. That was their position to lose, which they did in a spectacular fashion.
I continue to hope for a Microsoft-style comeback, but it's becoming increasingly unlikely.
If it's unlimited or "throttled for abuse," say that. Right now, I don't know if I can try it six times or experiment to my heart's desire.
1) Spend $100k in litigation to discover your boss owns the code
2) Get $20
Fights don't benefit anyone. Some companies would act like dicks and "ask for as much as they could get to remove it," but in most cases, that's not what happens either. A company like that would never get repeat business. Coincidentally, some employees do the same, with similar consequences. And there are employers everyone knows not to work for.
Resolving this sort of thing for a buck -- in the way a court would rule -- is really standard common-sense practice.
* Contract law does not require arm's length. A contract for $1 is okay.
* Tax law may require arms length.
* I've never heard of arm's length in employment law, but there are laws which lead to what you describe (e.g. mandatory overtime pay, minimum wage, etc.). In some jurisdictions, there are limitations on how much an employer can change the terms of employment. If you hire me for $100k, and after I quit my old job a week into the new one, you give a pay cut to $80k and otherwise change the terms of the deal, that might not be okay.
Any contract requires consideration. Without it, it's not a valid contract. It doesn't require fair consideration, so a clause giving e.g. $1 is typical for many contracts. They were nice and bumped it up to $20.
I suspect your work DID belong to the company already, under work-for-hire doctrine, but an explicit contract avoids that ambiguity. Ambiguity can be bad and super-expensive, whether during litigation or even something like an audit. If someone is buying a company, investing, making a major loan, that's the kind thing which comes up in due diligence and can be annoying.
So I don't think they were paying you for the code, so much as trying to come into compliance. Very likely, this was triggered by some similar audit for some deal they were trying to make.
There are very, very strong individual pressures to overhire. "I managed a 500-person team" sounds a lot better on a resume or otherwise than "I managed a 5-person team" (even if the 5-person team did more).
I also wouldn't go all cash. I'd do the normal $150-$200k cash, and the rest in equity. I'd be very, very generous with equity.
There are also time pressures, whereas many things take time to build. 5 people x 4 years >> 20 people x 1 year, at least if kept productive (which is sometimes hard with longer timelines)
So to be clear: If all of those were SWEs, that would be 2,268 people to introduce bugs, and roughly 2.5M potential social links / interactions (and communications overhead).
The issue queue is what results.
Most projects are best done by about 2-10 person teams. That's about where you can maintain architectural coherence. Beyond 20, architectural coherence becomes impossible.
"Bonus: Legacy Outdated Python Usage Warning Signs" was a helpful list of things to look at, but I disagree with many as best practices. I like when code from the year 2000 still works, and you do that by using standard packages.
The chase for the latest / greatest means bitrot and is the sign of a junior developer. You save a bit of time in the short term, but a new latest / greatest comes out a few years later.
The conclusion is a bit weird too. That kind of rant is what leads to no-hire decisions. Be careful what you put online.
Gitlab has 2,268 employees. That's probably an order-of-magnitude more than they need. With 226.8 employees, they would be wildly profitable. Now, once you take on employees, it's very, very hard to shrink. It takes a lot of disciplines not to overgrow workforce. So I'm not suggesting layoffs or anything specific to fix it.
Regarding costs: Gitlab is $29/month. Github is $21/month (or $4/month).
* If you're spending $200k on an employee, is it really worth saving $300 or whatever per year on tooling? Any difference in productivity will far overwhelm that.
* If a devops employee runs $200k per year, are you going to "host your own" to "save" a few grand?
Much of the market simply doesn't care about pennies, and bottom-feeders aren't super-profitable in either case. Bottom-feeders can be important from a network effects perspective, but for profit, going for the high-margin makes a lot of sense.
Honestly, I have no idea how I'd value gitlab; that's another story. But all else being equal, I'll pick open-source over proprietary. That is a competitive advantage over github.
That's what most open models rely on.
1) Hosted services are cheaper than running it myself, once I include staff time, so by default, I will go to the source vendor.
2) Even if there's a cheaper alternative, I'll gladly pay e.g. 50% more to go to the organization which wrote / maintains the product. Many companies just aren't that price-sensitive. If you pay $200k for a SWE, is saving $100/year worth it to go for gitlabknockoff.com instead of gitlab.com? Most big organizations wouldn't. The risk only comes in if gitlabknockoff was AWS, Azure, or GCP, which we're still learning what to do about.
3) There is a shallow moat in the forms of things like brand recognition, canonical URLs, etc.
If you're comfortable with e.g. a <100% profit margin, open models do just fine. Open models just mean you can't have a 10,000% markup or do an Oracle-style milking of customers. As a customer, that's why I pick open models.
Open models also mean I'm not SOL if you go out-of-business.
The friction comes in with a lot of hybrid models. Most things between open and proprietary don't work well. Datadog + gitlab are on opposite sides of this divide, and I don't see that working well.
I like both companies, but there is strongly negative synergy. I'm sure there's some vision behind it, but like most such purchases, one side or both will likely crash-and-burn. That would be sad.
Aside from technology issues, the companies have a completely different culture and ethos. Universally, that's not preserved in acquisitions like these. Gitlab has a very unique culture of transparency, remote work, etc. which won't mesh at all with Datadog.
If the goal is some kind of integration, a much better model is a significant investment and partnership agreement. It's possible to have those permanently binding, while still being attached at the hip.
- Whether people move with the work
- Telework infrastructure
- Central America is a convenient plane hop away, and in the same timezone.
- Parts of Africa and India are anglophone, which makes life easy. Africa is at least somewhat timezone compatible (calls might cut into evening plans, but you don't lose sleep)
The cost-of-living relative to Vietnam is low enough to not matter. There are also middle-income countries where cost-of-living is a bit higher, but with much better infrastructure. Plenty of Southern and Eastern Europe is at about a third of the per-capita GDP of the US.
TL;DR: Travel around and shop for what fits you.
Detroit wasn't very springy.
30+% vacancy means it's still vastly overpriced,
Alternative theory: As WFH improves, WFH will increasingly mean "Work from Ukraine," "Work from India," and "Work from Ghana." It will be hard to justify SFO salaries.
Coders like being at home.
* yt-dlp
* whisper
(whisper is surprisingly good for a lot of educational videos)
Even better is to connect text to images. but that's less of a simple trick (although I do have the code).
Practically, yes.
I've been in situations where there was no precedent, and in asking what would happen if this went to court, decisions were made based on how lower courts ruled. Legal analyses, law review articles, customary practice, etc. all /influence/ courts.
I would build one piece, as a well-documented Pythonic (not in Python; just in coding / documentation style) library.
The reason this is impossible is the monolithic design of these things. There are good reasons for it -- the pieces interrelate -- but I think it's possible to break it up (with a lot of work).
For example:
- A clean, documented JavaScript engine would be a good start.
- Python-style, independent, isolated JavaScript libraries would help (usable serverside or clientside where possible)
- An independent rendering engine would be nice -- again, documented and independent of the above
- Network libraries
- HTML / XML / CSS parsing libraries
... etc.
If this were in place, code could be interchangeable between serverside and clientside much more than today (and usable in other places, such as using JS as a scripting language in other systems).
Test cases for rendering (or even just making a screenshot) wouldn't need the whole browser. You would import and call into the rendering engine to make a .png without selenium.
Making a new web browser would involve mostly glue code and OS-specific code.
Russia is the most sanctioned country in the world. That's economically bad for everyone; just less bad for the US than Russia. The argument that this is designed to help US companies is... crazy.
My experience is that only helps if each layer is carefully designed and analyzed at a level impractical for most real-world systems.
In most cases, unless you're designing Unix from the ground up, the better approach is KISS.
My experience is that security is a function of simplicity and individuals having a complete understanding of the code and implications of changes.
Implications:
- A smaller team will generally lead to more secure software than a larger team.
- Many security layers are counterproductive.
In studies, bugs per KLOC are relatively consistent. A 100-line program can be fully auditable. One with a JIT in a virtual machine in a sandbox looks, on paper, more secure. In practice:
- There are many more places to introduce bugs.
- Beyond some level of complexity, it's impossible to understand the security model holistically.
- Bugs often cut across layers
- Layers are often used as an excuse ("We'll leave this, since that other layer will catch it).
Layers can be okay if they're well-understood, analyzed, and well-documented (e.g. postfix). However, the vast majority of the time, they're not. People pointing to bigger workforce or sandboxes in Chrome aren't selling me. It only takes one idiot.... And for sandboxes? I've never seen a clean block diagram of the Chrome security model.
To be clear: I'm not arguing which browser is more secure -- simply that the arguments in this thread don't sell me.
I don't think this is the cure for student loans, though.
The #1 reform student loans need is to be dischargeable through bankruptcy. There's a long list after that.
Credit records doesn't make the list for student loan reform to me. Credit records should be about choices, which student loans are, and which medical expenses are not.
The cliche about $200k debt for a liberal arts degree is perhaps an exaggeration, but the core of student loan reforms should be on realigning incentives to make sure the ROI is positive.
1) Insurance is structured to be affordable to everyone by banning discrimination. Young, healthy people subsidize old, sick people. That's okay.
2) No one is banning free speech. People are banning specific types of decision-making based on free speech.
3) Speech here isn't free. See HIPAA. It's okay -- and even important -- to protect privacy. See also FERPA, RFPA, etc.
I don't feel bad having my interest rates a little bit higher right now, in return for not having them go up if I have a horrific medical expense later. I don't think that should be factored.
This is not a debt people choose.
At a subscription or a significantly higher price point, I wouldn't.
Plural of anecdote isn't data, but anecdote is better than nothing, so there you have it.
The most important distinctions also include:
1) Fit. This matters a lot.
2) Nano versus electrostatic technology.
3) Filtration level. "N95" advertised isn't always 95% in reality, and some are 99+%.
4) Impedance to airflow
#4 is more than just comfort it determines how much air goes around the mask.
More than once per day? It's complicated. There are two designs:
- Electrostatic masks work well so long as the mask remains charged (those are the 3M N95 ones). Efficiency drops as they become moist, especially. However, for good ones, even after extended use, it's still surprisingly high.
- Nano masks basically work forever. The initial efficiency is lower than electrostatic, but remains pretty good for longer than I'd want to use one.
For real-world use, I really prefer nano. Unless you're much more careful than I am, enough air leaks around the mask that I'm not sure there's a big difference between 99%, 95%, or even 80% filtration.
And the numbers are extremely conservative too -- they look at filtration around a few hundred nanometers, which is the worst-case. Most diseases come in on much larger droplets.
One thing which tends to be under-emphasized is that it's not binary. Viral load is important. A single virus particle probably won't cause an infection (it probably won't infect a cell, and if it does, your innate immune system will probably flush it). If it does cause an infection, your adaptive immune system has a lot of time to react, so it probably won't be a bad one.
This is even more true for pollution and allergens.
For my purposes, I find nano masks to be the right bang-for-the-buck. They're much more breathable too. And they handle environmentals like rain or sweat better.
The Asians are right; living in a big city, I've felt better since 2020, with masks, air quality monitors, and HEPA filters everywhere. I get sick less often, have milder seasonal allergies, and just generally do better.
On a related note, other aspects of air quality matter too: CO2 levels, humidity, etc.