Joseph Kowalski wrote: > John Plocher wrote: > > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > > This information is Copyright 2008 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > Switch SPARC GNU coreutils+bash from 32 to 64bit > > 1.2. Name of Document Author/Supplier: > > Author: Roland Mainz > > 1.3 Date of This Document: > > 30 May, 2008 > > 4. Technical Description > > > > gisburn: Does it require an ARC case if we switch the GNU coreutils > > from 32bit to 64bit on SPARC only (no changes in interfaces > > and > > delivered files)? > > plocher: It doesn't sound like this has any architectural > > implications... > > gisburn: Not that I am aware of. > > plocher: so, I'd say that this was the entire arc review :-) > > > > 6. Resources and Schedule > > 6.4. Steering Committee requested information > > 6.4.1. Consolidation C-team Name: > > SFW > > 6.5. ARC review type: Automatic > > 6.6. ARC Exposure: open > > Sorry, I want a fast-track.
<rant>Could you please write a two-page justification with minimum 2000 words, please ?</rant> Actually I hoped to get this done this weekend - which will be likely the only free time to get it done in the next couple of weeks. If it can't be done this way then the likely only course of action is to withdraw the case since noone can work on it (because there is no time and the nerves of the person who actually wanted to work on it are completely ruined and likely noone will assign official engineering time to such an "unimportant" project (which is together with the build flag cleanup and the fixing of the dbx -check access bugs in coreutils mainly "janitor" work)). BTW: A while ago there was the question: Why is Sun so slow with adopting changes for packages or adding new stuff to SFW ? Maybe one part of the answer is: Because even small things are discussed to death, hell and beyond (just an experience of the other ARC case where I had to write 229 emails, two hours of IRC discussion and two phone calls, effectively ruining two working days). For Linux they just look at the change, document it and DO IT (and that's the reason we're using "auto-approved+automatic" for this ARC case). > 1) I believe this is an incomplete project. What's good for GNU coreutils > is also good for the rest of the utilities. The source of the > utilities doesn't > matter. > > Project completeness is always an arc concern. Why do you want that I want to do _all_ utilities in one piece ? It's technically impossible to do so for a volunteer, even for me. I can handle the utilities (including testing, code review, RTI etc.) step-by-step but certainly not all in one step. > 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC > weren't any faster than 64-bits (so why support both?). Since we have > unsupported any 32-bit SPARC hardware, the change could be made > now. However, validation needs to be done that this doesn't result in > performance regression. (Should be faster on an x86 - its all about > the number of registers, not the data path.) This is a C-team (PAC?) > issue, but it should be considered. We had that discussion already. The issue is: Most of the tools in GNU coreutils are so small that the statistical noise generated by the |fork()|+|exec()|-overhead is bigger than any regressions in performance. From ksh93 we already know that the difference is barely measureable on an Ultra1/143MHZ machine running Solaris 8... and somehow I doubt it changed a lot for Solaris 11. And IMO the benefits of having updated build flags (e.g. C99/XPG6 conformance), having no 256FD limit, a larger ARG_MAX and other increased limits greatly outwheights any concerns about statistical noise in the performance data (I've tested so far "bash" and it's not worse than ksh93). However I don't have time to test each indivisual tool for performance data - I can do the test suite tests and manual testing required for putback - but doing anything beyond requires to make this a fully-blown internal project (for which there aren't engineering resources). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
