[omniORB] OmniORB 3.0.2 on HP-UX 10.20 using gcc 2.95.2 and Python 2.0

Sai-Lai Lo S.Lo@uk.research.att.com
19 Feb 2001 17:20:35 +0000


Sorry about that. I thought I had check-in the change ages ago.
Its now in the CVS.

Sai-Lai


>>>>> Gary D Duzan writes:

>    Thanks, Kelly. That certainly is a big help. (I knew I should
> have kept that email when it came around the first time.) With this
> patch I get the following numbers on the same D380/2:

> single long:     10.3134191036
> octet sequence:  13.3104820251
> octet array:     13.1148051023
> short sequence:  16.6849160194
> short array:     16.4069149494
> long sequence:   16.4646189213
> long array:      15.8890680075
> ulong sequence:  60.6779190302
> ulong array:     60.305529952
> ulong sequence:  61.1681330204
> ulong array:     60.4791320562
> double sequence: 17.1504479647
> double array:    17.4159419537
> double sequence: 17.275316
> double array:    17.3659479618

> which isn't quite as good as the F50, but a lot better than it was.
>    Sai-Lai, can we get the patch from your email
> < http://www.uk.research.att.com/omniORB/archives/2000-12/0150.html >
> included in CVS? Thanks.

> 					Gary Duzan
> 					Verizon Laboratories



> In Message <JIECKDBAPAALDEKDDKJCMEAKCEAA.Kelly@tradebotsystems.com> ,
>    "Kelly Burkhart" <Kelly@tradebotsystems.com> wrote:

> =>Gary,
> =>
> =>There was a thread on the list back in December (search for "BOA vs POA
> =>Performance") that may be relevant.  I believe the issue had to do with with
> =>poor performance on HPUX 10.20 when using either poll() or select().
> =>
> =>-K
> =>
> =>> -----Original Message-----
> =>> From: owner-omniorb-list@uk.research.att.com
> =>> [mailto:owner-omniorb-list@uk.research.att.com]On Behalf Of Gary D.
> =>> Duzan
> =>> Sent: Monday, February 19, 2001 9:40 AM
> =>> To: Gary D. Duzan
> =>> Cc: Sai-Lai Lo; Manning, Kevin J; omniorb-list@uk.research.att.com
> =>> Subject: Re: [omniORB] OmniORB 3.0.2 on HP-UX 10.20 using gcc 2.95.2 and
> =>> Python 2.0
> =>>
> =>>
> =>> In Message <200102162213.f1GMDDL21931@duzanmac.gte.com> ,
> =>>    "Gary D. Duzan" <gdd0@gte.com> wrote:
> =>>
> =>> =>In Message <3owvb1m4qc.fsf@neem.uk.research.att.com> ,
> =>> =>   Sai-Lai Lo <S.Lo@uk.research.att.com> wrote:
> =>> =>
> =>> =>   If you are using Python 2.0, you can configure it like so:
> =>> =>
> =>> =>./configure  --without-gcc --with-cxx=/opt/aCC/bin/aCC
> =>> =>
> =>> =>and get a Python that works fine with omniidl and omniORBpy. It
> =>> =>passes all the type tests, though the performance tests have yet
> =>> =>to get past single longs on my D380/2. I'm not sure what is going
> =>> =>on in this case.  It isn't even taking up much CPU on either end.
> =>>
> =>>    Well, it turns out that it was actually working, but really
> =>> slowly.  Here are the times for the D380/2:
> =>>
> =>> single long:     2133.982566
> =>> octet sequence:  2100.00085998
> =>> octet array:     2104.16265702
> =>> short sequence:  2100.00274491
> =>> short array:     2146.62288201
> =>> long sequence:   2173.43311608
> =>> long array:      2100.01218307
> =>> ulong sequence:  2100.01479495
> =>> ulong array:     2100.01278603
> =>> ulong sequence:  2100.00914299
> =>> ulong array:     2100.01274097
> =>> double sequence: 2164.44086409
> =>> double array:    2100.01282108
> =>> double sequence: 2175.59187698
> =>> double array:    2114.03310108
> =>>
> =>> while an IBM F50 332Mhz*2 manages:
> =>>
> =>> single long:     5.64780700207
> =>> octet sequence:  9.23118901253
> =>> octet array:     9.17841303349
> =>> short sequence:  11.5316530466
> =>> short array:     11.4707759619
> =>> long sequence:   11.7409770489
> =>> long array:      11.5227389336
> =>> ulong sequence:  29.3214819431
> =>> ulong array:     29.2938150167
> =>> ulong sequence:  28.4953149557
> =>> ulong array:     28.5983029604
> =>> double sequence: 13.2012829781
> =>> double array:    13.0320450068
> =>> double sequence: 12.9045649767
> =>> double array:    12.853118062
> =>>
> =>> on a single machine, and roughly twice the time on average between
> =>> two F50s.  If the D380 is either client or server, it seems to be
> =>> taking time comparable to the run on the D380 itself.
> =>>    Just a "heads up" for anyone looking at trying to do lots of
> =>> calls on an HP. Note that this is with HP-UX 10.20. I would hope
> =>> that 11.0 would perform better.
> =>>
> =>> 					Gary Duzan
> =>> 					Verizon Laboratories
> =>>
> =>>
> =>>
> =>>
> =>



-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND