On 3/25/13 10:43 PM, Walter Bright wrote:
> On 3/25/2013 5:02 AM, Rory McGuire wrote:
>> The profiling doc is here:
>> http://blog.golang.org/2011/06/profiling-go-programs.html
>> It is all super easy, and documented so that you can do it now.
>
> What it says about profiling:
>
> "To start tuning the Go program, we have to enable profiling. If the
> code used the Go testing package's benchmarking support, we could use
> gotest's standard -cpuprofile and -memprofile flags. In a standalone
> program like this one, we have to import runtime/pprof and add a few
> lines of code:"
> [... bunch of code you have to copy/pasta in ...]
> "After adding that code, we can run the program with the new -cpuprofile
> flag and then run gopprof to interpret the profile."
>
>
> How to do profiling with the dmd D compiler:
>
> 1. Add the -profile switch to the command line.
>
> 2. Read the report generated.
>
> To do coverage analysis:
>
> 1. Add the -cov switch to the command line.
>
> 2. Read the report generated.
>
> That's it.

We need an article on that.

Andrei

Whether it is Go or D, I wish one of you guys would fill the gap between the numeric work I need to do in fortran and the ui/string parsing/web work/plotting/animating I do in python.

While working in two languages is realistically not a huge deal, it would be nice if there was something that bridged the gap for all of us people out there writing stuff for science so that we could just learn one and be done with it.

the day a D program can begin with "import SciD; import Dplot;", and progress to "matrix.invert();" and "surf(matrix);", I will ditch both python and Go.

I am being incredibly self-serving and am half-kidding on this post since other people use D for all sorts of other things and they probably outnumber me. Still, I would love to see a compiled language implement numeric libraries that worked as fluidly as numpy and matplotlib work with python.

One reason I prefer D over Go is that the D community is so incredibly nice :)

edit: ditch both python and fortran.

That's julia's(http://julialang.org/) goal, but of course it's not nearly polished.

I'm interested in this as well, since I'm not totally comfortable about using a pirated MATLAB version and I hear that numpy can't match its performance on "macro" code.

On Tuesday, 26 March 2013 at 04:11:05 UTC, Geancarlo Rocha wrote:
> That's julia's(http://julialang.org/) goal, but of course it's not nearly polished.
>
> I'm interested in this as well, since I'm not totally comfortable about using a pirated MATLAB version and I hear that numpy can't match its performance on "macro" code.

I have heard of Julia and have not really messed with it yet for the reason you mentioned (it being in its early stages).

I used MATLAB for a about a year before switching to numpy full time. I would totally recommend it. The performance loss (which I am not sure is actually there in all problems being solved) is really not that big of a deal unless you are doing some pretty heavy math, in which case MATLAB is slow compared to using C or fortran anyway. Another great thing is that numpy shares a lot of the same syntax as MATLAB, so the switch is fairly painless.

If it were just numeric stuff, fortran would work okay (albeit it is a chore). I have a small collection of libraries I have written so I can execute MATLAB-esque commands for creating vectors and doing basic plotting. For example, this works:

call linspace(0, pi, 100, x)
y = sin(x)
call plot2d(x,y)

It's not the cleanest looking thing, but its better than doing it from scratch every time :P

What if I wanted to plot a surface? Well, I need to write another fortran subroutine for that (which I have). The point is, it gets old having to write subroutines to do every little thing. Calculating an exponential integral requires me to link to the SLATEC library while MATLAB will do it with expint(x).

There are so many things that are commonly used in numeric programming and not standard in fortran (or any compiled language). Is there some rule that only scripting languages are allowed to do these sorts of things easily?

I would LOVE to see a compiled language that ran on par with C or fortran and had libraries that executed as cleanly as numpy and matplotlib do.

On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> How to do profiling with the dmd D compiler:
>
> 1. Add the -profile switch to the command line.
>
> 2. Read the report generated.
>
> To do coverage analysis:
>
> 1. Add the -cov switch to the command line.
>
> 2. Read the report generated.
>
> That's it.
>
>
Hi Walter,

Thanks I remember about the -profile switch but I don't see memory usage
there. If you see your program using more and more memory even though it
should not be
how do you check where the problem is?
In Go you generate a graph that shows the relationship between the various
function calls their memory use and cpu time. Its not a flashy graph I
think they use graphviz or something.

What would I use in D to profile heap usage? Would I be able to find the problem area as quickly?

26-Mar-2013 13:38, Rory McGuire пишет:
>
> On Tue, Mar 26, 2013 at 4:43 AM, Walter Bright
> <newshound2@digitalmars.com <mailto:newshound2@digitalmars.com>> wrote:
>
>     How to do profiling with the dmd D compiler:
>
>     1. Add the -profile switch to the command line.
>
>     2. Read the report generated.
>
>     To do coverage analysis:
>
>     1. Add the -cov switch to the command line.
>
>     2. Read the report generated.
>
>     That's it.
>
>
> Hi Walter,
>
> Thanks I remember about the -profile switch but I don't see memory usage
> there. If you see your program using more and more memory even though it
> should not be
> how do you check where the problem is?
> In Go you generate a graph that shows the relationship between the
> various function calls their memory use and cpu time. Its not a flashy
> graph I think they use graphviz or something.
>
> What would I use in D to profile heap usage? Would I be able to find the
> problem area as quickly?
>

What everybody in all other native languages use, for instance:
valgrind --tool=massif, valgrind --tool=callgrind

Any general purpose profiler works.  I can confirm that e.g. AMD CodeAnalyst works just fine if application is compiled with symbols. Intel's Vtune also should work as well as many opensource tools.

-- 
Dmitry Olshansky

On 3/26/2013 2:38 AM, Rory McGuire wrote:
> Thanks I remember about the -profile switch but I don't see memory usage there.

-profile and -cov do not track memory usage.

> If you see your program using more and more memory even though it should not be
> how do you check where the problem is?

I've written memory usage profilers before, but haven't done one for D. You're the first to ask for one.

> What would I use in D to profile heap usage? Would I be able to find the problem area as quickly?

What you can do is use -cov and see how often particular calls to new are done. This will give a pretty good clue as to where memory consumption is coming from.

On 3/26/2013 3:04 AM, Walter Bright wrote:
> On 3/26/2013 2:38 AM, Rory McGuire wrote:
>> Thanks I remember about the -profile switch but I don't see memory usage there.
>
> -profile and -cov do not track memory usage.
>
>> If you see your program using more and more memory even though it should not be
>> how do you check where the problem is?
>
> I've written memory usage profilers before, but haven't done one for D. You're
> the first to ask for one.

Now that I think about it, it wouldn't be that hard to add memory allocated per function when using -profile.

But my larger point is how simple it is to use -cov and -profile; it's hard to imagine it being any easier.

On 2013-03-26 10:49, Dmitry Olshansky wrote:

> What everybody in all other native languages use, for instance:
> valgrind --tool=massif, valgrind --tool=callgrind
>
> Any general purpose profiler works.  I can confirm that e.g. AMD
> CodeAnalyst works just fine if application is compiled with symbols.
> Intel's Vtune also should work as well as many opensource tools.

On Mac OS X there's Instruments. There's also dtrace.

-- 
/Jacob Carlborg