LuaJIT 2.1 Profiler released

#1

Post by qwertzlcoatl » Wed, Sep 11, 2013, 9:20 AM UTC

LuaJIT 2.1 Profiler released
permalink.gmane.org

Re: LuaJIT 2.1 Profiler released

#2

Post by otikik » Wed, Sep 11, 2013, 9:55 AM UTC

This. Is. Awesome.

Re: LuaJIT 2.1 Profiler released

#3

Post by acqq » Wed, Sep 11, 2013, 9:59 AM UTC

The most interesting conclusions of Mike Pall reflect my experiences: sampling profilers are often much more usable in practice than instrumentation:

As you might have noticed, I had to change my plans compared to the original approach presented in June. The main problem with the instrumenting profiler was finding high-precision and high-speed timing sources for all platforms. (...) The necessary pipeline flushes shadowed the actual timings up to the point where the measurements were less accurate than with a sampling profiler! Other platforms offered only inaccurate timing sources or none that are accessible from user mode. And to top it off, the instrumentation added considerable overhead. (...) I had to scrap that work and decided to go with a sampling profiler.

And I don't know any other scripting language with a built-in sampling profiler. Does anybody?

Re: LuaJIT 2.1 Profiler released

#4

Post by rustc » Wed, Sep 11, 2013, 10:06 AM UTC

Slightly off-topic, but does anyone know how I can download the complete mailing list archive data (of luajit)? Many of Mike's posts are very informative and useful, and I'd like to be able to search/read them easily, offline.

Re: LuaJIT 2.1 Profiler released

#5

Post by illumen » Wed, Sep 11, 2013, 10:14 AM UTC

acqq wrote: post #3

The most interesting conclusions of Mike Pall reflect my experiences: sampling profilers are often much more usable in practice than instrumentation: As you might have noticed, I had to change my plans compared to the original approach presented in June. The main problem with the instrumenting profiler was finding high-precision and high-speed timing sources for all platforms. (...) The necessary pipeline flushes sha…

python

Re: LuaJIT 2.1 Profiler released

#6

Post by vmind » Wed, Sep 11, 2013, 10:16 AM UTC

acqq wrote: post #3

The most interesting conclusions of Mike Pall reflect my experiences: sampling profilers are often much more usable in practice than instrumentation: As you might have noticed, I had to change my plans compared to the original approach presented in June. The main problem with the instrumenting profiler was finding high-precision and high-speed timing sources for all platforms. (...) The necessary pipeline flushes sha…

V8?

Re: LuaJIT 2.1 Profiler released

#7

Post by zeckalpha » Wed, Sep 11, 2013, 11:38 AM UTC

rustc wrote: post #4

Slightly off-topic, but does anyone know how I can download the complete mailing list archive data (of luajit)? Many of Mike's posts are very informative and useful, and I'd like to be able to search/read them easily, offline.

Either use NNTP, or http://gmane.org/export.php

Re: LuaJIT 2.1 Profiler released

#8

Post by pjmlp » Wed, Sep 11, 2013, 11:44 AM UTC

acqq wrote: post #3

The most interesting conclusions of Mike Pall reflect my experiences: sampling profilers are often much more usable in practice than instrumentation: As you might have noticed, I had to change my plans compared to the original approach presented in June. The main problem with the instrumenting profiler was finding high-precision and high-speed timing sources for all platforms. (...) The necessary pipeline flushes sha…

Smalltalk? Lisp?

Re: LuaJIT 2.1 Profiler released

#9

Post by camperman » Wed, Sep 11, 2013, 11:49 AM UTC

LuaJIT is a work of great beauty and efficiency. I've been working on a commercial product for small ARM boards where rapid prototyping has been essential because of ever changing requirements but the speed of the finished code is also paramount. LuaJIT has made this project an absolute pleasure. It wraps C libraries cleanly, it runs within 5-10% of native code speed on the ARM (I checked because I didn't believe it at first) and it's 100% compatible with all the Lua 5.1 supporting libraries I need. This new profiler will be a great addition to the toolbox along with ZeroBrane Studio's debugger which I just discovered this week and which also rocks.

Mike Pall needs several Jolt Awards.

Re: LuaJIT 2.1 Profiler released

#10

Post by barrkel » Wed, Sep 11, 2013, 12:31 PM UTC

acqq wrote: post #3

The most interesting conclusions of Mike Pall reflect my experiences: sampling profilers are often much more usable in practice than instrumentation: As you might have noticed, I had to change my plans compared to the original approach presented in June. The main problem with the instrumenting profiler was finding high-precision and high-speed timing sources for all platforms. (...) The necessary pipeline flushes sha…

Sampling for CPU performance, instrumentation for control flow analysis and memory allocation.

The distortion effect of measurement is higher with instrumentation, and is the chief reason I prefer sampling when trying to find performance problems.

But finding CPU performance issues is far from the only reason for using a profiler.