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 <module>
    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