Re: cxx performance

From: Nic Clews (sendspamhere_at_127.0.0.1)
Date: 06/17/03 

Date: Tue, 17 Jun 2003 10:28:39 +0100

Johan Nilsson wrote:
>
> Yes, the real performance lies in execution, but when executing the TDD
> cycle of continuously writing unit tests-> compiling -> linking -> running
> tests -> writing tests ... an ever so slight performance drop results in a
> grand total of much lost productivity over a day. Sorry to say.

Understood, I/we have folks in exactly the same position.

> That is also the reason I compared _debug_, _non-optimized_ builds, because
> that is what I work with most of the time.during development. So the
> compiler should not be having such a hard time finding the best
> optimizations. I assume that you are being sarcastic about comparing
> executable sizes, so I won't comment on that one.

Slightly sarcastic :-)

OK, I'm not a compiler expert or engineer but there was a point missed
in my original post, and I'll try to add some more explanation. I'm wary
overloading a post with detail when it may not be aimed at the right
level.

> > I expect that Itanium compilations will take even longer, because the
> > compiler is going to spend time looking for parallelism.
>
> For _optimized_ builds, yes, that is likely. However, the CPU horsepowers
> are increasing - so I wouldn't bet my shoes (?) on that.

I mean comparatively longer. CPU speeds are increasing yes, and now
peripheral devices are slipping behind.

> > It is possible for someone experienced in performance to tune a system
> > as a compilation engine. If you want some parity, I'd switch off the
> > default write caching in XP. Some folks I know got a huge performance
> > boost in compilations using the XFC features of 7.3 of VMS over 7.1, so
> > I don't believe you're really on a level playing field here. When was XP
> > released? And 7.1?
>
> If you really want to compare - how about comparing how much time the
> operating systems have had to mature. Windows NT was originally released
> in -93 (IIRC) as Windows NT 3.1 - which makes XP/NT ten years old. When was
> VMS originally released? But then again, this is not very interesting to
> me - I was looking for ways to speed up the compilation in the current
> envíronment.

My point here is around the file systems. XP has a fair amount of
optimization added. The executive of 7.3 is leaner with a read cache
*but no write back cache* as with XP.

I suggest you need a read cacher, on 7.1 you'll have to buy in a caching
product, but free trials of the software are available. Do this only
after the following advice.

We are talking tuning this system as a compilation engine, you've
already mentioned adjusting a few parameters but here's a few
suggestions in that area. Increase channelcnt and fillm, make the
wsdefault and wsquota the same big size as allowable by the memory you
have (observation required). For the file system, increase the values of
extend size, make sure highwater marking is off, make sure the
cxx$startup file has been run, use bypass privilege (controversial!)

Use AUTOGEN FEEDBACK data to size up some of the variables, bump up the
ACP (sic) caches, with only 1 or 2 disks, mount /processor=unique to
keep the caches separate.

This is by no means exhaustive, and I would also add individual
circumstances may vary, others will have different but possibly equally
effective ideas of tuning up.

I'd suggest observing MONITOR MODES during your compilation, no idle
time and 50 to 75% user mode and I don't think you'll get much better
out of the system. Any idle time would suggest that the IO system could
be holding things up, low user mode (and no idle) would suggest
operating system overhead is excessive. 

-- 
Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences
nclews at csc dot com

Relevant Pages

  • Re: cxx performance
    ... Surely compilation is a one-off process, ... Yes, the real performance lies in execution, but when executing the TDD ... If you really want to compare - how about comparing how much time the ... operating systems have had to mature. ...
    (comp.os.vms)
  • Re: huge array
    ... or do you know a CPU which can handle something like "FOR I = 1 TO ... The dot net JIT compilers *do* interpret pseudo code (or whatever ... parsing and execution are two separate steps. ... compilation happens in two phases ...
    (microsoft.public.vb.general.discussion)
  • Re: huge array
    ... or do you know a CPU which can handle something like "FOR I = 1 TO ... There is a huge difference between interpeted code and native code. ... parsing and execution are two separate steps. ... compilation happens in two phases ...
    (microsoft.public.vb.general.discussion)
  • RfD: FOUND
    ... The output value flag is zero if _name_ has the default compilation ... execution in interpret state MAY be or not be reported as not found. ... retrieve an xt, with C/SEM. ...
    (comp.lang.forth)
  • Re: huge array
    ... It alwasy has been run as native code. ... |> transformed from plain VB code or from any other language, ... parsing and execution are two separate steps. ... | stage of compilation - which is the generation of IL (a binary, ...
    (microsoft.public.vb.general.discussion)