Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2007
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Slow Show/Graphics in v6.0

  • To: mathgroup at smc.vnet.net
  • Subject: [mg81095] Re: Slow Show/Graphics in v6.0
  • From: Mark McClure <mcmcclur at unca.edu>
  • Date: Wed, 12 Sep 2007 03:46:55 -0400 (EDT)
  • References: <200709050653.CAA26889@smc.vnet.net> <fc4iac$eh5$1@smc.vnet.net>

From: Alex Shvydky <ashv at lle.rochester.edu>
> Here is my side of this whole issue.
> ...
> We, here at the lab, have our own legacy code and
> we do not expect to re-optimize it every time
> Intel releases their new C/FORTRAN compiler, since
> it works on the same code usually faster. We do
> not have either time or desire to rewrite and
> reoptimize our Mathematica routines that have been
> working acceptably fast for the past several
> years.

I think you've raised some interesting points and 
thinking through your examples has clarified some
things in my mind, so I really do appreciate your
comments and input.  Ultimately, however, I think
I disagree with your main tenet that V6 is across
the board, orders of magnitude slower than V5.2 -
particularly, if you are unwilling to try any new
approaches to the code. 

I can understand your frustration with the legacy
code issue, but Mathematica is not C or Fortran.  
It is much higher level and has many more built in
tools.  It is also much newer, evolving much more 
rapidly and the step from V5.2 to V6 is a 
particularly big one.  So I guess I don't find
the C/Fortran comparison very compelling.

> BTW, the Graphics optimization that you mentioned
> ("wrapping a large number of Points or Lines in a
> single head") also speeds up the V5.2 code, such
> that V5.2 code is still an order of magnitude
> faster than the V6.0 code:

This is just false.  The syntax I am referring to
is not understood by V5.2.  Perhaps I should try 
to be more clear.  Try the following in V5.2:

pts = Table[Random[], {10000}, {2}];
t1 = AbsoluteTime[];
Show[Graphics[Point /@ pts]]
t2 = AbsoluteTime[];
t2 - t1

On my MacBook Pro, I get an image in about 0.1
seconds.  If I try the exact same code in V6,
indeed it takes just over 5 seconds.  If I
replace the "/@" with just "@", however, it
takes 0.002 seconds - quite a bit faster than
V5.2.  In 5.2, this syntax is incorrect.

> Now, here is another trivial example:
> Timing[
>   mr = 500;
>   mt = 500;
>   xar = Table[((ir - 1.)/(mr - 1.))*
>     Cos[Pi*((it - 1.)/(mt - 1.))], 
>     {it, 1, mt}, {ir, 1, mr}];
>   yar = Table[((ir - 1.)/(mr - 1.))*
>     Sin[Pi*((it - 1.)/(mt - 1.))], 
>     {it, 1, mt}, {ir, 1, mr}];
> ]
> It takes 0.56 seconds in V5.2 and 4.703 seconds
> in V6.0 (Why???? What now, is it the "front-end" again?)

No, this is a PackedArray issue.  You can tell
by executing the following:
Developer`PackedArrayQ[xar]

V5.2 returns True, while V6 returns False.
PackedArrays are largely handled internally
and, evidentally, the rules as to when a 
PackedArray is automatically returned are a
bit different.  Perhaps a design flaw, although
I would immediately make that judgement, since
I don't know all the considerations that went
into the decision.  


Incidentally, try setting mr=mt=249 and compare
timings.  Or try setting mr=mt=1000 and multiply
by a symbolic expression inside the Table.  You'll
then find that the timings are quite comparable.
Essentially, this slows 5.2 by forcing it to not
use PackedArrays.  You can similarly speed up
the V6 code by forcing it to use PackedArrays.

Mark


  • Prev by Date: NIntegrate preprocessing and rule selection
  • Next by Date: Re: Anomolous behaviour of Penrose Triangle Demonstration
  • Previous by thread: Re: Slow Show/Graphics in v6.0
  • Next by thread: Re: Slow Show/Graphics in v6.0