Hacker News Reader

Comment by ZenoArrow | Hacker News Reader

> "In years past, they'd get maybe one extra product release off each new arch (tick/tock)"

Intel has moved away from the tick/tock release cycle. They now work to what they call process/architecture/optimization, or in more familiar unofficial terms tick/tock/tweak.

Moore's law is essentially broken now, and this isn't just an Intel problem, this is a problem for all the major chip manufacturers. Furthermore, the challenges and cost of future node shrinks is also causing a slowdown in progress in integrated circuit manufacturing. We may get a couple more node shrinks, but we should prepare ourselves for the brick wall that we're likely to hit in the next decade.

View on HN

«They now work to what they call process/architecture/optimization, or in more familiar unofficial terms tick/tock/tweak.»

For this cycle it's been tick/tock/tweak/tweak. Sounds like a broken clock.

As the bitkeeper guy, I'm watching this with amusement. Intel used BitKeeper for over a decade for their RTL and when they used BK things seemed fine. We did everything that Intel wanted, at one point I realized we had taken $7M of revenue from other customers over the years and spent it on doing work for Intel. And that was still not enough for them.

They switched to git because free is better (we were a rounding error on a rounding in terms of cost to Intel, the most they ever paid us in a year is .00000004 of their revenue).

But that was too much so they switched to git and it's been downhill for them ever since.

I'm not an idiot, I don't think that the switch to git is the cause of their problems, their problems are self inflicted. I'm just one of many many vendors that Intel has fucked over. So I like seeing them squirm.

Karma is a bitch Intel.

Edit: yup, knew I'd get down voted. Don't care. Try being an Intel vendor and get back to me about how much you like that.

@luckydude isn't just some random troll.

https://en.wikipedia.org/wiki/Larry_McVoy

McFly's right, if a bit sensational (ehhh, it's his style.)

However, as poorly as they treat their vendors, it's nothing compared to what they do to their employees and sadly large segments of their first line and middle management not only buy into that but have spent time making that into an art form.

What do they do to their employees?

Ask them to sign NDAs.

I don't really get it. You seem to be complaining that a party chooses to no longer be your customer? Isn't it their full right to decide so? What makes discontinuing a business relationship more "fucking you over" than you "fucking over the supermarket" by choosing to go to another supermarket?

Looking at CVs, everyone knows git. Using anything else would require not just licence costs. Also training and potentially reducing the pool of possible hires.

BK predates Git by quite a while. The free alternatives then were sccs, cvs, rcs, etc.

That doesn't change anything. Older or not, people use git.

It seems unfair that you are taking it out on Intel for dropping your product-- when in fact, the entire industry dropped your product. Git is free, more widely supported, open-sourced, and doesn't get angry when a user stops using it. Technology evolves - best not to pick at old scabs.

Because you came up randomly with your disappointment absolutely unrelated to today's topic, I'm tempted to give you another unrelated news: the Linux project has stopped using Bitkeeper too.

This is super uncalled for.

I could go into details about how they screwed us but that is perhaps a thread of its own. We bitch slapped them at the end when I finally grew a pair (after years and years of just doing whatever they wanted).

If you are an Intel vendor you will like this tidbit, they were on our paper. Not their agreement, they agreed to our paper. I think we are the only small vendor that they ever did business with where they didn't force their terms into the deal.

In some ways it's been closer to tick/tock/tweak/tweak/tweak, which is just another sign that improving process nodes isn't something that we should rely on anymore.

For this cycle the 'tick' (Cannon Lake) was pushed back a year (with two 'tweaks', Kaby Lake Refresh and Coffee Lake, taking its place). Cannon Lake devices are due to be released to the mass market this year, and according to Intel it was able to manufacture some Cannon Lake devices last year:

https://en.wikipedia.org/wiki/Cannon_Lake_(microarchitecture...

"At CES 2018 Intel announced that they had started shipping mobile Cannon Lake CPUs at the end of 2017 and that they would ramp up production in 2018."

The present evidences show that one should not trust Intel announcements. They may ship CPUs based on their 10nm process, but it is not clear that they managed to resolve all their yield issues.

If Mores law could be broken, mabe the continued economic growth is in danger too?

unlikely to be linked... increasing cache or writing better algorithms will make things faster...

Many industries are held back by lack of interoperability, rather than raw computer power.

> "increasing cache or writing better algorithms will make things faster"

There are performance ceilings on those as well. Best case scenario we come up with a new architecture that is more efficient than the current ones (something built around reconfigurable chips could be ideal). However, we will eventually reach a point where computers don't get significantly faster. Maybe it takes 20 years, maybe it takes 30 years, but there will come a point where that happens.

> However, we will eventually reach a point where computers don't get significantly faster.

Help me understand why. Even if individual computational units cannot get faster, can we not benefit from additional computational units? I know that these don't scale linearly but I suspect there remains work that can be done to improve scaling. Isn't that where GPUs get their computational power?

tons of algorithms and software don't run any faster with more cores. Plus each core has a n+1 cost associated with it, whereas with how scaling worked previously you got better performance for cheaper because of size decreases.

The most significant cost in making an ASIC is the silicon wafer, which is extremely expensive, so anything that uses it more efficiently [ less space] makes things cheaper, faster (easier to keep a faster clock synced over a small area), and use less power (less power means you can go faster too, because you have more power/head headroom for cranking clock speeds).

Scaling by going smaller is extremely synergistic, and has super exponential performance impact, whereas in the very best case adding more cores is linear, and in almost every real world case, sub linear. It also costs more, not less.

The fact is baring major breakthroughs, we are stuck with roughly today's level of performance for the foreseeable future.

>The fact is baring major breakthroughs, we are stuck with roughly today's level of performance for the foreseeable future.

Maybe finally we stop wasting hardware and use the supercomputers we have in our pockets for greater things.

Another thing to consider is that memory access is still the most prevalent speed problem. If we can work on these bottlenecks we can still get significant performance increases without actually increasing CPU performance that much.

> tons of algorithms and software don't run any faster with more cores.

> The fact is baring major breakthroughs, we are stuck with roughly today's level of performance for the foreseeable future.

That's obviously false. Otherwise graphics wouldn't get any faster when you add more GPU cores, to name one common embarrassingly parallel problem.

Our software is just really bad at making use of those extra cores. Measure real-world use cases with a well-tuned work stealing engine and you'll see how much performance we're leaving on the table.

(Source: I wrote the first version of possibly the largest consumer deployment of a major software component backed by a work stealing engine.)

> "Isn't that where GPUs get their computational power?"

GPUs get their power from being able to execute multiple calculations in parallel. Rendering a 3D scene is something that lends itself to being processed in parallel, for example on a simple level you can have different cores each rendering a different section of the overall image (tile-based rendering is one example of an approach that benefits from this: https://en.wikipedia.org/wiki/Tiled_rendering ).

The GPGPU uses of GPUs (i.e. non-graphics uses) also take advantage of this parallel processing power.

The issue is, not all computing workloads are easy to split up into smaller workloads that can run in parallel. Some workloads are easiest to manage sequentially. For example, consider some code that had a lot of conditional logic (such as "if" statements), where the code executed depended on validating a condition was met. What advantages would you gain from running this code in parallel?

Reply on news.ycombinator.com