|
|
Manish Chakravarty wrote:
>
>
> On Feb 12, 2008 11:44 PM, Ananth Shrinivas <Ananth.Shrinivas@xxxxxxx
> <mailto:Ananth.Shrinivas@xxxxxxx>> wrote:
>
> Hi Manish,
>
> Answers to a few of your questions:
>
> > I am looking for an Opteron based box with 8GB of RAM ( Saw one good
> > configuration for around 25k )
> >
> > Since Nevada userland is 32bit, would it be able to address all
> of the
> > 8GB of RAM or like Windows XP , only the first 4GB will be used?
>
> Since the kernel is 64 bit, you will be able to access all of your
> 8GB.
> In fact even the 32 bit unix kernel can access the entire 8GB
> because of
> the x86 Physical Address Extensions (PAE) (See:
> http://www.x86.org/articles/2mpages/2mpages.htm). It doesn't matter if
> the app is 32 bit or 64 bit since the app is only concerned with its
> Virtual Address Space and both the 32 and 64 bit kernels can see
> all of
> your physical address space.
> > know Ubuntu 64bit can access and utilize all of my 8 gigs if
> needed (
> > But Ubuntu , like all 64 bit Linux distros has full 64bit userland).
> > I am confused because Nevada userland is 32 bit but the kernel is
> > 64bit ( on machines which have 64bit capable CPU's )
> >
> > Two more questions:
> > 1) How does this work? ( 64bit kernel and 32 bit userland; could
> some
> > explain in a little detail?)
> >
> > 2) Why does Nevada not ship with full 64bit userland?
> > I understand #2 would break binary compatibility for 32bit apps.
>
> Nevada userland has a mix of both 32 and 64 bit apps. Take sort
> for example:
>
> $ file /usr/bin/sort /usr/bin/i86/sort /usr/bin/amd64/sort
> /usr/bin/sort: ELF 32-bit LSB executable 80386 Version 1 [FPU],
> dynamically linked, not stripped, no debugging information available
> /usr/bin/i86/sort: ELF 32-bit LSB executable 80386 Version 1
> [FPU],
> dynamically linked, not stripped, no debugging information available
> /usr/bin/amd64/sort: ELF 64-bit LSB executable AMD64 Version 1
> [SSE2
> SSE FXSR CMOV FPU], dynamically linked, not stripped, no debugging
> information available
>
> $ ls -li /usr/bin/sort
> 1763 -r-xr-xr-x 95 root bin 8048 Jan 13 07:26 /usr/bin/sort
>
> $ ls -li /usr/lib/isaexec
> 1763 -r-xr-xr-x 95 root bin 8048 Jan 13 07:26 /usr/lib/isaexec
>
> The /usr/bin/sort is a hard link to /usr/lib/isaexec which decides on
> the fly whether to execute the 32 bit (i86) version or the 64 bit
> (amd64) version.
>
> But beware, while things like HPC apps, Multimedia Software and
> Databases usually benefit from a 64 bit userland: In other cases with
> data type bloat, address alignment constraints and limited cache
> lines,
> it is not entirely uncommon for 64 bit apps to be slower than their 32
> bit counterparts.
>
>
> I was under the impression that 64 bit applications almost always
> perform better than 32 bit ones.
>
>
> Isnt there another factor involved: the lowest common denominator in
> terms of CPU flags and optimizations while "making" a distro for 32
> and 64 bit CPU's ?
>
> Typically the 64 bit CPU's ( both from the intel and and camp) support
> a lot more instruction sets. ( MMX , SSE2, and all that ), so the
> lowest common denominator is higher than for typical x86/32bit CPUś
>
> Of couse, having compiled ¨ls¨with MMX and SSE2 might not give a huge
> performance benefit, but I am sure compiling libc (and other base
> libs) with fancier flags should boost overall system performance.
Yep having optimized libc is good. That is why OpenSolaris delivers 4
versions of libc:
/lib/libc.so.1 - vanilla without using special instructions
/usr/lib/libc/libc_hwcap3.so.1 - SSE MMX CMOV CX8 FPU
/usr/lib/libc/libc_hwcap1.so.1 - SSE MMX CMOV SEP CX8 FPU
/usr/lib/libc/libc_hwcap2.so.1 - SSE2 SSE MMX CMOV AMD_SYSC CX8 FPU
During boot the capabilities of the processor is detected and the
appropriate libc
overlay mounted over /lib/libc.so.1. Just execute df -h in a
terminal window and
you will be able to see the libc mount.
The script /lib/svc/method/fs-root does all this work.
>
> I am unsure what x86 CPU is the lowest common denominator for Nevada (
> or S10 ) but I know it can run on PIIIś.
> But if we do Belenix for 64 bits, we could use the fancier flags and
> get better performance overall.
For BeleniX the 64Bit components are left out in the LiveCD but are
included
in a 7Zip compressed archive. We don't need to do anything special;
OpenSolaris
already has the optimizations you are talking about.
Regards,
Moinak.
>
> Does my argument make sense?
>
>
> Manish
> ------------------------------------------------------------------------
>
> _______________________________________________
> ug-bosug mailing list
> List-Unsubscribe: mailto:ug-bosug-unsubscribe@xxxxxxxxxxxxxxx
> List-Owner: mailto:ug-bosug-owner@xxxxxxxxxxxxxxx
> List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
>
_______________________________________________
ug-bosug mailing list
List-Unsubscribe: mailto:ug-bosug-unsubscribe@xxxxxxxxxxxxxxx
List-Owner: mailto:ug-bosug-owner@xxxxxxxxxxxxxxx
List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54
|
|