[illumos-Developer] Need short help with testing { sed, tr, pax } replacement binaries on i386 ...

[I. Szczesniak]

On Sat, Aug 7, 2010 at 12:23 AM, Garrett D'Amore <garrett at damore.org> wrote:
> I am starting to think I may need to arbitrate here.  Is that needed?

Not yet. I only asked Joerg to check his numbers because the real
world numbers in my company, General Electric Healthcare, contradict
Joerg's findings. Either our IT development department or Joerg did
measure wrong.

>
> "I. Szczesniak" <iszczesniak at gmail.com> wrote:
>
>>On Fri, Aug 6, 2010 at 11:46 AM, Joerg Schilling
>><Joerg.Schilling at fokus.fraunhofer.de> wrote:
>>> Roland Mainz <roland.mainz at nrubsig.org> wrote:
>>>
>>>> On Fri, Aug 6, 2010 at 12:30 AM, Joerg Schilling
>>>> <Joerg.Schilling at fokus.fraunhofer.de> wrote:
>>>> > Roland Mainz <roland.mainz at nrubsig.org> wrote:
>>>> >
>>>> >> I've uploaded a first _test_ version of the { /usr/bin/sed,
>>>> >> /usr/xpg4/bin/sed, /usr/bin/tr and /usr/bin pax } replacement binaries
>>>> >> for i386 to http://www.nrubsig.org/people/gisburn/work/solaris/illumos/posixcore20100701_i386_001.tar.bz2
>>>> >
>>>> > I recently posted a list of bugs for astpax. As this tar archive seems to refer
>>>> > to a time before the bug report, it is most unlikely that the reported bugs
>>>> > have been fixed. Missing POSIX compliance is a big problem.
>>>>
>>>> Erm... it would be nice to see the list of POSIX/SUS violations. The
>>>> code has been tested by Sun and then AT&T a month ago and they did not
>>>> find any POSIX violations except three bugs in the VSC test suite (Don
>>>> Cragun has IMO the final comment on these three issues) ...
>>>
>>> Roland, I send you a mail kindliy adking for test binaries and sources on
>>> Wednesday 28th but did never get a reply from you.
>>>
>>> Last Sunday, Olga posted a URL for recent sources and I used this as a base for
>>> testing. I send a test report on Monday to the mailing list.
>>>
>>> A short summary:
>>>
>>> astpax is the slowest known implementation (it typically needs 3-5x the amount
>>> of user CPU time than star) and it seems to ignore POSIX.1-2001 related
>>> information (metadata) in the archive. As a result, it may even get out of
>>> sync with the archive, depending on the content of the archive meta data.
>>>
>>> As a matter of curiosity, astpax (with high optimization) needs 100x the amunt
>>> of user CPU time to create a verbose listing for a POSIX.1-2001 archive and it
>>> needs 19x the wall clock time than star for this operation. Your unoptimized
>>> version mentioned above needs ~ 210x the amount of user CPU time than star and
>>> 33x the wall clock time used by star for the same operation. To help comparing
>>> these numbers: /usr/bin/pax (the otherwise slowest from the list star gtar
>>> /usr/bin/pax) needs 2x the amount of user CPU time than star and 1.3x the
>>> amount of wall clock time.
>>
>>Joerg, would you kindly check your setup, please? Your numbers
>>contradict our findings and real world performance observations on our
>>production machines. Our observation is that AST pax is faster than
>>star (and a lot more mature, too) and not the opposite as you've
>>claimed.
>>Something is wrong.
>>
>>Irek
>>
>>_______________________________________________
>>Developer mailing list
>>Developer at lists.illumos.org
>>http://lists.illumos.org/m/listinfo/developer
>

Irek