Re: ftbench: last updates
hey, i have done the changes you want forcing to push the repo. i am used vscode whitespace settings, is there any other mistakes to fix? Best, Goksu goksu.in On Sep 25, 2023 at 7:33 PM +0300, Werner LEMBERG , wrote: > > > I hope my effort contribute to you. I wish to see you again. > > :-) You are invited to continue your work even after GSoC has ended. > > > Here is my last version of readme, [...] > > Uh, oh, the formatting in the e-mail is completely broken... > > > i will push submit my final submission regarding your feedback. > > Ideally, you apply formatting and indenting changes to, say, the > fourth commit from the top (within your branch) by doing the > following: > > ``` > git rebase -i HEAD # interactive rebase > > > git add -p # add diffs one by one > git commit --amend # rewrite current commit > git rebase --continue # continue rebase > git push -f # force-push > ``` > > Currently, there is a bunch of whitespace commits on top of the > cleaned-up commits. However, the idea of a cleaned-up tree is that > such formatting changes are *not* present – please bear in mind that > we don't squash the commits into a single one! > > I would be glad if you could remove the whitespace commits and include > the whitespace fixes in the actual commits instead (don't worry about > today's GSoC deadline, this is cosmetics only). > > > (also waiting for *-demos code review, i will push them too) > > Thanks. > > > Werner
Re: ftbench: last updates
> I hope my effort contribute to you. I wish to see you again. :-) You are invited to continue your work even after GSoC has ended. > Here is my last version of readme, [...] Uh, oh, the formatting in the e-mail is completely broken... > i will push submit my final submission regarding your feedback. Ideally, you apply formatting and indenting changes to, say, the fourth commit from the top (within your branch) by doing the following: ``` git rebase -i HEAD # interactive rebase git add -p # add diffs one by one git commit --amend # rewrite current commit git rebase --continue# continue rebase git push -f # force-push ``` Currently, there is a bunch of whitespace commits on top of the cleaned-up commits. However, the idea of a cleaned-up tree is that such formatting changes are *not* present – please bear in mind that we don't squash the commits into a single one! I would be glad if you could remove the whitespace commits and include the whitespace fixes in the actual commits instead (don't worry about today's GSoC deadline, this is cosmetics only). > (also waiting for *-demos code review, i will push them too) Thanks. Werner
Re: ftbench: last updates
Thanks a lot :) I hope my effort contribute to you. I wish to see you again. Here is my last version of readme, i will push submit my final submission regarding your feedback. (also waiting for *-demos code review, i will push them too) > > > ftbench > ftbench is a program designed to run FreeType benchmarks between versions.It > accepts various options to run specific tests on font rendering operations. > Each test may involve tasks such as: > . Initializing the library. Opening the font file. Comparing results with > cached versions (if available). Configuring specific charmap indices, load > flags, etc. > Usage is iterations-limited or can be explicitly set to use a maximumnumber > of iterations per test. > > Command line options > -C Compare with cached version (if available).-c N Use at most N > iterations for each test (0 means time-limited).-e E Set specific charmap > index E.-f L Use hex number L as load flags (see FT_LOAD_XXX').-H NAME > Use PS hinting engine NAME (default is adobe').-I VER Use TT interpreter > version VER (default is version 40).-i I-J Forward or reverse range of glyph > indices to use.-l N Set LCD filter to N (default is 0: none).-m M Set > maximum cache size to M KiByte (default is 1024).-p Preload font file in > memory.-r N Set render mode to N (default is 0: normal).-s S Use S ppem > as face size (default is 10ppem).-t T Use at most T seconds per bench > (default is 2).-w N Use N iterations for warming up before each test. > -b tests Perform chosen tests (default is all).-v Show version. > Usage--- > make baseline To create a baseline for your benchmarks,use the > `make baseline` command. This will compile the ftbench.c andcreate a set of > baseline measurements in the objs/baseline/ directory. > make benchmark To run the benchmarks, use the `make benchmark` > command.The results will be stored in the objs/benchmark/ directory.It will > copy tohtml.py script to objs/ and generate a html file. > make clean-benchmark To remove all generated benchmark files andclean the > objs directory, use the `make clean-benchmark` command. > Best, Goksu goksu.in On 25 Sep 2023 07:20 +0300, Werner LEMBERG , wrote: > > Hello Ahmet, > > > sorry for the late reply, I'm travelling right now. > > > -Made documentation and comment line (will continue). > > Very nice! Some minor nits, in case you have still time today: > > * Please ensure that lines in the documentation are not longer than 78 > characters (`src/tools/ftbench/README`). Ideally, `README` comes in > Markdown format, but this is not important. > > * Use two spaces after a full dot in documentation (this simplifies > the search for the beginning of a sentence with some editors like > Emacs). > > * Use `autopep8 -a -a -a` to format `tohtml.py` and do some manual > editing to also shorten the remaining overlong lines to > 78 characters per line if possible and useful. > > * There are some indentation errors in `ftbench.c` (functions > `test_render`, `test_embolden`, etc.). > > * Please synchronize `ftbench.c` with the git version in the > `freetype-devel` repository (which is a trivial change only). > > > In this version of the code, i just didnt splitted iterations into > > chunks, got same results with it. > > OK. Too bad that we couldn't find the real cause for the large time > differences, but hey, this is a GSoC project :-) > > > Werner
Re: ftbench: last updates
Hello Ahmet, sorry for the late reply, I'm travelling right now. > -Made documentation and comment line (will continue). Very nice! Some minor nits, in case you have still time today: * Please ensure that lines in the documentation are not longer than 78 characters (`src/tools/ftbench/README`). Ideally, `README` comes in Markdown format, but this is not important. * Use two spaces after a full dot in documentation (this simplifies the search for the beginning of a sentence with some editors like Emacs). * Use `autopep8 -a -a -a` to format `tohtml.py` and do some manual editing to also shorten the remaining overlong lines to 78 characters per line if possible and useful. * There are some indentation errors in `ftbench.c` (functions `test_render`, `test_embolden`, etc.). * Please synchronize `ftbench.c` with the git version in the `freetype-devel` repository (which is a trivial change only). > In this version of the code, i just didnt splitted iterations into > chunks, got same results with it. OK. Too bad that we couldn't find the real cause for the large time differences, but hey, this is a GSoC project :-) Werner
Re: ftbench: last updates
Hi, I have created a new branch. Here you can see it: https://gitlab.freedesktop.org/freetype/freetype/-/tree/gsoc-2023-ahmet-final -Made documentation and comment line (will continue). -trailing whitespaces cleared -more verbose commit messages -formatted the code. In this version of the code, i just didnt splitted iterations into chunks, got same results with it. Best, Goksu goksu.in On 18 Sep 2023 10:34 +0300, Werner LEMBERG , wrote: > > Hello Ahmet, > > > > -I have changed the * and the sentence > > Thanks. Unfortunately, I was unclear that '*x*' in my e-mail is meant > as Markdown syntax and not to be taken verbatim. In other words, 'x' > should be typeset in italics, similar to a mathematical variable. > Sorry for that, and please fix. > > Something different: Please don't use `\r` in messages for newlines. > Use `\n` instead, which is standard (file `testing.mk`). > > > > I already changed the working way of the timing. I only start the > > > benchmark at beginning and stop at the end. > > > > i mean, it times chunks, not single iteration. timer starts at the > > beginning of the chunk and stop at the end (then divide the results > > size of a chunk). because of it does not time single iteration, it > > is already a bulk test. > > Ok. > > > > BTW, I suggest that you add another sentence, explaining *why* > > > there are two values at all. > > > > actually, i didnt get the reason well but it may differ even with > > same flags. i need help in this case. > > Alexei, please have a look. It seems that only(?) the 'Stroke' test > is affected... > > > the code seems producing more accurate results after splitting the > > results into chunks. are results seem satisfactory in your machine? > > Alas, they aren't. Running your code on my GNU/Linux machine, I get > percental differences up to 14%. > > BTW, I've also just compiled `valgrind` from its git repository (to be > sure that it exactly fits my 'libc' library version) and run > > ``` > valgrind --trace-children=yes make baseline > valgrind --trace-children=yes make benchmark > ``` > > expecting to get identical results, because `valgrind` uses a CPU > emulator. However, to my great surprise, they are *not* identical, > and sometimes the values differ even enormously. Has anybody an idea > why this happens? AFAICS from valgrind's source files, the > `clock_gettime` function *is* caught. > > Note that with valgrind the creation of the webpage fails; I get > > ``` > Traceback (most recent call last): > File "/home/wl/ahmet/tohtml.py", line 310, in > main() > File "/home/wl/ahmet/tohtml.py", line 67, in main > generate_total_results_table(html_file, BASELINE_DIR, BENCHMARK_DIR) > File "/home/wl/ahmet/tohtml.py", line 192, in generate_total_results_table > diff = ((baseline - benchmark) / baseline) * 100 > ZeroDivisionError: float division by zero > ``` > > Attached are the two directories from valgrind runs. Comparing this > with non-valgrind values I think there is a fundamental interaction > problem with the `bench` program: It seems that `bench` controls the > number of loops *in addition* to what you specify via the command > line. Unfortunately, I don't have time right now to check this by > myself. > > Too bad that you didn't try `valgrind` by yourself earlier, as I've > asked you repeatedly to do ... > > > Also, While there are less than 10 days for final evaluation, there > > are points that are not completed: > > > > * meson > > * cmake > > * documentation > > > > because of our focus a bit changed, didnt worked on them > > much. Should I complete them all? Is there a priority? > > Please forget meson and cmake, this is not important at this stage. > What I now ask is to create a new branch, with *all* of your changes > recreated as logical and (relatively small) incremental commits, > rebased to 'master'. Ideally every commit is compilable. If not > (which should be an exception, and there should be a good explanation > for that), please add a remark in the commit message. > > * Try to adjust the formatting to be as near to the remaining code of > FreeType. > > * The commit messages should also be in FreeType style, which is much* > *more verbose than what you currently do. > > * Avoid trailing whitespace – whatever editor you use, *please* change > the settings so that this gets automatically removed. Right now, I > see zillions of trailing whitespace in file `tohtml.py`. > > * Hin-Tak is right: Documentation is of paramount importance so that > you (or someone else) can continue the work. > > Have a look at previous GSoC students' (remote) branches to see how > such a recreated branch should look like, for example > `GSoC-2019-nikhil` or `GSoC-2017-ewaldhew`. > > > Werner Freetype Benchmark Results Warning: Baseline and Benchmark have the same commit ID! Info InfoBaselineBenchmark Parameters-c 1000 -w 100-c 1000 -w 100 Commit IDe61380fee61380fe Commit Date2023-09-21 15:34:38 +03002023-09-21 15:34:38 +0300
Re: ftbench: last updates
Hello Ahmet, > -I have changed the * and the sentence Thanks. Unfortunately, I was unclear that '*x*' in my e-mail is meant as Markdown syntax and not to be taken verbatim. In other words, 'x' should be typeset in italics, similar to a mathematical variable. Sorry for that, and please fix. Something different: Please don't use `\r` in messages for newlines. Use `\n` instead, which is standard (file `testing.mk`). >> I already changed the working way of the timing. I only start the >> benchmark at beginning and stop at the end. > > i mean, it times chunks, not single iteration. timer starts at the > beginning of the chunk and stop at the end (then divide the results > size of a chunk). because of it does not time single iteration, it > is already a bulk test. Ok. >> BTW, I suggest that you add another sentence, explaining *why* >> there are two values at all. > > actually, i didnt get the reason well but it may differ even with > same flags. i need help in this case. Alexei, please have a look. It seems that only(?) the 'Stroke' test is affected... > the code seems producing more accurate results after splitting the > results into chunks. are results seem satisfactory in your machine? Alas, they aren't. Running your code on my GNU/Linux machine, I get percental differences up to 14%. BTW, I've also just compiled `valgrind` from its git repository (to be sure that it exactly fits my 'libc' library version) and run ``` valgrind --trace-children=yes make baseline valgrind --trace-children=yes make benchmark ``` expecting to get identical results, because `valgrind` uses a CPU emulator. However, to my great surprise, they are *not* identical, and sometimes the values differ even enormously. Has anybody an idea why this happens? AFAICS from valgrind's source files, the `clock_gettime` function *is* caught. Note that with valgrind the creation of the webpage fails; I get ``` Traceback (most recent call last): File "/home/wl/ahmet/tohtml.py", line 310, in main() File "/home/wl/ahmet/tohtml.py", line 67, in main generate_total_results_table(html_file, BASELINE_DIR, BENCHMARK_DIR) File "/home/wl/ahmet/tohtml.py", line 192, in generate_total_results_table diff = ((baseline - benchmark) / baseline) * 100 ZeroDivisionError: float division by zero ``` Attached are the two directories from valgrind runs. Comparing this with non-valgrind values I think there is a fundamental interaction problem with the `bench` program: It seems that `bench` controls the number of loops *in addition* to what you specify via the command line. Unfortunately, I don't have time right now to check this by myself. Too bad that you didn't try `valgrind` by yourself earlier, as I've asked you repeatedly to do ... > Also, While there are less than 10 days for final evaluation, there > are points that are not completed: > > * meson > * cmake > * documentation > > because of our focus a bit changed, didnt worked on them > much. Should I complete them all? Is there a priority? Please forget meson and cmake, this is not important at this stage. What I now ask is to create a new branch, with *all* of your changes recreated as logical and (relatively small) incremental commits, rebased to 'master'. Ideally every commit is compilable. If not (which should be an exception, and there should be a good explanation for that), please add a remark in the commit message. * Try to adjust the formatting to be as near to the remaining code of FreeType. * The commit messages should also be in FreeType style, which is much* *more verbose than what you currently do. * Avoid trailing whitespace – whatever editor you use, *please* change the settings so that this gets automatically removed. Right now, I see zillions of trailing whitespace in file `tohtml.py`. * Hin-Tak is right: Documentation is of paramount importance so that you (or someone else) can continue the work. Have a look at previous GSoC students' (remote) branches to see how such a recreated branch should look like, for example `GSoC-2019-nikhil` or `GSoC-2017-ewaldhew`. Werner valgrind.tar.gz Description: Binary data
Re: ftbench: last updates
Thanks Hin-Tak, I will create a README and enhance the comments inside of the codes and Makefile being guided by docguide and ftrandom (another function inside of the src/tools) documentation. Best, Goksu goksu.in On 17 Sep 2023 22:23 +0300, Hin-Tak Leung , wrote: > Hi Ahmet. I'll leave Werner to say something definitive, but in my opinion, > given the project will be put aside and/or merge with some incomplete area > soon, for some possibly long period before you or somebody else revisit the > tasks/goals, it is particularly important to document things clearly. Not > just in terms of formal documentations in the various readme's, but also > adding "TODO", "Known limitations" in the code. Like "notes and reminders to > future self" if you need to come back to it and continue after 5 years :-). > > As for meson and cmake - if you do add/change something at this stage, be > sure to write a bit more about what state it is in, in the commit message. It > will be quite annoying for somebody else, or you yourself for that matter, to > look at some large chunk of code in a year or two, and think: "what state > this was in, did this work at all? Has this gotten broken recently, or never > did work?". I think one example might be qt6 support for ftinspect - there > are some work/code going towards it, but it would be nice to see a comment > where it matters - around where one might switch from qt5 to qt6 - that it > doesn't quite work yet. There are always going to be > incomplete/work-in-progress areas, so the general direction would be write > down things clearly so you or someone else can revisit later and continue > with as much help and information as you can give now. > > > On Sunday, 17 September 2023 at 12:35:08 BST, Ahmet Göksu > wrote: > > > Thanks Hin-Tak, > I am developing on a Mac. > > Also, > While there are less than 10 days for final evaluation, there are points that > are not completed: > *meson > *cmake > *documentation > because of our focus a bit changed, didnt worked on them much. Should I > complete them all? Is there a priority? > > Best, > Goksu > goksu.in > On 17 Sep 2023 02:31 +0300, Hin-Tak Leung , > wrote: > > I just remember something - the windows' implementation of ANSI / POSIX > > timing routines are especially poor - e.g. > > https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime > > So unfortunately if you are trying to measure time on Windows accurately, > > you might have to do something differently from ANSI C . If you search for > > "poor timer on Windows" or just "highres timer os" on most search engines, > > there are various discussions about it. > > > > > > On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu > > wrote: > > > > > > Hello, > > -I have changed the * and the sentence > > -changed the links to relative > > > I already changed the working way of the timing. I only start the > > > benchmark at beginning and stop at the end. > > i mean, it times chunks, not single iteration.timer starts at the beginning > > of the chunk and stop at the end (then divide the results size of a chunk). > > because of it does not time single iteration, it is already a bulk test. > > > BTW, I suggest that you add another sentence, explaining *why* there > > > are two values at all. > > actually, i didnt get the reason well but it may differ even with same > > flags. i need help in this case. > > > > as i said before, i run the benchmark in mac. it uses this if clause. > > return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; > > > > the code seems producing more accurate results after splitting the results > > into chunks. are results seem satisfactory in your machine? > > > > Best, > > Goksu > > goksu.in > > On 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: > > > > > > > > If a value in the 'Iterations' column is given as '*x* | *y*', > > > values *x* and *y* give the number of iterations in the baseline and > > > the benchmark test, respectively.
Re: ftbench: last updates
Hi Ahmet. I'll leave Werner to say something definitive, but in my opinion, given the project will be put aside and/or merge with some incomplete area soon, for some possibly long period before you or somebody else revisit the tasks/goals, it is particularly important to document things clearly. Not just in terms of formal documentations in the various readme's, but also adding "TODO", "Known limitations" in the code. Like "notes and reminders to future self" if you need to come back to it and continue after 5 years :-). As for meson and cmake - if you do add/change something at this stage, be sure to write a bit more about what state it is in, in the commit message. It will be quite annoying for somebody else, or you yourself for that matter, to look at some large chunk of code in a year or two, and think: "what state this was in, did this work at all? Has this gotten broken recently, or never did work?". I think one example might be qt6 support for ftinspect - there are some work/code going towards it, but it would be nice to see a comment where it matters - around where one might switch from qt5 to qt6 - that it doesn't quite work yet. There are always going to be incomplete/work-in-progress areas, so the general direction would be write down things clearly so you or someone else can revisit later and continue with as much help and information as you can give now. On Sunday, 17 September 2023 at 12:35:08 BST, Ahmet Göksu wrote: Thanks Hin-Tak, I am developing on a Mac. Also, While there are less than 10 days for final evaluation, there are points that are not completed: *meson *cmake *documentation because of our focus a bit changed, didnt worked on them much. Should I complete them all? Is there a priority? Best,Goksugoksu.inOn 17 Sep 2023 02:31 +0300, Hin-Tak Leung , wrote: I just remember something - the windows' implementation of ANSI / POSIX timing routines are especially poor - e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime So unfortunately if you are trying to measure time on Windows accurately, you might have to do something differently from ANSI C . If you search for "poor timer on Windows" or just "highres timer os" on most search engines, there are various discussions about it. On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu wrote: Hello, -I have changed the * and the sentence -changed the links to relative I already changed the working way of the timing. I only start the benchmark at beginning and stop at the end. i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test. BTW, I suggest that you add another sentence, explaining *why* there are two values at all. actually, i didnt get the reason well but it may differ even with same flags. i need help in this case. as i said before, i run the benchmark in mac. it uses this if clause. return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine? Best,Goksugoksu.inOn 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: If a value in the 'Iterations' column is given as '*x* | *y*', values *x* and *y* give the number of iterations in the baseline and the benchmark test, respectively.
Re: ftbench: last updates
Thanks Hin-Tak, I am developing on a Mac. Also, While there are less than 10 days for final evaluation, there are points that are not completed: *meson *cmake *documentation because of our focus a bit changed, didnt worked on them much. Should I complete them all? Is there a priority? Best, Goksu goksu.in On 17 Sep 2023 02:31 +0300, Hin-Tak Leung , wrote: > I just remember something - the windows' implementation of ANSI / POSIX > timing routines are especially poor - e.g. > https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime > So unfortunately if you are trying to measure time on Windows accurately, you > might have to do something differently from ANSI C . If you search for "poor > timer on Windows" or just "highres timer os" on most search engines, there > are various discussions about it. > > > On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu > wrote: > > > Hello, > -I have changed the * and the sentence > -changed the links to relative > > I already changed the working way of the timing. I only start the > > benchmark at beginning and stop at the end. > i mean, it times chunks, not single iteration.timer starts at the beginning > of the chunk and stop at the end (then divide the results size of a chunk). > because of it does not time single iteration, it is already a bulk test. > > BTW, I suggest that you add another sentence, explaining *why* there > > are two values at all. > actually, i didnt get the reason well but it may differ even with same flags. > i need help in this case. > > as i said before, i run the benchmark in mac. it uses this if clause. > return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; > > the code seems producing more accurate results after splitting the results > into chunks. are results seem satisfactory in your machine? > > Best, > Goksu > goksu.in > On 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: > > > > > If a value in the 'Iterations' column is given as '*x* | *y*', > > values *x* and *y* give the number of iterations in the baseline and > > the benchmark test, respectively.
Re: ftbench: last updates
I just remember something - the windows' implementation of ANSI / POSIX timing routines are especially poor - e.g.https://stackoverflow.com/questions/18346879/timer-accuracy-c-clock-vs-winapis-qpc-or-timegettime So unfortunately if you are trying to measure time on Windows accurately, you might have to do something differently from ANSI C . If you search for "poor timer on Windows" or just "highres timer os" on most search engines, there are various discussions about it. On Saturday, 16 September 2023 at 17:21:49 BST, Ahmet Göksu wrote: Hello, -I have changed the * and the sentence -changed the links to relative I already changed the working way of the timing. I only start the benchmark at beginning and stop at the end. i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test. BTW, I suggest that you add another sentence, explaining *why* there are two values at all. actually, i didnt get the reason well but it may differ even with same flags. i need help in this case. as i said before, i run the benchmark in mac. it uses this if clause. return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine? Best,Goksugoksu.inOn 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: If a value in the 'Iterations' column is given as '*x* | *y*', values *x* and *y* give the number of iterations in the baseline and the benchmark test, respectively.
Re: ftbench: last updates
Hello, -I have changed the * and the sentence -changed the links to relative > I already changed the working way of the timing. I only start the > benchmark at beginning and stop at the end. i mean, it times chunks, not single iteration.timer starts at the beginning of the chunk and stop at the end (then divide the results size of a chunk). because of it does not time single iteration, it is already a bulk test. > BTW, I suggest that you add another sentence, explaining *why* there > are two values at all. actually, i didnt get the reason well but it may differ even with same flags. i need help in this case. as i said before, i run the benchmark in mac. it uses this if clause. return 1E6 * (double)clock() / (double)CLOCKS_PER_SEC; the code seems producing more accurate results after splitting the results into chunks. are results seem satisfactory in your machine? Best, Goksu goksu.in On 12 Sep 2023 18:17 +0300, Werner LEMBERG , wrote: > > If a value in the 'Iterations' column is given as '*x* | *y*', > values *x* and *y* give the number of iterations in the baseline and > the benchmark test, respectively.
Re: ftbench: last updates
>> With 'bulk test' I mean that you don't time single iterations but >> do timings for 10 iterations in a group, say, thus avoiding >> issues with the granularity of the OS timing functions. > > I already changed the working way of the timing. I only start the > benchmark at beginning and stop at the end. Sorry, but I don't understand your last sentence, please elaborate. >> I wouldn't use '**' – this looks like a footnote, and people start >> searching where it belongs to. Instead, please use a simple >> itemization. Well, in the latest incarnation of the HTML page there is now a single line with a '*'. An enumeration needs at least two items, otherwise it again looks like a footnote. In other words, the second sentence need to start with '*', too. >> * The sentence about '(X | Y') is cryptic. [...] > > done! Thanks, but the current text If two values are given in the 'Iterations' column, those are belong to baseline and benchmark in order. is not correct English. Maybe If a value in the 'Iterations' column is given as '*x* | *y*', values *x* and *y* give the number of iterations in the baseline and the benchmark test, respectively. BTW, I suggest that you add another sentence, explaining *why* there are two values at all. >> The links for `Baseline` and `Benchmark` to the `.txt` files are >> absolute and thus not portable. They must be relative. > > I didnt get this clear. Since objs dir and the source dir > different, I needed to give abs path. Why? Simply give one directory relative to the other! Assuming that you have baseline_dir = /foo/bar/baseline/ benchmark_dir = /foo/bar/benchmark/ and `benchmark.html` gets built in `benchmark_dir`, the two links to file `Roboto_subset.txt` would be What am I missing? Maybe https://stackoverflow.com/questions/29055511/how-to-find-relative-path-given-two-absolute-paths helps. The benchmark should abort if it is not possible to construct a relative path. Werner
