Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Hardware Is Software

octoml.ai

Post reply on HN
Print view View original

11–20 of 35 posts

Re: The Future of Hardware Is Software

#11

Post by xscott »

aidenn0 wrote: post #9
xscott wrote: post #7

Earlier quoted context omitted.

There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. To me, there is a spectrum of parallelism on the desktop: multi-server, multi-process, multi-threaded (shared mem), , SIMD instructions Yeah, Itanium might have…

> There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. DSPs (which have great perf/watt for the numerical algorithms you mention) have used VLIW for decades, so of course there is a place for it. GPUs have moved in…

Yeah, there's a whole other universe of specialized chips for special purposes, and I used PCI-style DSP cards when I could. I just think a standard VLIW on the desktop/server would've been useful for the stuff I'm interested in.

GPUs can definitely carry that load, but I avoided them in my career because I could rarely guarantee that my customer's computers would have a sufficient GPU. In the world where I worked, x86 and AMD64 became standard - I could always count on that. It had to be a pretty special project for my customers to let me dictate a dedicated rack of specific hardware was required.

> Intel and HP had hundreds of smart people trying to solve the "software problem" of Itanium and they did not succeed.

Yeah, but that's tied up in the market too. A big name customer screaming, "But I don't want to retrain my programmers, it has to work with Java/C++" would certainly sway them from a Verilog or Cuda style language. Hell even OpenCL and Cuda have to look like C++. Double hell, the FPGA folks have been trying to make a C++-like language for decades so that they can increase their market. That doesn't mean another possibility couldn't exist for Itanium.

It's very clear that Itanium is dead. Maybe I'm just saying the market was foolish, and you're saying Intel/HP couldn't satisfy the market.

Re: The Future of Hardware Is Software

#12

Post by synergy20 »

It already is, every hw/chip designer is pretty much a software engineer coding in verilog(c-like), all testbench/verification is also pure software, designer normally uses powerful CAD software daily, the hardware part for many designers are minimal.

the true hardware is those who design the boards (PCB), which, before COVID, was mostly outsourced to China, I'm unsure if this "hardware" will ever move back.

Re: The Future of Hardware Is Software

#13

Post by xscott »

jdsully wrote: post #10
xscott wrote: post #7

Earlier quoted context omitted.

There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. To me, there is a spectrum of parallelism on the desktop: multi-server, multi-process, multi-threaded (shared mem), , SIMD instructions Yeah, Itanium might have…

>A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. There are already DSPs for this purpose, but typical server workloads don't generally use those algorithms. Perhaps Itanium would have made a good DSP but it wasn't really aimed at that market.

> There are already DSPs for this purpose

I should've been more clear: Most open source projects, or my projects for the customers I used to have, can't/couldn't rely on a DSP chip or card being installed. If Itanium had gone mainstream, I could've counted on it's VLIW instructions.

We can /almost/ count on a GPU nowadays, but programming in Cuda ties you to NVidia, and OpenCL doesn't seem to have taken off the same way.

> Perhaps Itanium would have made a good DSP but it wasn't really aimed at that market

I suspect there are a lot of FFTs, SVDs, and large matrix multiplies in software now. Deep learning, convolutional nets, image and audio algorithms, TikTok "filters", and so on. Of course there was almost none of that on desktops in the late 90s.

Re: The Future of Hardware Is Software

#14

Post by tw04 »

Ahh, yes, back to 2010 when everyone told companies like Hitachi they were doing storage wrong by relying on custom ASICs.

Meanwhile Google and Facebook and Amazon are making hardware offload engines because they've figured out there's a limit to the performance of general purpose CPUs and it's a lot of wasted power.

You can't have it both ways, efficiency and speed or flexibility, choose one.

Re: The Future of Hardware Is Software

#15

Post by deepnotderp »

xscott wrote: post #7
aidenn0 wrote: post #6

> A classic example is Itanium: it is only a historical footnote today, but Itanium’s explicit parallelism and focus on scalability once made it look like the future of CPUs. The problem was never the hardware itself—it was difficult compilation and backward compatibility with the x86 software ecosystem that doomed Itanium. The problem with the Itanium was the hardware itself. Finding sufficient ILP on general purpos…

There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. To me, there is a spectrum of parallelism on the desktop: multi-server, multi-process, multi-threaded (shared mem), , SIMD instructions Yeah, Itanium might have…

Itanium got maximum penetration in HPC, so people were aware of this. The challenge is that GPUs and DSPs (many are VLIW) are even better at parallel.

Re: The Future of Hardware Is Software

#16

Post by deepnotderp »

xscott wrote: post #7
aidenn0 wrote: post #6

> A classic example is Itanium: it is only a historical footnote today, but Itanium’s explicit parallelism and focus on scalability once made it look like the future of CPUs. The problem was never the hardware itself—it was difficult compilation and backward compatibility with the x86 software ecosystem that doomed Itanium. The problem with the Itanium was the hardware itself. Finding sufficient ILP on general purpos…

There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. To me, there is a spectrum of parallelism on the desktop: multi-server, multi-process, multi-threaded (shared mem), , SIMD instructions Yeah, Itanium might have…

Also, it’s worth noting that OoO brings more than just ILP/scheduling, it also brings MLP and dynamism. Take for instance latency hiding a cache miss or a mispredicted branch. Stuff like this is impossible to know in advance, no matter how much you redesign your language to expose ILP.

Re: The Future of Hardware Is Software

#17

Post by msandford »

And the future of software is hardware. Which way is the pendulum swinging now? From which perspective? Why?

If you've been around for a swing or two this is nothing new. If not, it's earth shattering.

Anyone remember thick clients, then thin clients, and now thick clients again? Anyone want to guess when mobile-first starts becoming web-first?

Re: The Future of Hardware Is Software

#18

Post by karmakaze »

I don't buy this inevitable future where the best software runs on the best hardware because that's obviously optimal. How many times has history played out that way vs large entities entrenched in their moat of hw, sw, or a mix?

I mean what's the closest that we have to a good example, maybe ARM hardware running Linux? What about mobile, we have Android Open Source Project which is a bit early to see what it will amount to. I still hope and wait, but wouldn't bet on it.

Re: The Future of Hardware Is Software

#19

Post by metadat »

metadat wrote: post #5
fxtentacle wrote: post #2

"The Future of Hardware Is Software" ... says everyone that wants to sell you AI software on commoditized hardware. Yet here I am, I recently won an AI competition by reviving an old 2005 algorithm and just using the fact that compute power has 7000x-ed since then (from 5 GFLOPS on a P4 to 35 TFLOPS on a 3090). No AI was needed. And now I'm building custom electronics for a new type of 3D camera because even after ye…

You're such a tease! Seriously, please share the deets on this 2005 "junker" algo. It was super unsatisfying to read your post with so much interesting information glossed over.

FYI fxtentacle, people keep upvoting this comment- there seems to be enormous interest, it's already at +17.

Will be sad if we never hear from you.

Re: The Future of Hardware Is Software

#20

Post by wahern »

aidenn0 wrote: post #9
xscott wrote: post #7

Earlier quoted context omitted.

There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. To me, there is a spectrum of parallelism on the desktop: multi-server, multi-process, multi-threaded (shared mem), , SIMD instructions Yeah, Itanium might have…

> There are a lot of important numerical algorithms which would have really benefited if Itanium had gone through iteration and growth. A mainstream VLIW could've had it's place, and it's trivial to find parallelism in FFTs, SVDs, matrix multiplies, and so on. DSPs (which have great perf/watt for the numerical algorithms you mention) have used VLIW for decades, so of course there is a place for it. GPUs have moved in…

> Intel and HP had hundreds of smart people trying to solve the "software problem" of Itanium and they did not succeed.

I've also heard a contrary story that Intel and HP simply assumed the compilers would show up, or at least failed to put in sufficient effort to advance the industry. I'm curious if you have any sources. I've always wondered what the true story was, though neither need be mutually exclusive.

It would seem foolhardy for Intel and HP not to heavily invest in compiler research given the stakes. OTOH, the norm seems to be for hardware vendors to suck at deliberately building and evolving software ecosystems around their hardware, especially as commodity hardware and open source software became ubiquitous. And "sufficient effort" is definitely a matter of opinion.

By way of example, early examples of polyhedral compilation go back to the 1990s, but it wasn't until the 2010s that implementations shipped in GCC and clang, long after Itanium failed. I doubt it would have saved Itanium, but I would have expected to see such contributions earlier and coming directly from Intel and HP. But maybe my expectations are too high.

Post reply on HN