1lmbench3-alpha1 2 Added new benchmark line, which determines the cache line size 3 4 Added new benchmark tlb, which determines the effective TLB size. 5 Note that this may differ from the hardware TLB size due to OS 6 TLB entries and super-pages. 7 8 Added new benchmark par_mem, which determines the possible 9 speedup due to multiple memory reads progressing in parallel. 10 This number usually depends highly on the portion of the 11 memory hierarchy being probed, with higher caches generally 12 having greater parallelism. 13 14 Added new benchmark cache, which determines the number of caches, 15 their sizes, latency, and available parallelism. It also 16 reports the latency and available parallelism for main memory. 17 18 Added new benchmark lat_ops, which attempts to determine the 19 latency of basic operations, such as add, multiply and divide, 20 for a variety of data types, such as int, int64, float and 21 double. 22 23 Added new benchmark par_ops, which attempts to determine the 24 available scaling of the various basic operations for various 25 data types. 26 27 Added new benchmark stream, which reports memory bandwidth 28 numbers using benchmark kernels from John McCalpin's STREAM 29 and STREAM version 2 benchmarks. 30 31 Added new benchmark lat_sem, which reports SysV semaphore latency. 32 33 Added getopt() command line parsing to most benchmarks. 34 35 Added a new benchmark timing harness, benchmp(), which makes 36 it relatively easy to design and build benchmarks which 37 measure system performance under a fixed load. It takes 38 a few parameters: 39 - initialize: a function pointer. If this is non-NULL 40 the function is called in the child processes after 41 the fork but before any benchmark-related work is 42 done. The function is passed a cookie from the 43 benchmp() call. This can be a pointer to a 44 data structure which lets the function know what 45 it needs to do. 46 - benchmark: a function pointer. This function 47 takes two parameters, an iteration count "iters", 48 and a cookie. The benchmarked activity must be 49 run "iters" times (or some integer multiple of 50 "iters". This function must be idempotent; ie., 51 the benchmark harness must be able to call it 52 as many times as necessary. 53 - cleanup: a function pointer. If this is non-NULL 54 the function is called after all benchmarking is 55 completed to cleanup any resources that may have 56 been allocated. 57 - enough: If this is non-zero then it is the minimum 58 amount of time, in micro-seconds, that the benchmark 59 must be run to provide reliable results. In most 60 cases this is left to zero to allow the harness to 61 autoscale the timing intervals to the system clock's 62 resolution/accuracy. 63 - parallel: this is the number of child processes 64 running the benchmark that should be run in parallel. 65 This is really the load factor. 66 - warmup: a time period in micro-seconds that each 67 child process must run the benchmarked process 68 before any timing intervals can begin. This is 69 to allow the system scheduler time to settle in 70 a parallel/distributed system before we begin 71 measurements. (If so desired) 72 - repetitions: If non-zero this is the number of 73 times we need to repeat each measurement. The 74 default is 11. 75 - cookie: An opaque value which can be used to 76 pass information to the initialize(), benchmark(), 77 and cleanup() routines. 78 This new harness is now used by: bw_file_rd, bw_mem, bw_mmap_rd, 79 bw_pipe, bw_tcp, bw_unix, lat_connect, lat_ctx, lat_fcntl, 80 lat_fifo, lat_mem_rd, lat_mmap, lat_ops, lat_pagefault, lat_pipe, 81 lat_proc, lat_rpc, lat_select, lat_sem, lat_sig, lat_syscall, 82 lat_tcp, lat_udp, lat_unix, lat_unix_connect, and stream. 83