I want to write a browser extension that analyzes past HN archives and decorates the usernames of posts and comments with a "Fell For It Again" badge in the case of people who seemed to believe that Dojo existed.
I had been hoping that these would be a bit faster than the 9950X because of the different memory architecture, but it appears that due to the lower power design point the AI Max+ 395 loses across the board, by large margins. So I guess these really are niche products for ML users only, and people with generic workloads that want more than the 9950X offers are shopping for a Threadripper.
Threadripper very rarely seems to make any sense. The only times it seems like you want it are for huge memory support/bandwidth and/or a huge number of pcie slots. But it's not cheap or supported enough compared to epyc to really make sense to me any time I've been specing out a system along those lines.
I bought a threadripper pro system out of desperation, trying to get secondhand PCIe 80G A100s to run locally. The huge rebar allocations confused/crashed every Intel/AMD system I had access to.
I think the Xeon systems should have worked and that it was actually a motherboard bios issue, but I had seen a photo of it running in a threadripper and prayed I wasn’t digging an even deeper hole.
Yeah I don't get it either. To get marginally more resources than the 9950X you have to make a significant leap in price to a $1500+ CPU on a $1000 motherboard.
It also seems like the tools aren't there to fully utilize them. Unless I misunderstood he was running off CPU only for all the test so there's still the iGPU and NPU performance that's not been utilized in these tests.
No, only a couple initial tests with Ollama used CPU. I ran most tests on Vulkan / iGPU, and some on ROCm (read further down the thread).
I found it difficult to install ROCm on Fedora 42 but after upgrading to Rawhide it was easy, so I re-tested everything with ROCm vs Vulkan.
Ollama, for some silly reason, doesn't support Vulkan even though I've used a fork many times to get full GPU acceleration with it on Pi, Ampere, and even this AMD system... (moral of the story just stick with llama.cpp).
No experimental flag option, no "you can use the fork that works fine but we don't have capacity to support this" just a hard "no, we think it's unreliable". I guess they just want you to drop them and use llama.cpp.
Yeah, my conspiracy theory is Nvidia is somehow influencing the decision. If you can do Vulkan with Ollama, it opens up people to using Intel/AMD/other iGPUs and you might not be incentivized to buy an Nvidia GPU.
ROCm support is not wonderful. It's certainly worse for an end user to deal with than Vulkan, which usually 'just works'.
I agree. AMD should just go all in on vulkan I think, The ROCm compatibility list is terrible compared to...every modern device and probably some ancient gpus that can be made to work with vulkan as well.
Considering they created mantle, you would think it would be the obvious move too.
Vulkan is Mantle. Vulkan was developed out of the original Mantle API that AMD brought to Khronos. What do you mean "AMD should just go all in on Vulkan"? They've been "all in" on Vulkan from the beginning because they were one of the lead authors of the API.
Hi Jeff, I'm a linux ambassador for Framework and I have one of these units. It'd be interesting if you would install ramalama in fedora and test that. I've been using that out of the box as a drop in replacement for ollama and everything was GPU accelerated out of the box. It pulls rocm from a container and just figures it out, etc. Would love to see actual numbers though.
It only seems like a bubble if you think this is that much of an outlier. $750k a year for 2 years is a lot, but it's not an outrageous grant rate for technical staff. It's high but not like 10x high. If it was actually a $1.5m bonus like the headline suggests, then that would be crazy.
It says every member of the technical staff. It also says it's a grant that vests over 2 years, so not what any normal person considers a "bonus". A bonus is cash in hand.
> Every bonus I have gotten has been paid out in January based on past performance. That's why the term "bonus season" exists.
Hey, I believe you and have no reason to think you are lying. Every bonus I've had has been vested over a 2 year period with about 50% vesting upfront. Again this is probably due to my bonus being tied to performance which could change from year to year and the fact the its probably larger than the average bonus employees get.
Every company is different and every bonus is different. There is no one way a bonus is allocated.
It's flagged because flags are crowdsourced, it only takes a few clicks to take down the post, and HN is crawling with MAGA accelerationists who are happy to destroy America.
Or there is a sane explanation - People drive cars -> People push their politicians to improve road infrastructure -> less money for other infrastructure -> trains are underfunded -> trains and tracks are having maintenance issues a reliability starts to fall apart -> people drive cars even more.
While I agree that fundamentally the issue is that Germans spend more on cars than any other European population (but nowhere near as much as Americans), there is also the detail that a large share of VWAG is owned by a German state.
But electricity consumption is a minority of energy consumption. It was always true that decarbonization was going to massively increase the use of electricity.
Yes but the task becomes that much harder - we are scaling up natural gas generation not to phase out coal but simply to meet demand that wouldn't exist without the fierce competition to build the biggest LLM. Any feasible plan made 5 years ago which may have worked to transition a large industry from fuel burning energy sources to electricity generation (renewable or otherwise) is made 10x harder by the introduction of this rapid rollout in datacentre capacity.
I'm not sure if that's true of not. As the article indicates, training for AI is naturally demand responsive. Training can move on the clock, and it can move around the world to minimize carbon footprint. See the PDF I just love to share: "Revamped Happy CO2e Paper" https://arxiv.org/pdf/2204.05149
Agree on training. But that google paper was written when the only image model available for broad public consumption was dall-e 2 and video models were more than a year away. It gets a mention in a more recent 2024 paper [1] which goes into detail about how inference rather than training creates the difficult to manage energy load which grids struggle to meet. If consumer interests and demands drive the trend in what companies offer in terms of inference capability then it's fair to worry that the impact on sustainability goals will be an afterthought.
The second author of that paper is the person who got turfed out of Google for refusing to use actual energy consumption and insisting on using their flagrantly wrong estimate of inference energy costs. E.g. the rebuttal by Dean https://x.com/JeffDean/status/1843493504347189746
The number was correct to a reasonable degree under the assumptions stated by the author in the paper that tweet references since they obtained estimates from consumer grade hardware and the carbon intensity associated with average kilowatt produced in the United States not a hyperscale datacentre run using "ML best practices" although this distinction is left out of various lay media citations. The number also did not pertain to inference it was associated with training a particular model from pre-2019.
I'm sure you see the problem with assuming a very inefficient and poorly-utilized system but at the same time assuming Google scale, and multiplying those factors together.
If your standard is "I won't do anything unless it's the majority of energy consumption," you're really just saying don't do anything period.
>It was always true that decarbonization was going to massively increase the use of electricity.
That was the plan (and it could have worked too), but what actually happened is the new decarbonized energy is supplementing fossil fuel instead of replacing it.
There aren't enough details in the somewhat hyperbolic narrative format to really say, but if I were going to create a temporary archive of files on an embedded system for diagnostic upload, I would also delete it, because that's the nature of temporary files and nobody likes ENOSPACE. If their system had deleted the inputs of the archive that would seem nefarious, but this doesn't, at first scan.
The main reasons to store data are for safety and legal purposes first, diagnostics second. Collision data are all three. They need to be prioritized above virtually everything else on the system and if your vehicle has had so many collisions that the filesystem is filled up, that's a justifiable reason to have a service visit to delete the old ones.
If I were implementing such a system (and I have), I could see myself deleting the temporary without much thought. I would still have built a way to recreate the contents of the tarball after the fact (it's been a requirement from legal every time I've scoped such a system). Tesla not only failed to do that, but avoided disclosing that any such file was transferred in the first place so that the plaintiffs wouldn't know to request it.
The tar file is a convenient transport mechanism for files that presumably exist in original form elsewhere within the system. (All bets off if sources for the tar were changed afterward.)
Given storage is a finite resource, removing the tar after it was confirmed in the bucket is pure waste.
I'm not sure whether you're saying that the tar should or shouldn't be deleted. Regardless, my point isn't that it was intentionally deleted. I can easily imagine someone writing a function to upload the data using something like std::tmpfile (which silently deletes the file when it's closed) without thinking about the full implications of that for the broader context the code exists in.
Even in that case though, you would still have a way to produce the data because it would have been specced in the requirements when you were thinking about the broader organizational context.
When a vehicle crash occurs, that embedded system should no longer be treating data as "temporary", but as what it now is, civil and potentially criminal evidence, and it should be preserved. To go to the effort of creating that data, uploading it to a corporate server, and then having programming that explicitly deletes that data from the source (the embedded system), certainly reads as nefarious without easily verifiable evidence to the contrary. The actions of a company that has acted this way in no fashion lends any credibility to being treated as anything other than a hostile party in court. Any investigators in the future involving a company with such a history need to act swiftly and with the immediate and heavy hand of the court behind them if they expect any degree of success.
"Their system" is a car, sold as a consumer product, which has just experienced a collision removing it indefinitely from normal operation. Reconsider your analysis.
Yes? But the article doesn't say that Tesla deleted the EDR, it says they uploaded the EDR file in an archive format, then deleted the uploaded entity. Which strikes me as totally normal.
No, the car's "black box" is the EDR, the behavior of which is regulated by federal agencies. This article is discussing ephemeral telemetry which accessed the EDR.
No, the EDR forms part of the car's "black box" – just like the FDR forms part of an aeroplane's black box. Per the article, the erased* telemetry ("collision snapshot") contained quite a bit more data than just from the EDR.
*: I can't work out from the article whether this file was erased, or just unlinked from the filesystem: they quote someone as saying the latter, but it looks like it was actually the former.
So? Tesla needs to bear the responsibilities of having deleted its own potentially exculpatory evidence. Not granted an inference that it did so and therefore Tesla is innocent.
I would love to see what you need so much disk space for after the car is crashed and airbags are deployed. If that event fires the car is going in to the shop to have its airbags replaced at a minimum. Adding a service step to clear up /tmp after a crash is fairly straitforward.
I would be fascinated to entertain arguments for how the future write life of a flash memory chip, meant for storing drive-time telemetry in a wrecked car, merits care for preservation.
Many parts, especially non-moving parts, hold value after a wreck. It does not make sense to keep the file on the disk for the lifetime of the part. The part is most likely going to be resold as used. The part will have a shorter life if the big crash data file is left on disk.
I didn't know Tesla authorized any resale of parts from any of their vehicles, used, crashed, or otherwise! Certainly I had no idea they built support for it into the system software. Was that a recent change?
Oh, I'm sure it has. Owners tell a different story about what the site is worth. Of course, Apple actually "innovated" that one. But do you seriously mean to suggest Tesla engineer their cars to discard potentially dispositive crash analysis, in order to support their own resale of junkyard pulls?
Your implicit claim is that there exists a resale market for wrecked Teslas, meriting such product and engineering interest from the company that the car's data storage, in the immediate wake of a disabling collision, preemptively and correctly destroys information of use to crash investigators, so that the company can cannibalize the wrecked hulk for items which Tesla then goes on to sell as new OEM repair parts.
Isn't it embarrassing to go to all this? It certainly seems like it should feel that way, for as degrading as it looks from the outside. If you can explain it, I would like to understand what makes it seem worth your while.
The data was not preemptively destroyed. It was uploaded and then deleted. The implications for deleting are obvious. The part can be sold and reused after the crash data is erased. The part should not be sold and reused until that information is erased because it contains a large file and this file will likely contain death footage.
>
The data was not preemptively destroyed. It was uploaded and then deleted. The implications for deleting are obvious. The part can be sold and reused after the crash data is erased. The part should not be sold and reused until that information is erased because it contains a large file and this file will likely contain death footage.
Okay, then your contention appears that Tesla is content with not bothering at all to refurbish the junkyard pulls it sells through OEM channels as OEM repair parts, thus denying themselves any opportunity to manually wipe sensitive data - potentially to include video of the prior owner's violent death! - as part of any remanufacturing or even basic QC process. But - as has now been made a matter of public record, in consequence of their fighting and losing this wrongful death case - Tesla do make sure to keep a copy for themselves, one of an apparently large collection of same which they went far out of their way for years to keep anyone else from discovering even exists.
Is there anything you care to add to that? Feel free to take your time. You've said quite a lot already.
This counterargument does not hold. The vast majority of crashed vehicles are not sent back and resold by Tesla. They are resold at auto auctions, junkyards, ebay, etc. Deleting the crash data protects Tesla from lawsuits on both ends of the chain: the victims and the new owners, while also preserving the part's lifetime.
Fundamentally, flash memory is a bunch of pages. Each page can be read an infinite number of times but there are quite relevant limits on how many times you can write it.
In the simplistic system lets say you have 1000 pages, 999 hold static data and the last one keeps getting a temporary file that is then erased. All wear occurs on page 1000 and it doesn't last very long.
In the better system it notes that page 1000 is accumulating a lot of writes and picks whatever page has the least writes, copies the data from that page to page 1000 and now uses the new page for all those writes. Repeat until everything's worn down. Note the extra write incurred copying the page over.
In the real world a drive with more space on it is less likely to have to resort to copying pages.
Wear increases when free space is low as there's less overall space to put the data. If you only have 500MB of free space, those blocks take the majority of write hammering until the chip fails. If there's 5000MB free, you can spread the wear.
I think the goal is to save as much as you can in the interim. Holding onto X bytes of archives is more time worth of data than X bytes of uncompressed. We do that stuff all the time in finance. Stuff gets spewed off to external places and local copies get kept but archived and we simply rotate the oldest stuff out as we go. If the cleanup process is configured separately from the archiving process you can absolutely archive things just to remove them shortly thereafter.
It seems they waited for a subpoena. Would you prefer automakers send the police a notification anytime the car records a traffic infraction, or maybe they should just set up direct billing for municipalities?
The police reached out to Tesla legal within days and asked if they needed a subpoena. The Tesla lawyer said no, but then directed the police to make their request in a specific way that hid relevant data from police and the victims. It took 5 years to get the data, and only then after a forensic engineer proved Tesla uploaded it by finding logs on the cars black box and after the court was leveling sanctions.
Should companies be intentionally misleading to law enforcement about what data they have on fatal accidents like Tesla?
I hadn’t listened to the below video in a while but I did again today and the above comment’s assumptions of fact perfectly illustrate the point of the video.
This comment takes as fact a claim made by the police, which might be wrong, either by error or purpose.
One thing is for certain though, the police’s initial investigation was criminal. That is to say it was to establish the fact of who was the driver, etc. It was totally separate from the civil litigation that later established Tesla to be at 30% fault for the wreck using computer records establishing that ADAS was engaged.
Leaving Tesla out of it, suppose there was some other automaker with some other problem. A cop comes to them and says “what do I need to ask you to establish the facts about an accident?” Since when do police just accept “oh, the potentially adversarial lawyer gave me advice on what they can tell me without getting a subpoena. Guess that’s all I can do?” That’s absurd.
It isn't clear that Tesla pretended anything aside from a claim in the article. The article: 1) does not directly cite an original source; 2) walks back the claim to "acted as if". The police had access to everything in vehicle the entire time. The civil lawsuit plaintiffs also had access to everything as evidenced by their forensic expert's access. That Tesla also received a copy of the vehicle's data is not relevant.
That's obviously problematic. I am only commenting on the belief in a conspiracy of programmers here. The overwhelmingly most likely reason that a temporary file would be unlinked after use is that is what any experienced systems programmer always does as a matter of course.
I've made no contention, but if I had, it would be that whoever signed off on this design had better not have a PE license that they would like to keep, and we as an industry would be wise not to keep counting on our grandfather-clause "fun harmless dorks" cultural exemption now that we manufacture machines which obviously kill people. If that by you is conspiracy theory, you're welcome.
There are not PEs signing software changes for ancillary equipment in consumer vehicles.
ETA: Restate your conspiracy theory in the hypothetical case that they had used `tar | curl` instead of the intermediate archive file. Does it still seem problematic?
"Ancillary" is quite a term for crash reporting after a crash. That is, for a system responding as designed to a collision which disabled the vehicle.
I'm not going to argue with someone who throws gratuitous insults. Rejoin me outside the gutter and we'll continue, if you like. But the answer to your question is trivially yes, that is as professionally indictable, as might by now have been clarified had you sought conversation rather than - well, I suppose, rather than whatever this slander by you was meant to be. One hopes we'll see no more of it.
reply