[nylug-talk] LOWMEM vs. HIGHMEM performance advantage?

[Alex Pilosov]

On Sat, 19 Apr 2008, [utf-8] Bryan J Smith wrote:

> rom: Alex Pilosov <alex at pilosoft.com>
> > will strongly disagree. 
> >x86-64 (i will call it x64 and spare me) - is *bad* idea *unless* you
> > *have* to. because pointers are 64-bit,
> 
> Are they now?  Wow! I guess I shouldn't have read those x86-64/IA-32e
> programmer manuals.
> 
> I fully expect an application-level developer to disagree. But anyone
> who has worked at the system level knows this fact ...
> 
> I686: 6 bytes (48-bit segmented)
> X86-64: 6 bytes (48-bit flat)
Blah blah blah.

Bryan, cut the crap, seriously. You do know some things, but you like to 
bring up technical details that absolutely have no relevance to topic 
discussed.

> When paging is the biggest factor in performance, what you speak is
> laughable.
paging isn't biggest factor in performance. sorry, fail. 

> > lots of structures are much larger in size, so your binaries and data
> > are much larger in size, so you blow l2/l3 cache much faster, and use
> > up more memory for same work. in empirical tests, bloat is anywhere
> > between 25% to 50% depending on application.
> 
> You're trying to apply a "from afar" assumption about ALU realities to a
> discussion on paging. This is about paging, not what user-space
> application developers think what is going on.
What the hell does it have to do with ALU. Go take Architecture 101 class 
and find out what ALU is.

> > also, the border is not 1GB. Border is 3GB. 3GB apps work fine with
> > 3/1. split.
> 
> Paging is still in operation beyond 1GB. Your user-space app may not
> have additional overhead itself, but the contact switches very much do.
> If a lot of IPC is going on, and not just system-calls, forget it.
@*(*(@#(*@#

> Context switching tends to be a major factor in performance. Especially
> as you are running a VM like for Java and Python.  It really adds up for
> than this side-assumption you have. Honestly.
What the hell does context switching have to do with anything discussed 
above?!

Are you saying that context switch on 64-bit platform is more expensive 
than 32-bit platform? Or that somehow doing 3/1 split results in more 
expensive context switches than 1/3 split? I have no idea. In either case, 
I call bs.

> Application assumption != to system reality.
> 
> > Kinda apples and oranges. X4 is for large number of cores (32 cores, 8
> > sockets), large amounts of ram (1TB). However, the X4 servers are xeon
> > 7xxx series which are fail compared to 5xxx
> 
> IBM's X4 is creaming the reference-based competition by over 30% in our
> tests with 8-16 cores (2-4 sockets) with 16-32GiB. You don't have to go
> multi-board to see it, Intel's platform sux without help. Luckily IBM
> provides it, leverging Intel's superior ALU/SSE for a great majority of
> applications, while mitigating (or eliminating) the platform
> limitations.
Again, you bringing up irrelevant topics. Go check SPEC benchmarks. 7xxx 
series are far worse (in price AND performance) than 5xxx series. You 
disagree? 

I find it very unlikely that whatever mumbojumbo X4 brings to the table is
able to compensate for ~20% loss you take on 7xxx series. AMD tried
connecting memory closer to chip. That didn't go so well. Intel still
kicked their asses. 

I note that there aren't any SPEC benchmarks of series 460/X4 hardware.  
Wonder why. In fact, the only published benchmark that I can find is for 
TPC/C for a 16-socket series460 hardware.

> > But yes, there are issues with addressing >32-bit in PCI on _some_
> > hardware platforms. I'd like to make a point that it is device and
> > driver specific.
> 
> It's protection-generic.
What does it even MEAN?

> > In fact, your higher-performance hardware is likely to already work
> > fine without bounce buffers. (most scsi controllers and e1000 cards
> > understand this).
> 
> And you're entrusting them to work responsibly. They don't always. ;)
You are on crack.

> Enterprise Linux distros side with that concern for a reason.
Yes, you are on crack. It just works. Nobody cares.

> > Yeah, AMD has hw bounce buffers. Which intel said are not important.
> > Intel was right. Suck it, amd boy.
> 
> Depends on how much I/O you're doing. For home consumers, it's not. For
> web servers, it's not.
> 
> When your grpahics card has 2GiB of frame buffer, it's AMD-only.  Same
> deal when you have serious caching going on in an I/O capability.
Why are you switching from I/O to graphics cards now? I've pointed out 
that bounce buffers are irrelevant, what *else*?

> If it's "not important," then why is Intel working on it? Why does IBM
> address some things in their chipset?
Working on *what* precisely?!

I've shown that serious devices don't have need for bounce buffers. Why
are hardware bounce buffers important again?

-alex