jpgvm · HackerTrans

17 दिन पहलेdiscuss

If you want a massive MacBook anyway then it's great. They are decent for local LLMs, awesome for local image models and it's a MacBook so AppleCare+ has your back. IMO it's a no brainer if you wanted a MacBook anyway but it's a poor choice if your reason to buy it is to run LLMs.

jpgvm

19 दिन पहलेdiscuss

So from what little I know of the history there were some serious personal issues going on in the team that led to ~7 of the 11-12 folk on Quake eventually leaving.

Sandy has gone into it on various podcasts and mediums. It's pretty clear he doesn't consider Carmack responsible but rather someone he refuses to name (but is quite obviously Tim Willits) that caused pretty much all the problems.

My read is Carmack is saying he is sorry he lacked the awareness and experience to manage the people stuff.

He lost his dream team, I'm sure it's something he has thought about a lot.

jpgvm

20 दिन पहलेdiscuss

This is honestly the biggest battle with AI driven development right now. You have these extremely potent tools that can output a ton of really great code if they are wielded correctly but there is simply no way to keep up with their output at human review pace (which was already slower than human code creation pace).

I think the only real solution is to add increasingly strict guardrails that can be enforced with a combination of more AI agents and actual executable contracts. The other aspect is through using languages and tools that densify correctness. i.e languages like Rust that have very rich type system so both review and design can be focused on a small by volume slice which is the core types. The other main tools for densifying correctness are formal methods, (model checking, etc), fuzzing/property based testing and static analysis.

All of these tools are cheaper to use than they once were because of lot of the minutiae can be handled AI agents while core invariants can receive heavy human scrutiny.

IMO generative AI is here to stay in development so may as well get ahead of the game and start using these tools to try get the best out of it.

jpgvm

2 माह पहलेdiscuss

So I would say the most important thing is that the APIs these are using as in mlx5 DevX (essentially direct fw access) or ibverbs are exactly the same regardless if it's CPU or GPU talking to it. So with that in mind the source of rdma-core, DPDK, ucx etc may be the most elucidating when it comes to low level details.

For higher level patterns again the APIs are the same so anything building on libibverbs or aforementioned ucx etc are pretty compatible from a high level ideas perspective. If you are new to RDMA in general definitely start with raw verbs instead of using abstractions like MPI if you really want to build a good intuition and then move to MPI once you understand what it is doing for you.

jpgvm

2 माह पहलेdiscuss

Yeah pretty much this.

I would separate the knowledge into maybe 3 distinct buckets.

The baseline: device/host boundary, SIMT programming etc.

The intermediate: kernel architecture, CUDA graph vs persistent kernels, warp specialisation/divergence avoidance techniques etc.

The advanced: architecture specifics so tcgen05, TMA, SMEM/HBM, memory throughput vs compute biases in various arch impls., GEMM, FHMA, all the tricks that make modern fused kernels very fast. Also would bucket most GPU Direct RDMA/GPU NetIO/friends here too.

The baseline hasn't changed much and probably won't, the intermediate knowledge has also remained pretty reliably stable for ~10 years with only things like graphs changing stuff. Tile might become more relevant than it is today but for now CUDA, cuBLAS, friends are where it's worth investing knowledge.

jpgvm

2 माह पहलेdiscuss

This is a fairly crap post and the reasoning isn't sound but somehow the conclusion is still somewhat correct.

You do want to use Rust with LLMs.

The reason you want it is simple, it's more constrained.

LLMs thrive on constraint and drown in freedom.

The further you can constraint the solution space the more likely you are to end up with a solution you like/is actually good.

Rust has several properties that make it really good for LLMs:

* Really robust type system that is also very expressive, if guided LLMs can implement most of the invariants in types which substantially increases the chances of success.

* Great compile time errors, the specificity and brevity (vs say C++ template expansion) means token efficient correction of syntax and/or borrow mistakes etc.

* Protection against subtle errors at compile time, namely data races and memory safety issues.

* Great corpus of well designed code and patterns, higher quality on average than some other ecosystems more favored by begineers/mass-market programming.

* Stdlib is strong, small-ish number of blessed crates.

* Context friendly, type signatures, errors, etc are all dense information.

* Also bias towards compile time checks means less runtime tests which means less toolcall time (and less tests needed overall) which in turn makes the process a ton faster.

I have been continually using Rust, Python and Kotlin since ~Jan this year and keeping track of my thoughts and I increasingly bias towards Rust now where I would have previously chosen Python or Kotlin instead just because I am lazy and I prefer the tool that the computer writes better so I have to write less lol.

jpgvm

2 माह पहलेdiscuss

Don't worry though guys, climate change isn't real. /s

1200 years is a serious timescale, I think humans generally struggle reasoning about long durations or very vast distances. Which leads to them instead postulating how all these other more present, more recent and nearer things can be to blame when what you really need to do is zoom out (in space and/or time).

jpgvm

3 माह पहलेdiscuss

Github Actions is a decidedly unserious product, used largely by unserious people.

It's always been poo, the YAML is bad, the reliability is bad and the cost is bad.

So there is really no redeeming features because even if you tout forge integration it's UI is, you guessed it, also bad.

Putting aside the anti-pattern of using vendor YAML for literally anything (please don't do that) you are distinctly better off with literally any other CI/orchestration service. Buildkite is good, dynamic pipeline = good, there are other good options. If you are a serious person you will find good things to use.

Getting back to vendor YAML, please just use a real build system instead. Define all the actual logic there with entry points/targets the YAML hits. Also generally make sure that you don't need the actual CI system to be up to do releases, deployments etc. A sufficiently elevated local user should be able to run the appropriate target with the appropriate credentials to get the job done in absence of said CI system.

jpgvm

3 माह पहलेdiscuss

No. They have been able to destroy much more important and hardened targets, i.e multiple AN/TPY-2 radars, the extremely valuable AN/FPS-132 radar in Qatar, $Bs worth of aircraft on the apron at Prince Sultan airbase in Saudi.

Not to mention being able to quickly deliver counter-attacks to like for like infrastructure when theirs has been attacked. i.e the Ras Laffan counter punch after South Pars was attacked and the UAE aluminium plants after their steel mills were hit etc.

They have also already essentially taken AWS Bahrain permanently offline at this stage.

So they are certainly capable of it but simply hitting the target removes the leverage of using it in a negotiation. If it's already gone you can't say "we won't hit X if you agree to terms Y before time Z".

jpgvm

3 माह पहलेdiscuss

Pre-war views were very much the status-quo was better than starting a war.

Now that a war is started it has to be finished or the GCC is left far worse off with Iran in a much stronger strategic position in the region despite a decimated military.

jpgvm

4 माह पहलेdiscuss

Thankyou for your attention to this matter!

jpgvm

4 माह पहलेdiscuss

Sort of?

My journey up from Senior/Staff was mostly on the back of proposing and then leading cross-functional projects.

Which means I was doing Principal work before being granted the title. To be honest it was (and remains) a huge amount of work and I wouldn't continue doing it if the recognition and compensation hadn't been forthcoming in the following perf reviews.

If you are doing this stuff and aren't moving up where you are then you should be going somewhere else as that is probably a very exploitive work relationship.

jpgvm

5 माह पहलेdiscuss

VictoriaMetrics stack. Better, cheaper, faster queries, more k8s native, etc. Easy to run with budget saved from not being on Datadog + attracts smart and observability minded engineers to your team.

jpgvm

5 माह पहलेdiscuss

> These are not top tier talent type people, this is work that my mom could do, but Apple can pay much less by bringing people over from India, Pakistan, China to do this work instead of finding Americans to do it.

H1Bs are not getting approved for these for years now.

Infosys and TechM exploited the crap out of it to do shit like this which caused the rules to be tightened massively.

These days you are only getting H1B for folks atleast earning 200k+ base.

jpgvm

5 माह पहलेdiscuss

Bar was lowered massively during the COVID employment boom (with the exception of Apple really).

Unfortunately resetting the bar has massive collateral damage but it will sort itself out pretty quickly.

All the good ones will be re-employed within short order. The ones that the layoffs were trying to flush out with said layoffs will transition out of FAANG into lower-tier employers.

jpgvm

5 माह पहलेdiscuss

I interpreted this: > I don’t see any notable difference between immigrant and non-immigrant

As your main point.

More educated or not doesn't actually matter, whether they meet the bar or not is all that matters no?

My over-arching point is if there were more Americans to be hired that meet the bar they will usually be hired before immigrants because they are less paperwork and money (immigration lawyers fees).

Also I think comparing to immigrant education isn't necessarily a great idea, immigrants need more on-paper education to simply clear the immigration requirements because most governments around the world place a higher emphasis on that than work experience or their salary. US in particular values years of education at a roughly 2:5 ratio vs work experience with 10 years of work experience necessary to qualify vs a 4 year degree.

If you are somehow implying immigrants are fundamentally less intelligent then yeah I don't know what to tell you but that is probably not correct.

jpgvm

5 माह पहलेdiscuss

> what % of this labor could be sourced domestically and what actually needs to be imported?

None of it? The way I see it is every top tier programmer in America is already employed.

I think the inevitable outcome would just be the big multi-nationals (FAANG in particular) would just hire more in their international offices and spread out their engineering org more instead of remaining so American heavy and using immigration to centralise staffing.

There probably isn't a world where these huge companies decide to simply not take advantage of the global talent pool, if they don't exploit it someone else will and they can't have that.

jpgvm

5 माह पहलेdiscuss

My argument is that the H1Bs meet the bar to be hired at their respective companies. Neither pool is inherently better but availability matters.

There are only so many American engineers that meet said bar, they are all either employed or choosing not to be employed.

The ones that don't meet the bar are either employed by smaller employers with lower bars that don't use H1B anyway or yes, maybe unemployed or transitioning to a new industry because they couldn't hack it.

The mythical group I am saying doesn't exist is engineers that are somehow perfectly capable of meeting FAANG bar but are somehow being displaced by H1B. That group doesn't exist.

jpgvm

5 माह पहलेdiscuss

You are proving my point - FAANG hires the top tier talent, and makes extensive use of both the global talent pool and sponsoring immigration in order to meet their needs.

The Americans you work with (along with your other co-workers) meet the bar.

If there were more Americans that met the bar they would employ them before taking on all the extra work and cost of immigration.

I'm not talking about Americans you work with. I'm talking about the mythical ones you don't work with that are somehow disadvantaged by H1B and thus unemployed/underemployed. You don't work with these people because they don't exist.

jpgvm

5 माह पहलेdiscuss

No. The talent shortage is not a myth. The unemployed/underemployed American programmer that can actually keep up is a myth. Everyone good (without additional baggage) is either a) employed or b) could be employed whenever they feel like it.

If you aren't good enough then don't be surprised the companies prefer an immigrant. You don't get an automatic American free pass for having less skills, experience, interviewing poorly, etc.

i.e skill issue.

Ending immigration for tech would simply mean far more global workers/offshoring in order to access the top tier talent via different means as that is the real reason all along.

Wage suppression was the old (and now largely incorrect) story. The visa is still exploitive, it should be amended to be a 10 year visa that is independent of employment so immigrants aren't screwed by layoffs.

comments