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

Lots of bugs in 32-bit x86 Linux entry code

lwn.net

Post reply on HN
Print view View original

61–70 of 110 posts

Re: Lots of bugs in 32-bit x86 Linux entry code

#61

Post by IvyMike »

srgpqt wrote: post #37
jdsully wrote: post #30

Earlier quoted context omitted.

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

> If anything, we've only learned to squander all available memory.

If I've learned anything in my computer career, it is that this is an evergreen comment. I remember reading Q-Link posts from Commodore 64 users with this complaint when the wasteful C128 came out.

Re: Lots of bugs in 32-bit x86 Linux entry code

#62

Post by tedunangst »

noobermin wrote: post #59
jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

Let's just hope we don't go through the same thing when we switch to 128-bit. We ought to learn from our mistakes when we do this whole thing again. And yes, before people flare me for this, don't pretend it isn't possible, recall that once upon a time 640K ought to be enough for anybody.

Nobody ever thought that, and mindlessly repeating just means we don't learn anything.

Re: Lots of bugs in 32-bit x86 Linux entry code

#63

Post by tedunangst »

mehrdadn wrote: post #55
derefr wrote: post #39

Earlier quoted context omitted.

Go ahead and buffer 4k video streams to disk, I dare you :) There's a reason that even modern appliance platforms like Apple/Android TV need multiple GBs of memory, and it ain't bloat.

What are you calling "disk" here? It's not every day that I see a machine with a disk slower than its network connection.

That might describe every rpi running off SD.

Re: Lots of bugs in 32-bit x86 Linux entry code

#64

Post by cptskippy »

tyingq wrote: post #49
cptskippy wrote: post #16

Earlier quoted context omitted.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

Back then, AMD kind of had to license the x64 stuff to Intel for cross license reasons. They aren't under any pressure this time to give away anything.

Really? When did that change? I thought they had some sort of in-perpetuity cross licensing agreement going back to when AMD was a second source for x86 for Intel with Government contracts.

Re: Lots of bugs in 32-bit x86 Linux entry code

#65

Post by cptskippy »

topbanana wrote: post #23
cptskippy wrote: post #16

Earlier quoted context omitted.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

They've got momentum on their side now, but intel won't bow down without a fight. I expect we'll see some real innovation over the next five years.

The real question isn't if Intel will fight back but how. They've been known to innovate shady marketing tactics just as much as their CPU architecture.

Re: Lots of bugs in 32-bit x86 Linux entry code

#66

Post by tyingq »

cptskippy wrote: post #64
tyingq wrote: post #49

Earlier quoted context omitted.

Back then, AMD kind of had to license the x64 stuff to Intel for cross license reasons. They aren't under any pressure this time to give away anything.

Really? When did that change? I thought they had some sort of in-perpetuity cross licensing agreement going back to when AMD was a second source for x86 for Intel with Government contracts.

Their advantage this time isn't the ISA. There's no "cross licensing" for the silicon design, fab choice, etc.

Re: Lots of bugs in 32-bit x86 Linux entry code

#68

Post by BruiseLee »

jdsully wrote: post #30
gdxhyrd wrote: post #28

Earlier quoted context omitted.

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

Consensus? I would call it dissensus actually.

Re: Lots of bugs in 32-bit x86 Linux entry code

#69

Post by thrower123 »

human_banana wrote: post #3

Maybe because nobody uses 32-bit x86 anymore?

If only... I have been hoping for a native x64 version of Visual Studio for almost a decade, and signs do not look good for that ever coming to fruition. As it is, loading up solutions that consume nearly 2GB of RAM are still bringing the IDE to its knees and making it thrash and page.

Re: Lots of bugs in 32-bit x86 Linux entry code

#70

Post by robothread »

cptskippy wrote: post #16
jdsully wrote: post #5

I remember being an early adopter of 64-bit Linux with my Athlon64 back in the day. Lots of stuff was broken and I got a lot of debate on whether it was any faster or worthwhile at all. It's really cool to see the technology curve go full circle.

Completely off topic but... Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't followup until Ryzen. I wonder if they're going to stick around and fight this time.

Well Intel wasn’t exactly sitting idle during the Athlon 64 era. It was just unfortunate that none of their plans worked out.

NetBurst was a bust. IA-64 flopped too. Both were attempts to progress from the P6 architecture - which they felt had reached its limits.

In the end, the market spoke, they want the P6. No one was willing to rewrite software (or even recompile). So back to the P6 in the form of the Pentium M followed by the Core /Core dual series and finally the i3/5/7/9 that we use today - which you would notice hasn’t improved much per core; as mentioned the P6 style design is pretty much tapped out and all they can do is “squeeze blood from stone” for a few percentage improvements here and there.

AMD recently caught up but frankly, they aren’t doing much better. Performance per core is just on par with Intel. Their main selling point is that they made it cheaper by splitting the L3 cache in 2 - the Ryzen is basically 2 quad-cores glued together for better yields.

Post reply on HN