测量执行时间ECLiPSe CLP(或Prolog) [英] Measuring execution time ECLiPSe CLP (or Prolog)

问题描述

如何测量ECLiPSe CLP中方法的执行时间?目前，我有这个:

How do I measure the execution time of a method in ECLiPSe CLP? Currently, I have this:

measure_traditional(Difficulty,Selection,Choice):-
  statistics(runtime, _),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  time(solve_traditional(Difficulty,Selection,Choice,_)),
  statistics(runtime,[_|T]), % T 
  write(T).

我需要写出执行方法 solve_traditional(...)所需的时间，并将其写到文本文件中.但是，它不够精确.对于给定的方法，有时 time 将显示0.015或0.016秒，但通常会显示0.0秒.

I need to write the time it took to perform a method solve_traditional(...) and write it out to a text file. However, it is not precise enough. Sometimes time will print 0.015 or 0.016 seconds for the given method, but usually it prints 0.0 seconds.

弄清楚该方法完成得太快，我决定使用 statistics(runtime，...)来衡量两次运行时调用之间所花费的时间.然后，我可以测量例如完成20个方法调用并将所测量的时间T除以20所花费的时间.

Figuring the method completes too fast, I decided to make use of statistics(runtime, ...) to measure the time it takes between two runtime calls. I could then measure for example the time it takes to complete 20 method calls and divide the measured time T by 20.

唯一的问题是，有20个调用，T等于0、16、32或48毫秒.显然，它分别测量每个方法调用的时间，并找到执行时间的总和(通常仅为0.0s).这超出了测量N个方法调用的运行时间并将时间T除以N的全部目的.

Only problem is, with 20 calls T equals either 0, 16, 32 or 48 milliseconds. Apparently, it measures the time for each method call separately and finds the sum of the execution times (which is often just 0.0s). This beats the whole purpose of measuring the runtime for N method calls and dividing the time T by N.

简而言之:我用于执行时间测量的当前方法是不够的.有没有办法使它更精确(例如9位小数)?

In short: the current methods I'm using for execution time measurements are inadequate. Is there a way to make it more precise (9 decimals for example)?

推荐答案

基准测试在任何编程语言中都是一项棘手的事情，在CLP中尤其如此.特别是如果您打算发布结果，则应该非常透彻，并绝对确保要衡量自己声称要衡量的内容.

Benchmarking is a tricky business in any programming language, and particularly so in CLP. Especially if you plan to publish your results, you should be extremely thorough and make absolutely sure you are measuring what you claim to measure.

计时器::您是在测量实时时间，进程cpu时间，线程cpu时间吗?包括花费在系统调用上的时间?包括还是排除垃圾收集? ...

Timers: Are you measuring real time, process cpu time, thread cpu time? Including time spent in system calls? Including or excluding garbage collection? ...

查看 statistics/2 提供的不同计时器原始. 有一个实时高分辨率计时器，可以通过 statistics( hr_time，T).

See the different timers offered by the statistics/2 primitive. There is a real-time high-resolution timer that can be accessed via statistics(hr_time,T).

计时器分辨率:在您的示例中，计时器分辨率似乎为1/60秒.也就是说，要获得3位有效数字，您必须至少测量1000 * 1/60 = 16.7秒的运行时间.

Timer resolution: In your example the timer resolution seems to be 1/60 sec. That means, to get 3 significant digits in your time measurement, you have to measure at least a runtime of 1000*1/60 = 16.7 seconds.

如果基准测试运行时间太短，则必须多次运行.

If your benchmark runtime is too short, you have to run it multiple times.

运行时差异:在现代机器上，越来越难以获得可重现的时序.这是由于与您正在测量的程序无关的影响，例如缓存行为，分页，上下文切换，电源管理硬件，内存对齐等.

Runtime variance: On modern machines it is increasingly difficult to get reproducible timings. This is due to effects that have nothing to do with the program you are measuring, such as cache behaviour, paging, context switches, power management hardware, memory alignment, etc.

运行足够的重复，在一台安静的机器上运行，确保结果可重复.

Run enough repetitions, run on a quiet machine, make sure your results are reproducible.

重复进行基准测试:在类似ECLiPSe的系统中，必须谨慎地反复运行基准测试，以确保连续运行确实进行相同的计算，并且理想情况下具有相同或相似的缓存和垃圾收集行为.

Repeating benchmarks: In a system like ECLiPSe, running benchmarks repeatedly must be done carefully to ensure that the successive runs really do the same computation, and ideally have same or similar cache and garbage collection behaviour.

在您的代码中，您将结合起来依次运行基准测试.不建议这样做，因为变量实例化，延迟的目标或垃圾可能会从先前的运行中幸存下来，并减慢或加快后续运行的速度.如上所述，您可以使用模式

In your code, you run the benchmark successively in a conjunction. This is not recommended because variable instantiations, delayed goals or garbage can survive from previous runs and slow down or speed up subsequent runs. As suggested above, you could use the pattern

run_n_times(N,Goal) :- \+ ( between(1,N,1,_), \+ Goal ).

本质上是将序列重复N次的方法

which is essentially a way of repeating N times the sequence

once(Goal), fail

这样做的重点是once/1和fail的组合会撤消所有Goal的计算，因此下一次迭代尽可能从相似的机器状态开始.不幸的是，此撤消过程本身会增加额外的运行时间，从而扭曲了测量...

The point of this is that the combination of once/1 and fail undoes all of Goal's computation, so that the next iteration starts as much as possible from a similar machine state. Unfortunately, this undo-process itself adds extra runtime, which distorts the measurement...

测试开销::如果您多次运行基准测试，则需要一个可以为您完成测试的测试框架，这有助于您衡量运行时间.

Test overheads: If you run your benchmark several times, you need a test framework that does that for you, and this contributes to the runtime you measure.

您要么必须确保开销可以忽略不计，要么必须测量开销(例如，通过使用虚拟基准测试运行测试框架)并将其减去，例如:

You either have to make sure that the overhead is negligible, or you have to measure the overhead (e.g. by running the test framework with a dummy benchmark) and subtract it, for example:

benchmark(N, DummyGoal, Goal, Time) :-
    cputime(T1),
    run_n_times(N, DummyGoal),
    cputime(T2),
    run_n_times(N, Goal),
    cputime(T3),
    Time is (T3-T2)-(T2-T1).

CLP细节:CLP求解器中还存在许多其他特定于数据驱动操作的考虑因素，这些因素使CLP运行时很难进行比较.这些求解器在传播程序的调度，修剪程度，搜索控制中的平局决胜规则等方面具有许多内部自由度.

CLP specifics: There are many other considerations specific to the kind of data-driven operations that occur in CLP solvers, and which make CLP runtimes very difficult to compare. These solvers have many internal degrees of freedom regarding scheduling of propagators, degrees of pruning, tie breaking rules in search control, etc.

专门讨论这些问题的论文是: 《基准约束逻辑编程平台》，作者:马克·华莱士(Mark Wallace)，约阿希姆·辛普夫(Joachim Schimpf)，沈洁和沃里克·哈维(Warwick Harvey).在 CONSTRAINTS Journal 中. E.C. Freuder，9(1)，第5-34页，Kluwer，2004年..

A paper that discusses these things specifically is: On Benchmarking Constraint Logic Programming Platforms, by Mark Wallace, Joachim Schimpf, Kish Shen and Warwick Harvey. In CONSTRAINTS Journal, ed. E.C. Freuder,9(1), pp 5-34, Kluwer, 2004.

这篇关于测量执行时间ECLiPSe CLP(或Prolog)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！