I think you have a valid point Alex. While it is true that the example
code you presented is not optimized, the simple fact that it runs much
slower in v6.0 vs. v5.2 is just not right. I am concerned that something
has changed to reduce the fundamental performance of the kernel in some
areas. Unfortunately, I don't have my previous v5.1 installed anymore.
Otherwise, I would be doing some serious benchmarking on my own. I might
even reinstall 5.1 for this purpose (my concern is potential conflict
when installing a prior version after installing 6.0). I hope WRI is
taking note of this thread.
David
Alex Shvydky wrote:
> Hello Bobby,
>
> Thanks for your input.
> Actually, I did try the modifications that you suggested.
> The peace of code I provided was for illustration purposes only
> (I will just have to keep reiterating it over and over again).
> I was not soliciting the advice on how to modify this particular piece =
of
> code (thought I do appreciate your time!). My intention was to
> get the confirmation (and hopefully draw WR team's attention)
> that THE SAMPE CODE runs on v6.0 considerably slower than in v5.2.
>
> I was aware that the direct integration of fonebeam function in V6.0 is=
> faster
> than in v5.2 (which is a great thing). In actuality, my "fonebeam" is r=
ead
> in from the file where it is defined as a table; it is not an analytic
> function!
>
> An no, I can't try it in Fortran or C in 30 minutes!
> That is the reason I started using Mathematica in early 90th
> in the first place. I just would not want it become so sluggish
> that it would be useful only for toy problems and to make
> beautiful plots for presentation purposes.
>
> Frankly, I am quite surprised that some of the forum members
> treat these horrible slow downs as something that should be expected
> and accept it rather than voice their concern.
>
> Thanks,
> Alex
>
> DrMajorBob wrote:
>> I suspect (just guessing) that you meant to set finterp equal to the
>> Interpolation in your Table; that way the code could actually do
>> something. But the Interpolation only wastes time (in version 6):
>>
>> profr[r_, s_] = E^(Log[0.05]*r^s)
>>
>> \[ExponentialE]^(-2.99573 r^s)
>>
>> fonebeam[th_, s_] = profr[Sin[th], s]*Max[0, Cos[th]]
>>
>> \[ExponentialE]^(-2.99573 Sin[th]^s) Max[0, Cos[th]]
>>
>> lmax = 10;
>> Timing[saved = Table[
>> NIntegrate[
>> fonebeam[th, s]*LegendreP[#1, Cos[th]]*Sin[th], {th, 0, Pi},
>> MaxRecursion -> 16] & /@ Range[0, lmax], {s, 1.9, 3., 0.02}];]
>>
>> {27.453, Null}
>>
>> Timing[saved2 =
>> Table[finterp =
>> Interpolation[({#1, fonebeam[#1, s]} &) /@
>> Range[0, Pi, Pi/(30.*lmax)]];
>> NIntegrate[
>> finterp[th]*LegendreP[#1, Cos[th]]*Sin[th], {th, 0, Pi},
>> MaxRecursion -> 16] & /@ Range[0, lmax], {s, 1.9, 3., 0.02}];]
>>
>> {33.609, Null}
>>
>> saved - saved2 // Abs // Max
>>
>> 2.02138*10^-7
>>
>> In version 5.2 the timings were 18.5 and 3.1 seconds, so Interpolation=
>> DID speed things up, and 5.2 does seem faster. (But not unless you
>> write the code correctly, of course.)
>>
>> Back in v6, you can eliminate fonebeam and its Max[0, Cos@th] this way=
:
>>
>> Timing[saved = Table[
>> NIntegrate[
>> profr[th, s]*LegendreP[#1, Cos[th]]*Sin[th], {th, 0, Pi/2},
>> MaxRecursion -> 16] & /@ Range[0, lmax], {s, 1.9, 3., 0.02}];]
>>
>> {6.953, Null}
>>
>> Can you really try all these things in C or Fortran, in the 30 minutes=
>> I spent?
>>
>> Bobby
>>
>> On Fri, 07 Sep 2007 01:04:29 -0500, Alex Shvydky
>> <ashv at lle.rochester.edu> wrote:
>>
>>> Thanks for the input, Ricardo.
>>>
>>> They should do something with that. Currently I am running both 5.2 a=
nd
>>> v6.0 side by side
>>> and for now most of the code is noticeably slower in 6.0! To the poin=
t
>>> it is not usable anymore.
>>> (Of course I could spent couple of days to optimize its etc. etc., bu=
t
>>> then it would defeat
>>> the purpose of using Mathematica in the first place - I would rather
>>> then do it in Fortran
>>> or C...)
>>>
>>> Like e.g.
>>>
>>> profr[r_, s_] := E^(Log[0.05]*r^s);
>>> fonebeam[th_, s_] := profr[Sin[th], s]*Max[0, Cos[th]];
>>> lmax = 10;
>>> Table[
>>> Interpolation[({#1, fonebeam[#1, s]} &) /@ Range[0, Pi,
>>> Pi/(30.*lmax)]];
>>> NIntegrate[finterp[th]*LegendreP[#1, Cos[th]]*Sin[th], {th, 0, Pi=
},
>>> MaxRecursion -> 16] & /@ Range[0, lmax],
>>> {s, 1.9, 3., 0.02}];
>>>
>>> took 3.78sec in Mathematica V5.2 and 39.97sec in V6.0.
>>>
>>> There is again an order of magnitude slow down!
>>>
>>> I am observing this across the board. Whatever the "improvement" they
>>> introduce in
>>> my view can not justify an order of magnitude slow down!
>>> I hope they work on that and v6.xx will be faster.
>>>
>>> It is like a new version or a C or Fortran compiler would come with 1=
0
>>> times larger libraries and features,
>>> but the code it would generate from your old programs would run 10 ti=
mes
>>> slower.
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>> Ricardo Samad wrote:
>>>> Dear Alex,
>>>>
>>>> I confirm that some graphic functions rendering became slower in
>>>> Mathematica 6.0.
>>>> I am having a similar problem when trying to display a 480 x 640 dat=
a
>>>> array using ListContourPlot or ListPlot3D; In Mathematica 5.2 it too=
k
>>>> a few seconds, in 6.0 it takes minutes, and eventually the Kernel
>>>> hangs.
>>>> I also would like to know if there=C2=B4s a setting to speed the
>>>> rendering up.
>>>>
>>>> Ricardo Samad
>>>>
>>>>
>>>>
>>>> On 9/5/07, *Alex Shvydky* <ashv at lle.rochester.edu
>>>> <mailto:ashv at lle.rochester.edu>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Just wanted to share my puzzlement (utter disappointment/
>>>> frastration) with a ridiculously slow speed of Show/Graphics
>>>> routines in the v6.0 of Mathematica as compared to 5.2,
>>>> which to me at this point makes v6.0 plain unusable.
>>>>
>>>> Working with hydrodynamic simulations I need to
>>>> visualize the computational grid. So I wrote
>>>> simple Mathematica routines to draw a simulation grid.
>>>> In 5.2 they worked fabulously for the past couple of
>>>> years.
>>>>
>>>> Here's an example.
>>>> First, set up two 2dimensional x- and y-coordinate
>>>> arrays.
>>>>
>>>> Timing[
>>>> mr = 350;
>>>> mt = 350;
>>>> 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}];
>>>> ]
>>>>
>>>> In v6.0 it took
>>>> Out[3]= {2.312, Null}
>>>> In v5.2 it took
>>>> {0.281 Second, Null}
>>>>
>>>> Which is an order of magnitude difference, but hold on.
>>>> Now let's plot the mesh by simply constructing table
>>>> of edges of all the cells (I am aware that the algorithm
>>>> below is very unoptimized and can be made faster etc. etc.
>>>> It was not my intention to discuss here what should be the
>>>> fastest algorithm to plot a 2-d mesh,
>>>> nor was it my intention to debate the issue why one
>>>> would need to plot such a large mesh in the first place...,
>>>> but rather to compare the execution time for an IDENTICAL
>>>> code on v6.0 and v5.2. and get some confirmation/explanation
>>>> of such a suspiciously slow execution speed!).:
>>>>
>>>> Timing[
>>>> Show[
>>>> Graphics[{Hue[ 0.7], AbsoluteThickness[0.1],
>>>> Table[{Line[{{xar[[it,ir]], yar[[it,ir]]},
>>>> {xar[[it,ir + 1]],yar[[it,ir + 1]]},
>>>> {xar[[it + 1,ir + 1]], yar[[it + 1,ir + 1]=
]},
>>>> {xar[[it + 1,ir]], yar[[it + 1,ir]]}}]},
>>>> {ir, 1, mr - 1}, {it, 1, mt - 1}]
>>>> }],
>>>> PlotRange -> {{-1, 1}, {0, 1}}, AspectRatio -> 1/2, Axes -> True=
,
>>>> DisplayFunction -> $DisplayFunction, ImageSize -> 800]]
>>>>
>>>> While the timing as, it is returned by the Timing[] function,
>>>> is smaller in the v6.0:
>>>> {1.703, <Here goes the actual graphics>}
>>>> vs.
>>>> {2.094 Second, -Graphics-}
>>>> in v5.2
>>>>
>>>>
>>>> The actual cell evaluation time in v.6.0 is 124.11 seconds
>>>> vs. 2.22 seconds in v 5.2. ???!!!!!!!
>>>>
>>>> Could anybody please confirm this. Also it would be helpful
>>>> if someone from Wolfram Research would explain if
>>>> that is intended (unavoidable) by design or maybe
>>>> a simple setting (which I am unaware of) or a future patch
>>>> will be able to fix it.
>>>>
>>>> Also, it is horribly slow to resize the above graphics
>>>> in v5.2 you just grab the corned and drag. In v6.0 you
>>>> must do it 10-100 times slower (is it possible
>>>> that I just have a very poor graphics card?).
>>>>
>>>>
>>>> Thanks,
>>>> Alex Shvydky
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ____________________________________
>>>> Ricardo Elgul Samad
>>>>
>>>> tel: (+55 11) 3816-9314
>>>> fax: (+55 11) 3816-9315
>>>>
>>>> Centro de Lasers e Aplica=C3=A7=C3=B5es
>>>> IPEN/CNEN-SP
>>>> AV. Prof. Lineu Prestes 2242
>>>> Cidade Universit=C3=A1ria
>>>> 05508-000
>>>> S=C3=A3o Paulo - SP
>>>> Brazil
>>>> ____________________________________
>>> --
>>> _______________________________________________________________
>>>
>>> Alex Shvydky <ashv at lle.rochester.edu>
>>>
>>> Research Associate
>>> Computational Design Group
>>>
>>> Laboratory for Laser Energetics Office: 1423 COI
>>> University of Rochester Phone: (585) 275-9539
>>> 250 East River Road FAX: (585) 275-5960
>>> Rochester NY 14623
>>> _______________________________________________________________
>>>
>>>
>>>
>>
>>
>