On Sun, Feb 7, 2016 at 10:39 PM, Matthias-Christian Ott <ott at mirix.org> wrote:
> On 2016-02-08 04:31, Roger Binns wrote: > > On 07/02/16 00:56, Dominique Pell? wrote: > >> I'm curious about the outcome on SQLite benchmarks. > > > > About a year ago I tried them out on some tight code (non-SQLite) that > > absolutely had to use less CPU time. I couldn't get them to make any > > difference outside the bounds of measurement error. Since SQLite has > > lots of "tight code" places, the instrumentation would have to help in > > most of them to make a difference (Amdahl's law). > > Amdahl's law is not applicable here and describes a completely different > problem. SQLite does not involve concurrency. > "Amdahl's law _In computer architecture, Amdahl's law (or Amdahl's argument[1]) gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved." You _can_ use it to analyze why parallelizing an algorithm across N CPUs won'y cause the runtime to become 1/N, but that's not the only use. In typical scenarios SQLite is also limited by the number of IOPS and > optimization to improve branch predictability have no measurable effect > and you just waste time with them. Just use PCIe SSDs that are able to > saturate the bus and all of you performance problems with SQLite are > gone if you use SQLite on typical computer. > In fact, your argument here is Amdahl's Law. If your performance is primarily limited by I//O latency, then improving CPU efficiency won't help much. -scott
