zifpanachr23

This is good advice and it's worked for other things I've been addicted to.

I guess you can think of this as my retirement from Hacker News. Thank you kind stranger.

I don't think many of us find it acceptable judging by the comments here. Programmers aren't the target audience though, the actual target audience probably has no idea how much faster these things can and should run.

Says the company that only hires in India now and is notorious for disloyalty towards the workers that made them.

$150 billion is bullshit as well, R&D spending they have committed to is actively going down year over year. No details at all on how they came up with that number and nothing at all has been signed.

Oh 100%. As far as I am concerned, anybody that has touched that stuff is blacklisted and radioactive.All its gonna take is a little prick and the financing on the whole house of cards falls apart.

So don't think my hostile opinion towards developers that are involved in using AI to abuse their fellow humans is going to be remotely rare in the future. All the necessary preconditions are already there and the only reason it hasn't been noticed yet is because the people that fucked up are still able to get jobs at companies riding AI funding to do AI work.

Look what happened to a lot of the crypto bros. Now multiply that by 10 and the amount of nasty shit they were doing to other workers by 10 and I don't think people are going to take it as lightly as a lot of the crypto bros got off, which was usually just a black mark and severe down leveling when they came back to work at actual companies.

Lmao. Don't pay any attention to the thing about incels, which whether true or not, so obviously does not establish that android was a causative factor. Look at the percentage of US people that have Android. iPhone is not nearly as dominant in the US as spoiled brat teens seem to think. Nearly half the population is Android users. I'm sure we are all incels.

The pressure should obviously be applied on the underage children with the Apple products, or better yet on Apple. Perhaps the children should be punished and have their iPhones taken away and replaced with budget android phones or flip phones.

This is good in the long run since the behavior they were engaging in puts them at odds with nearly half the population. Not only is it anti-social behavior, it's mind numbingly stupid and likely to backfire in ways that make their lives worse.

~43% of the cell phones out there in the US are Android phones. To follow their conviction against Android at all convincingly and thoroughly, they would be missing out on a lifetime of opportunities and would live a significantly diminished existence.

iPhone is not even close to being a dominant enough platform to be able to enforce this kind of social pressure against anyone but people significantly under the age of 18. Shame them, make sure they feel bad and spoiled (they should feel spoiled for being a child with an iphone), and watch them grow out up to be pro-social adults.

Yep, and I like it this way.

Worrying about whether or not somebody has an Android is going to be very bad for your mental health given that something like 42% of the US cell phone market is Android. Is it possible that you are living in a bubble of people that are significantly more committed to Apple products than the median person?

I don't live in such a bubble, and whether or not somebody has Apple or Android is not something I have ever heard an adult bring up as a serious thing. The most I've ever seen is as an observation about why some sort of thing in a group chat didn't work, but then everyone moves on with their day and the chat continues with the types of text and media that do work.

You can't compare cores like that.

Take a look at the cache size on the Telum II, or better yet look at a die shot and do some measuring of the cores. Then consider that mainframe workloads are latency sensitive and those workloads tend to need to scale vertically as long as possible.

The goal is not to rent out as many vCPUs as possible (a busines model in which you benefit greatly by having lots and lots of small cores on your chip). The goal for zArch chips is to have the biggest cores possible with as much area used for cache as possible. This is antithetical to maximizing core density, and so you will find that each dual chip module is absolutely enormous, and that each core takes up more area in the zArch chips than in x86_64 chips, and that those chips therefore have significantly less core density.

The end result is likely that the zArch chips are going to have much higher single thread perf. Whereas they will probably get smacked by say a Threadripper on multithreaded workload where you are optimizing for throughout. This is ignoring intricacies about vectorizatiln and what can / can't be accelerated and whether or not you want binary or decimal floating point and other details and is a broad generalization about the two architectural general performance characteristics.

Likewise, the same applies for networking. Mainframe apps are not bottlenecking on bandwidth. They are way less likely to be web servers dishing out media for instance.

I really dislike seeing architectures compared via such frivolous metrics because it demonstrates a big misunderstanding of just how complex modern CPU designs are.

There are really applications that are large enough and hard enough to parallelize and/or shard that any rewrite on a different platform would turn into a performance catastrophe, even if you hired the best engineers and wrote the whole thing in very efficient C++, which you never hear about them doing because its usually only about saving money and so it's done with as cheap of developers as possible and in Java. I've seen it and it's not pretty. They tend to be dog slow and unresponsive, and even harder to maintain than the crusty old assembler and COBOL, because you have to implement a lot of the report writing and record crunching features built into a domain specific language like COBOL from scratch it you want to write the same application in Java.

That's my biggest pet peeve with people that want to ditch mainframes, which is that they seem to care very little about the quality and performance of the software in my experience or they would only be thinking of replacing COBOL and Assembler code with an equivalently performant modern language and dialect. The desire to migrate is often driven primarily to have cheap, easily replaceable developers.

Yeah the architectures focus on different things. The huge caches on the z series chips are designed primarily around the kind of latency sensitive workloads more common in finance than the massive floating point throughput often needed for big scientific computing.

They aren't the best, they are different, and the best in certain areas. In terms of cache size they are way out in front. That architecture has very very fat cores. That's the main thing that makes them different (not better or worse) than something like x86_64, is the focus on single thread performance and cache rather than more cores. If you have a transaction processing app that you can't shard and that scales mostly with single thread perf, then they are pretty well suited for that use case.

The legacy workloads are in some sense legacy, but in another sense the term legacy is misleading because at larger shops with capacity growth there has been no shortage of modernization of the various frontends and addition of new logic into the existing programs. The application maybe has the same name and core business as it always has, but is still growing in size and under active development. The idea now is that you might as well do the same thing and build in AI inference to those existing applications. Which is something they started implementing first with the last generation Telum chip which added some basic tensor units. This time around they are adding vector extensions 3 (think round 3 kinda like how AVX evolved) and that tensor processing extension 2 to the instruction set. Plus they are selling a discrete chip now that uses those same instructions and connects over PCI, which will probably be more than enough given that the goal is to never train on mainframes and only inference.

I'd expect them to be significantly better than the competition in that area given the large part of the CPU that is a dedicated coprocessor specifically for crypto (called CPACF). There is much less area given to crypto on x86_64.

Of course we are talking about encryption here. TLS and AES etc etc. Not Bitcoin mining, which would indeed not be very cost effective.

While new processes don't often get created for mainframes (most of the tasks it is particulary suited for have already been automated by this point, and the market of companies doing those tasks is pretty statics) outside of bolting on more modern interfaces to existing backend, one thing that is often ignored in answering the "why mainframes" question is that the overall amount of compute being done on the platform continues to increase. The same old batch and transaction processing programs get fitted with shiny web frontends and more and more business gets sent to those same old programs. So you can end up in a situation where mainframes remain a very stable business that is worth investing in for future upgrades, even while they become more and more "niche" in the eyes of most computer users over time as the number of computers increases at a faster rate than mainframe capacity increase, so the ratio of computer capacity to mainframe capacity is going up, therefore mainframe capacity is growing substantially while also making up less percent of a larger market over time. Then of course there are the margins, which are much higher than they are for x86_64 servers or other common architecture. A slow and steady increase in demand, mixed with outstanding margins, makes for a good business plan.

Many of the big existing mainframe customers already have multiple max capacity models and are pushing them to their limits as web and analytics and AI/ML and a bunch of other factors increase the overall amount of workload finding their way to mainframes. IBM wouldn't be making those brand new generations of 4-frame models with a new larger max capacity if there weren't customers buying them.

My theory: every (I'm exaggerating, more like most) systems programmer in the company was told to join Azure or get cut. Then outsourcing or something. It's been obvious that they don't have many experienced people left to work on native windows stuff for a while now. The constant churn in the platform apis and everything getting turned into a web app was the sign.

There are an enormous number of people such as myself that work in tech and believe the same exact thing.

At the end of the way we dont need to argue about this. The truth should be empirically knowable. If it's as useful as people say, it will show up in the GDP numbers (I wonder what's taking it so long...).

Lmao

Do you have any examples?

False equivalency and you know it.

Asimov is probably my least favorite major science fiction author (that I've read a significant number of works from).

Something about his worldview always seemed off to me, although I didn't know he actually seriously held such utopian convictions about AI. It explains an awful lot of the way his stories are.

Gotcha. That makes a lot more sense. I was led to believe by the wording of the comparison that they were the same operations. Appreciate the explanation.

Reading the press release about the "Hypercomputer" and I can't tell what part of this is real and what part is marketing.

They say it comes in two configuration, 256 chips or 9,216 chips. They also say that the maximal configuration of 9,216 chips delivers 24x the compute power of the world's largest supercomputer (which they say is called El Capitan). They say that this comes to 42.6 exaFLOPs.

This implies that the 9,216 chip configuration doesn't actually exist in any form in reality, or else it would now be the world's largest supercomputer (by flops) by a huge margin.

Am I massively misunderstanding what the claims being made are about the TPU and the 42.6 exaFLOPs? I feel like this would be much bigger news if this was fully legit.

Edit: The flops being benchmarked are not the same as regular supercomputer flops.

The only way to keep standards high is to cease using degrees solely as class indicators and stop requiring a bachelor's degree for the overwhelming majority of white collar jobs (that we all know don't need the specific knowledge from the degree or else the required degree would be more specific, and that we also know the degree doesn't indicate work ethic necessarily, go look at the people working much harder precisely because they don't have a degree, if anything the degree serves as a license to slack off like the upper class so).

Otherwise the potential downside of not graduating with at least a bachelor's degree is so devastating that the population (who don't want to be perpetually responsible for their adult children that have been made unemployable in any decent capacity for no reason other than to make certain email job people feel important) will accept nothing less than a pass rate approaching ever closer to 100%.

If you want to make education rigorous, you have to address that problem and then also try to address the K-12 education system that faces a similar but more extreme version of the same issue (because not being able to properly read and write are genuinely bad indicators for the majority of white collar jobs, and failing to graduate high school tends to indicate fundamental issues in that respect moreso than failing to graduate with a bachelor's, which usually just indicates immaturity / lack of money / boredom / a million other things that don't imply missing fundamental skills).

Every project handles this differently, and because of the huge variety of environments and potential build complications in comparison to pretty much every other language, I think it would be very hard to get a supermajority of the C and C++ communities in agreement on a package manager.

That being said, there are package managers like vcpkg and conan that work just fine. They will just never be ubiquitous like pip or npm or cargo. Projects are going to continue to want to manage these sorts of issues themselves in a lot of circumstances.

For new projects on a supported platform, I'd recommend going ahead and just using vcpkg. But that's just my opinion. And there is code I work on where that wouldn't be possible. Plus some people just don't like the things that package managers tend to encourage.

The two sides are never going to understand each other because I suspect we work on entirely different things and have radically different workflows. I suspect that hackernews gets more use out of LLMs in general than the average programmer because they are far more likely to be at a web startup and more likely to actually be bottlenecked on how fast you can physically put more code in the file and ship sooner.

If you work on stuff that is at all niche (as in, stack overflow was probably not going to have the answer you needed even before LLMs became popular), then it's not surprising when LLMs can't help because they've not been trained.

For people that were already going fast and needed or wanted to put out more code more quickly, I'm sure LLMs will speed them up even more.

For those of us working on niche stuff, we weren't going fast in the first place or being judged on how quickly we ship in all likelihood. So LLMs (even if they were trained on our stuff) aren't going to be able to speed us up because the bottleneck has never been about not being able to write enough code fast enough. There are architectural and environmental and testing related bottlenecks that LLMs don't get rid of.

Yeah, probably the second one.

This is based on a common fallacy that people believe about CVEs vs. what actually gets exploited. I would go back and read the papers that got you so aggressively on board the memory safety train one more time and see if you can't detect motivated reasoning.

Red Hat has been more consistently pro GPL and pro open source and invests more money into it than any other company.

Them putting the downloads of their enterprise OS behind a login screen (student and solo developer licenses can STILL be got for free) is something I 100% understand and am kind of sympathetic about.

I know that's out of like with how some people define free software, but I've always had ethical issues with the way people would redistribute Red Hats work for free. Just because it's legal doesn't make it ethical.

I agree. He's by far my favorite "very YouTube famous" programmer and it isn't even very close.