Board index » delphi » Re: Questions regarding the MM challenge...

Re: Questions regarding the MM challenge...


2005-07-04 04:01:21 PM
delphi249
Hi Ralf Mimoun
Thanks for your opinion.
Regards
Dennis
 
 

Re: Questions regarding the MM challenge...

On Sat, 2 Jul 2005 21:41:02 +0100, "Peter Morris [Droopy eyes software]"
<XXXX@XXXXX.COM>writes:
Quote
[a good post]
which I agree with completely.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Re: Questions regarding the MM challenge...

On Sun, 3 Jul 2005 23:13:04 +0200, "Dennis" <XXXX@XXXXX.COM>
writes:
Quote
>Maybe for their purposes 8 byte alignment, or 32 byte alignment was more
>productive?

Perhaps. I do not care about it. We just measure and document the alignment
they do.
Actually, no.
When putting a label like 'fail/pass', 'OK/NOT OK', etc. on something
you are not only measuring and documenting, you are putting in a value
statement too. Obviously, in your opinion, one of the labels is 'better'
than it is counterpart.
You *are* therefore sending out a value message to all readers.
Validation should only be about absolutes - '*Does* it actually work?'
Benchmarking should be about '*How* does it work compared to others?'
'Wish list fulfillment/featuritis' is about *opinion*.
The *wish* to have 16 bit alignment is created by the FastCode
community, it is not an inherent need for a Delphi MM.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Re: Questions regarding the MM challenge...

On Mon, 4 Jul 2005 05:31:26 +0200, "Ralf Mimoun" <XXXX@XXXXX.COM>
writes:
Quote
From an end user point of view, I would say that Peter should consider
to take his function from the contest/comparison/name it.
But *Peter* didn't enter his function to the competition, it was freely
available, and FastCode included it for comparisons.
There *is* a problem when you include functions not explicitely written
for the competition specifications, and I fully agree that value
statements such as 'fail/pass' do not have a place there in that case.
'N/A' is better, but still leaves the reader doubting ("Why is this
routine N/A?").
It would probably be best to only include entries explicitely written
for FastCode specifications.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Re: Questions regarding the MM challenge...

On Mon, 4 Jul 2005 09:42:13 +0200, "Dennis" <XXXX@XXXXX.COM>
writes:
Quote
I think it would be very weird to list RTLMM: 16 byte alignment = N/A.
I think it makes sense to write RTLMM: 16 byte alignment = no.
I think it would make most sense to write:
RTLMM: Alignment = 4
xyzMM: Alignment = 16
abcMM: Alignment = 4, 8, 32
or whatever the MM:s support. that is facts, not value statments. The
value of a certain alignment is for the user to decide.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Re: Questions regarding the MM challenge...

Hi
Quote
Bending words ;-) I apologize but I cannot follow you.
It's not bending words, it is being more factual. You can interpret the
result as either
A) The 3P library tried to pass the test but failed
B) The 3P library does not "conform" to *your* requirements to pass the test
If a 3P library did not attempt to conform to your standards then it cannot
possibly "fail", it can only "function differently". Their requirements
were obviously different to yours.
Quote
>2) Your label is obviously biased towards FC entries
Not really biased. We never make some other MM's look bad by intention.
I didn't mean that you are intentionally biased to make people look bad. I
am saying that it is obviously much easier to pass a test that you purposely
set out to pass, and also much more difficult to pass a test you had no
knowledge of or didn't even exist when you wrote your library. Any 3P
parties which pass your tests do so through coincidence only.
That is what I mean by "biased". The results of your tests make entries
look like they are better quality, when in fact they just meet the FC
requirements.
Quote
I think it is possible that we could agree better if we discussed each of
the tests. General discussion will miss the target - IMHO.
I don't think so. I think it is quite clear what I am saying, you seem to
be the only person who does not understand.
Quote
It is hard to find a correct wording ;-) How do you suggest that we
publish
that a certain MM does not 16 byte align blocks?
I will steal the answer from Anders Isaksson, which I think was very good.
RTLMM: Alignment = 4
xyzMM: Alignment = 16
abcMM: Alignment = 4, 8, 32
Here you aren't saying that the RTLMM "failed" at 8,16,32 - you are merely
stating a fact that it only supports 4, which is how it was designed. Note
that I don't know which alignments the RTLMM supports, these numbers are
merely illustrative.
Quote
Perhaps. Do you think that we have a war going on with Nexus, Borland or
M$
? Trying to harm their business such that we can earn more more on our
free
MM's ? ;-)
No, I just think you unintentionally made them look faulty by labeling test
results with "fail", and I am trying to make you aware that doing so is not
a good thing for a commercial product.
Quote
Have you taken the noble task of defending those "third party library"
authors.
I'm just trying to prevent you from making the same mistake to some future
3P tool vendor.
Quote
I think that our discussion should evolve around the "Fastcode Quality
Label" only. I see this as the most controversial issue. Do you agree?
No, I see that as the most simple to solve. A 3P library is not subject to
your label, it should *only* be used as a speed reference for the entries to
beat.
Quote
Can you give me a complete list of which tests are not applicable to which
MM's.
No because I am talking generally, not specifically about this case. I am
trying to suggest a way in which you can provide valuable data without
making 3P vendors look like they write dodgy code.
Quote
>2) If a 3P function does not conform to your tests (this is not the same
as
>failing) then list it as "Functions differently"

Word bending. We should be really carefull not to hurt the fealings of
these
three companies. Try ask them whether they feel hurt.
Okay. "Pete, do you feel hurt? Actually, I did a bit, yes".
There you go. I am glad your libraries ran faster than mine, maybe one day I
will look at the source and see why, and I sincerely hope they are
eventually used in the VCL *but* I do not like you to say that I
accidentally let a bug slip through when I didn't. Now, if you were using
the wording that I propose, you wouldn't have implied my code was faulty,
you would have merely indicated that obtaining a benchmark for that specific
routine was not appropriate because the routine functions differently to
your own specification.
This is exactly the sort of statement that you should not be making.
Quote
I think it would be very weird to list RTLMM: 16 byte alignment = N/A.
I think it makes sense to write RTLMM: 16 byte alignment = no.
That is because your example is not a speed benchmark, it is a feature
comparison table. In the above case it is acceptible to use "no" instead of
fail, but for speed benchmarks you should use
A) For different behaviour: "Functions differently"
B) For a routine which is not present: "N/A"
Quote
>You should employ something along these lines simply because it
demonstrates
>professional courtessy to the owners of the third party libraries you are
>using as benchmarks.

And reduces the quality of our report.
On the contrary, I believe it is *much* more informative. I think you just
didn't follow my suggestions because you were concentrating on the feature
table when I was in fact talking about speed benchmarks.
I hope I have made it clear enough now?
PS, you failed the test I defined after you wrote your email. My test was
that your email should end with the word "Penguin".
--
Pete
====
ECO Modeler, Audio compression components, DIB graphics controls,
FastStrings
www.droopyeyes.com
Read or write articles on just about anything
www.HowToDoThings.com
My blog
blogs.slcdug.org/petermorris/
Penguin
 

Re: Questions regarding the MM challenge...

Quote
Not I. It is we = Fastcode community.
I merely used your own references.
Quote
*I* do not like to have different types of entries in a challenge. *I*
like it
simple. Either it is a full entry or it is not in. *My* personal opinion
only.
We do differentiate quite a lot. Do you see problems in the
AnsiStringReplace B&V?
I only see the winning entry on the website, I don't see the full list.
Quote
We have permission from you and Nexus and this is the only two we discuss?
We are only discussing them as examples. Besides, permission to benchmark
my library is not the same as me submitting it as an entry.
Pete
 

Re: Questions regarding the MM challenge...

Anders Isaksson writes:
Quote
On Mon, 4 Jul 2005 05:31:26 +0200, "Ralf Mimoun" <XXXX@XXXXX.COM>
writes:

>From an end user point of view, I would say that Peter should consider
>to take his function from the contest/comparison/name it.

But *Peter* didn't enter his function to the competition, it was
freely available, and FastCode included it for comparisons.
I don't care who added it and who could exclude it.
Ralf
 

Re: Questions regarding the MM challenge...

Quote
'N/A' is better, but still leaves the reader doubting ("Why is this
routine N/A?").
My proposal is that "N/A" is only used if you are providing a set of
routines (eg, search, replace) and one of them is not included in the 3P
Library.
Where the 3P library functions differently I'd expect to see "Functions
differently", because you cannot compare apples with pears.
Where the 3P library functions the same I'd expect to see an amount of
time taken.
I would not expect any kind of quality label associated with a 3P library at
all.
If there is a list of features that are being listed, instead of (A = fail,
B = fail, C = fail) I'd expect to see
Supported: A, B, C
*but* if D is supported to a different specification I'd expect to see
Supported: A, B, C, D*
--
Pete
====
ECO Modeler, Audio compression components, DIB graphics controls,
FastStrings
www.droopyeyes.com
Read or write articles on just about anything
www.HowToDoThings.com
My blog
blogs.slcdug.org/petermorris/
 

Re: Questions regarding the MM challenge...

Hi Anders Isaksson
Quote
RTLMM: Alignment = 4
xyzMM: Alignment = 16
abcMM: Alignment = 4, 8, 32

or whatever the MM:s support. that is facts, not value statments. The
value of a certain alignment is for the user to decide.
I like that.
Regards
Dennis