Re: -warmup
> It is warming up as the given number of seconds with -w flag before > every benchmark test. > > There are still differences like 100%.. Also, 1 sec warmup means > (test count)*(font count) 70 secs for the results. Mhmm, I'm not sure whether a warmup *time span* makes sense. I would rather have thought that every test would get a certain number of warmup *loops*. For example, '--warmup 100' means that for a value of N=5, the first 100 loops of each test are not taken into account for timing so that effects of the various processor and memory caches, the operating system's memory page swapping, etc., etc., doesn't have too much influence. This should be just a very small fraction of time, not 70s. > I am thinking of what else can be done and waiting for your test. Just looking at your most recent HTML page I see some peculiarities. * What exactly means 'Baseline (ms)'? Is the shown number the time for one loop? For all loops together? Please clarify and mention this on the HTML page. * There seems to be a fundamental math problem in calculating the percentage numbers. For example, looking at the 'TOTAL' field, the percental difference between 2.788 and 2.740 is not -6.1% but -1.7%! What am I missing? * Looking at the 'Load_Advances (Unscaled)' row, I think that 100% difference between 0.001 and 0.002 doesn't make any sense. How do you compute the percentage? Is this based on the cumulative time of all loops? If so, and you really get such small numbers, there must be some fine-tuning for high-speed tests (for example, increasing N for this particular test by a factor of 10, say) to get meaningful timing values. Werner
-warmup
Hi, I have updated the bench code. It is warming up as the given number of seconds with -w flag before every benchmark test. There are still differences like 100%.. Also, 1 sec warmup means (test count)*(font count) 70 secs for the results. I am thinking of what else can be done and waiting for your test. Best, Goksu goksu.in On 3 Aug 2023 05:45 +0300, Werner LEMBERG , wrote: > > > I have done the changes you want. > > Thanks! > > > > 36.5% run difference is bd. AFAICS, you haven't yet worked on > > > omitting 'warmup' iterations, right? > > > > I am planning to increase the iteration count by 10% and ignore the > > results for them. > > You mean you are going to ignore the first 10% of the iterations? > This might be a good default. However, I still think that a > `--warmup` command-line option makes sense to control this. > > > Trying to figure out the benchmarking program but actually drowning > > in 1500 lines of code. > > :-) I hope you can eventually find what you need. > > > Werner Freetype Benchmark Results Warning: Baseline and Benchmark have the same commit ID! Info InfoBaselineBenchmark Parameters-c 500 -w 1-c 500 -w 1 Commit IDfae5e8c9fae5e8c9 Commit Date2023-08-01 17:37:55 +03002023-08-01 17:37:55 +0300 BranchGSoC-2023-AhmetGSoC-2023-Ahmet * Smaller values mean faster operation Results for Roboto_subset.ttf TestN* Baseline (ms)* Benchmark (ms)Difference (%) Load598800.2500.270-8.0 Load_Advances (Normal)598800.3110.24321.9 Load_Advances (Fast)598800.0020.0020.0 Load_Advances (Unscaled)598800.0010.002-100.0 Render598800.2200.2180.9 Get_Glyph598800.0860.0860.0 Get_Char_Index469060.0010.0010.0 Iterate CMap4990.0010.0010.0 New_Face4990.0220.0220.0 Embolden598800.1150.1150.0 Stroke571201.6281.629-0.1 Get_BBox598800.0550.0550.0 Get_CBox598800.0430.0422.3 New_Face & load glyph(s)598800.0530.054-1.9 TOTAL14076482.7882.740-6.1 Results for Arial_subset.ttf TestN* Baseline (ms)* Benchmark (ms)Difference (%) Load474050.3900.3763.6 Load_Advances (Normal)474050.3440.3401.2 Load_Advances (Fast)474050.0010.0010.0 Load_Advances (Unscaled)474050.0010.0010.0 Render474050.1790.186-3.9 Get_Glyph474050.0750.076-1.3 Get_Char_Index469060.0010.0010.0 Iterate CMap4990.0010.0010.0 New_Face4990.0280.02510.7 Embolden474050.1030.1030.0 Stroke474051.3241.329-0.4 Get_BBox474050.0490.051-4.1 Get_CBox474050.0350.036-2.9 New_Face & load glyph(s)474050.0600.05410.0 TOTAL11387182.5912.5800.9 Results for TimesNewRoman_subset.ttf TestN* Baseline (ms)* Benchmark (ms)Difference (%) Load474050.4550.464-2.0 Load_Advances (Normal)474050.4190.4121.7 Load_Advances (Fast)474050.0010.0010.0 Load_Advances (Unscaled)474050.0010.0010.0 Render474050.2010.1972.0 Get_Glyph474050.0780.082-5.1 Get_Char_Index469060.0010.0010.0 Iterate CMap4990.0010.0010.0 New_Face4990.0270.0270.0 Embolden474050.1400.1390.7 Stroke401851.5451.5450.0 Get_BBox474050.0580.059-1.7 Get_CBox474050.0370.041-10.8 New_Face & load glyph(s)474050.0690.076-10.1 TOTAL11242783.0333.046-1.8 Results for Tahoma_subset.ttf TestN* Baseline (ms)* Benchmark (ms)Difference (%) Load474050.2650.289-9.1 Load_Advances (Normal)474050.2450.2392.4 Load_Advances (Fast)474050.0010.0010.0 Load_Advances (Unscaled)474050.0010.0010.0 Render474050.1660.1660.0 Get_Glyph474050.0750.0715.3 Get_Char_Index469060.0010.0010.0 Iterate CMap4990.0010.0010.0 New_Face4990.0250.0244.0 Embolden474050.1180.1088.5 Stroke474051.2441.2360.6 Get_BBox474050.0470.0470.0 Get_CBox474050.0340.0340.0 New_Face & load glyph(s)47405
Re: Progress update on adjustment database
> [...] I have confirmed by commenting/uncommenting steps of the > hinting process that af_glyph_hints_align_edge_points is the > function that snaps the tilde back to flat, so if my understanding > is correct, the points at the top and bottom of the tilde are > forming edges and are being rounded towards each other, causing the > tilde to remain flat. Yes, it seems so. In case you haven't read it already, this article gives a nice overview, but please be aware that it is 20(!) years old and thus partially outdated with respect to some details: https://www.tug.org/TUGboat/tb24-3/lemberg.pdf > How should I proceed? Perhaps you can try to remove the affected segments from the corresponding edges. If that fails there is still the possibility to apply the vertical distortion afterwards... Werner
