MathGroup Archive 2008

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

Search the Archive

Re: Re: Mathematica 7 is now available

  • To: mathgroup at smc.vnet.net
  • Subject: [mg94244] Re: [mg94217] Re: Mathematica 7 is now available
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Tue, 9 Dec 2008 06:55:48 -0500 (EST)
  • References: <gg62p3$56g$1@smc.vnet.net> <gh8hkr$r1d$1@smc.vnet.net> <ghavsp$ock$1@smc.vnet.net> <200812081121.GAA15802@smc.vnet.net>

Jon Harrop wrote:
> Michael Weyrauch wrote:
>> Hello,
>>
>>> Parallelism is used when performance is important. In general,
>>> Mathematica is used when performance is largely unimportant.
>>> Consequently, they are almost mutually exclusive.
>> This is a strange statement, which I hardly understand. First of all, in
>> many of my numerical calculations performance is important (e.g. solving
>> large sets of coupled differential equations) and Mathematica compares
>> rather well with compiled languages (in a few cases I can compare with
>> compiled code which does the same calculations as my Mathematica code)
>>
>> Within such calculations often linear algebra routines are used, which
>> where parallalized in Mathematica even before Version 7, and, of course
>> it makes a big difference if your Computer has just one or more
>> processors available. So compared to compiled languages with programs
>> that are not parallelized (which is often the case) Mathematica may even
>> have an advantage.
> 
> Yes, and that is true of any task where Mathematica already bundles a decent
> implementation that you can simply invoke. However, it is not true in
> general.
> 
>>> For example, you would need to parallelize the following Mathematica
>>> program perfectly across 700,000 CPU cores to obtain performance
>>> comparable to the equivalent OCaml program:
>> I don't know OCaml.
> 
> This is not specific to OCaml. Here are equivalent implementations of that
> program in C++, Java, OCaml, SML, Scheme, Lisp and Haskell and all well
> over 100,000x faster than the Mathematica I gave (and many are more concise
> as well!):
> 
>   http://www.ffconsultancy.com/languages/ray_tracer/

I do not understand this claim that the speed difference is 5 orders of 
magnitude. Some experiments indicate 3, perhaps.


>> Therefore, could you elaborate a bit how this tremendous difference comes
>> about and under what conditions?? 
> 
> Mathematica programs are only competitively performant when the bottleneck
> is one of Mathematica's internal routines (FFT, Schur decomposition,
> regular expressions etc.). Optimizing Mathematica code largely entails
> reimplementing your code in such a way that stress is moved onto these
> internal functions even if that is objectively inappropriate (e.g. in the
> case of the recent example on this list with the subject "Floating-Point
> Computing").
> 
> If you cannot express a solution to your problem in such a way then
> Mathematica's performance is likely to be dire, often up to a thousand
> times slower than a compiled language. The program I gave hits several of
> Mathematica's inefficiencies and, consequently, it takes days to compute
> instead of seconds.
> 
> I highly recommend learning when these performance issues are likely to
> arise because you can save a huge amount of time by developing from scratch
> in a performant language when you know performance will be important.

If you have code that is readily written in a compiled language, it is 
certainly the case that it will run faster there than in an interpreted 
language. Probably much faster. So yes, that would be the route to take.

Some modest improvements to the original Mathematica code, though, bring 
it to maybe 2 orders of magnitude of the OCaml speed. In the variant 
below, I make sure everyone is a machine real number or machine integer, 
whichever is appropriate. I use Compile on RaySphere. There are a few 
other tweaks for general efficiency (some might apply to the OCaml 
implementation, I'm not sure).

delta = Sqrt[$MachineEpsilon];
inf = 100000.;
neglight = Normalize[{1., 3., -2.}];
nohit = {inf, {0., 0., 0.}};

Clear[RaySphere, Intersect, Create, RayTrace, Main];

RaySphere = With[{inf = inf}, Compile[
     {{c, _Real, 1}, {o, _Real, 1}, {d, _Real, 1}, {r, _Real}},
     Module[{v = c - o, b, disc, t},
      b = v.d;
      disc = b^2 - v.v + r;
      If[disc < 0., inf,
       disc = Sqrt[disc];
       If[b > disc, b - disc,
        t = b + disc;
        If[t < 0., inf, t]]]]]];

Intersect[o_, d_, ln : {lambda_, n_}, List[c_, r_]] := Block[
   {lambda2 = RaySphere[c, o, d, r]},
   If[lambda2 >= lambda, ln, {lambda2, c}]]

Intersect[o_, d_, ln : {lambda_, n_}, List[c_, r_, s_]] := Block[
   {lambda2 = RaySphere[c, o, d, r]},
   If[lambda2 >= lambda, ln,
    Fold[Intersect[o, d, #1, #2] &, ln, s]
    ]
   ]

RayTrace[o_, d_, scene_] := Block[
   {lambda, n, g, p},
   {lambda, n} = Intersect[o, d, nohit, scene];
   If[lambda >= inf, 0.,
    n = Normalize[o + d*lambda - n];
    g = n.neglight;
    If[g <= 0., 0.,
     {lambda, n} =
      Intersect[o + lambda d + delta n, neglight, nohit, scene];
     If[lambda < inf, 0., g]]]]

Create[level_, c_, r_] :=
  Block[{obj = List[c, r^2]},
   If[level == 1, obj,
    Block[{a = 3*r/Sqrt[12], Aux},
     Aux[x1_, z1_] := Create[level - 1, c + {x1, a, z1}, 0.5 r];
     List[c,
      9*r^2, {obj, Aux[-a, -a], Aux[a, -a], Aux[-a, a], Aux[a, a]}]]]]

prepareTable = Compile[{{n, _Integer}, {s, _Integer}},
    With[{nss = N[s]},
     Flatten[
      Table[Normalize[{(x + s1/nss)/n - .5, (y + s2/nss)/n - .5,
         1.}], {s1, 0, s - 1}, {s2, 0, s - 1}, {y, 0, n - 1}, {x, 0,
        n - 1}], 1]
     ]];

Main[level_, n_, ss_] :=
  Block[{scene = Create[level, {0., -1., 4.}, 1.], nss = N[ss]},
   scene = MapAll[Developer`ToPackedArray, scene];
   Total[Map[RayTrace[{0., 0., 0.}, #, scene] &,
      prepareTable[n, ss], {3}], 1]/nss^2]

In[22]:= Timing[ff512 = Main[9, 512, 4];]
Out[22]= {1542.27, Null}

At this point, it might make sense to use ParallelMap instead of Map, in 
Main.

Daniel Lichtblau
Wolfram Research


  • Prev by Date: Re: Plotting a large dataset
  • Next by Date: Re: Re: Clever Tricky Solutions
  • Previous by thread: Re: Mathematica 7 is now available
  • Next by thread: Re: Mathematica 7 is now available