John Plocher wrote: [snip] > [I'm attaching Richard's original mail since it was only sent to > opensolaris-arc and probably didn't get into the case mail log] > > Richard L. Hamilton wrote: > > I can think of three main categories of capacity limits on 32-bit that might > > be higher on 64-bit: > > * file size max of 2GB > > * register size and usage > > * available address space, and therefore amount that can be mmap()'d at once > > (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > > > AFAIK, only where the address space is an issue is 64-bit all that > > beneficial > > on SPARC. > > ... > > The file size limit can be lifted on 32-bit with large file support > > (lfcompile(5)). > > The register usage can be altered in an often helpful way by compiling with > > -xarch=v8plus. Even the stdio problem could be circumvented (using AT&T > > SFIO in place of libc stdio), although that may be an architectural no-no > > for > > now. > > Roland: Could you respond to Richards comments - it may be that by using > large file support you could get the behavior you want - on both x86 and > SPARC.
Largefile support wasn't the goal since 32bit applications in Solaris may have largefile support, too. Mainly the ideas/goals were: -- snip -- - No problem with dates >= 2030 (64bit |time_t|) - High-resolution timestamps by default - Stack would be non-executable by default - ARG_MAX would be larger (twice the size), therefore allowing applications to deal with much more data (note this extra memory is mapped via |mmap()|-like calls and only reserves the size, not actually allocate it (reserved address space != real memory usage)). - "bash" supports arrays and it would be nice that we don't limit the array content to 2GB -- snip -- And just to log it here: The long-term goal is to make both OS/Net and SFWNV "64bit clean", e.g. that we can support hardware which only supports a 64bit mode and no 32bit support (for at least one Solaris port we know that the porters were _forced_ to invent artificial 32bit support to work aound the problem that OS/Net is not 64bit clean (which is IMO an unimaginable abdomination (IMO this comes right after putting kittens into the microwave))). I only wanted to start the journey through the code and picked "GNU coreutils" and "bash" as easy targets to begin this long-term work (but it turned-out that this issue has poisoned teeth, claws, salvia, breathes fire and has 32bit-style heads which only accept 64bit proposals as diet). [snip] > With a 64-bit system, you shouldn't be stuck with a 32-bit limit just > because someone might have a 32 bit system that behaves differently. > Isn't that why we developed 64 bit systems in the first place? Isn't > that why we are doing the OpenSolaris thing - to find and fix these kinds > of problems? Another issue is that OS/Net and SFWNV aren't 64bit clean which prevent Solaris from being ported to 64bit-only hardware. The problem is _known_ since the first 64bit support was added for Solaris 7 and I _finally_ want to start a small project to crawl over the sources and kill the problem. And IMO the _obvious_ solution to prevent this issue in the future is to make the matching binaries 64bit by default if the kernel is 64bit-only. [snip] > Last I heard, unless there was some benefit to be gained, 64-bit was usually > _slower_ on SPARC than 32-bit (unlike x86, where all the extra registers > are a big help), due to larger address constants meaning more data to fetch > (and less effective use of cache?), etc. It would be the pointer size... however the amount of data shuffeled around for pointers depends on how the application works internally. And in the case of "GNU coreutils" and "bash" IMO doesn't matter since a) the difference between 32bit and 64bit is _barely_ measureable and b) AFAIK noone cared about performance of these tools in the past (otherwise such a person would've found a very obvious issue with the build flags already (and it seems I'm the first one who really ran benchmarks and tries to fix the problem)) > I can think of three main categories of capacity limits on 32-bit that might > be higher on 64-bit: > * file size max of 2GB > * register size and usage > * available address space, and therefore amount that can be mmap()'d at once > (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > AFAIK, only where the address space is an issue is 64-bit all that beneficial > on SPARC. Erm... that's not correct. The ideas where more like this: -- snip -- - No problem with dates >= 2030 (64bit |time_t|) - High-resolution timestamps by default - Stack would be non-executable by default - ARG_MAX would be larger (twice the size), therefore allowing applications to deal with much more data (note this extra memory is mapped via |mmap()|-like calls and only reserves the size, not actually allocate it (reserved address space != real memory usage)). - "bash" supports arrays and it would be nice that we don't limit the array content to 2GB -- snip -- > The file size limit can be lifted on 32-bit with large file support > (lfcompile(5)). > The register usage can be altered in an often helpful way by compiling with > -xarch=v8plus. Erm... small correction: -xarch=v8plus cannot safely be mixed with other sparcv7 code in all cases (nor was the width of registers an issue here). > Even the stdio problem could be circumvented (using AT&T > SFIO in place of libc stdio), although that may be an architectural no-no for > now. Why ? Technically I would strongly prefer to use an ARC contract for |libast::stdio| than trying to deal with |libc::stdio| if I hit such limits (the reason is simply performance - the libast version of stdio outperforms libc's stdio in all benchmarks and scales a lot better for large amounts of FDs). > A cursory glance at the programs in question suggests that not all of them > would have any use for a larger address space; those could probably receive > all the benefits (and not the possible performance drawbacks) of 64-bitness > by just being built with large file support and compiled as v8plus. Umpf... "GNU coreutils" and "bash" are only two packages which cannot be split into smaller pieces without pain. And "sparcv8plus" won't help a lot since it#s still 32bit and has no access to a larger addressspace, 64bit timestamps or other items listed above. > Where that would be sufficient to reach maximum capacity limits, I think > performance testing of large file+v8plus versus v9 (64-bit) should be > considered, > to avoid regression. See my other email about performance regressions. Compared to the current 32bit versions we will likely improve the situation by fixing the build flags. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
