Re: f0dder, the agony and the ecstacy. :)
- From: "f0dder" <f0dder.nospam@xxxxxxxxxxxxxxxx>
- Date: Mon, 16 Oct 2006 00:54:11 +0200
Try to show just a little bit of honesty by answering these points clearly
and in order.
Let us recap the situation, cannot or will not deliver the goods,
"the goods"? If you're referring to the licensed Microsoft source, it should
be obvious why I can't republish it - and I already told where to obtain it,
anyway. If you're talking about the no-source binaries you published years
back, it's because I fail to see the relevance with regards to my
"PowerBASIC code generation sucks".
wants to use external source from his compiler with unpublished
binaries but wants to restrict a humble basic compiler to the
bubblegum range of output to back up outrageous claims he has been
trying to make for years.
"unpublished binaries"? I'm using LIBC, for which the source is available at
the locations I've already given. Source isn't available for the PowerBASIC
"ARRAY SORT", so I fail to see why this is even a point to you.
Cannot write a clear, intelligible or reliable real time timing and
has to massage a range of obscure techniques to represent his own
output as something special when in real time,
"obscure techniques"? QueryPerformanceCounter for the timing, output as
HIDWORD:LODWORD for easier readability. OutputDebugString for output might
be a bit "obscure", but it doesn't affect the timing in any way...
his so called fastest algo is slower than his C library routine.
Say... what? STL std::sort is not "my routine", and I don't see where I
claim it was the fastest (I was a bit surprised that it comes out slower
than qsort(), but that's probably because of the dataset - *shrug*).
Would not change his source to produce reliable and clear timings and
desperately wants to avoid anyone else doing it.
You're the one that don't have clear and reliable timings - and furthermore
you don't provide all source, so people can't modify to gain reliable
timings. I, on the other hand, provided full source so you could have
changed the timing method if you wanted.
Has misrepresented a simple example that was written for him a couple
of years ago and claimed to know enough about both languages to write
a benchmark between them even though the simple example had data type
errors that made it a lot slower and even in the face of having the
source code corrections posted in the ALA newsgroup, he wants to shift
the responsibility to me for code I did not write.
I assume you're now talking about the CircleSieve and not the sort... You
still haven't pointed out the "data type errors", as far as I know. I didn't
write the PB code for that, so you'd have to take up "data type errors" with
Brad Byrne. The C++ conversion of the algo was implemented in the same way,
without any tricks to speed it up.
In the face of being shown up for his claim of 3.5 times faster as
simply dishonest, he has rewritten his own example and wants to try
again.
I admitted I was wrong, re-benchmarked, and posted results showing 2x faster
than the original code. *then* I fixed up the code a bit and re-did
benchmarks, which was 7x faster than the original. Since you haven't
published neither source nor executables for *your* fixed up version, I
can't benchmark it against mine.
As for dishonest, I've posted source and executables as well as explained
how I tested, so people can check for themselves.
A simple PB example constructed from my PB junk is faster on 2 of my 3
PIVs than his best and his best which is a quick sort is faster than
his choice of an STL template source that is supposed to be faster
than hand coded assembler from a superior compiler.
Which example are you talking about now? The new sort which you have not
published source for? That sort routine looks like 's handcrafted assembly,
not PowerBASIC code. Furthermore it's integer only and does inline
comparisons instead of "call comparefunc" - no wonder it's faster than
generic libc code.
Also, where does "his choice of an STL template source" come from?
This much is clear, on a level playing field, (the one where
application code is designed and sold) he has failed to produce the
superiority he has claimed against a native code basic compiler that
is designed to produce code the way the author writes it and DOES NOT
MODIFY YOUR CODE to fix your mistakes.
Translated to plain English: "PowerBASIC cannot compete with MSVC in terms
of code generation or standard library speed, so users are forced to write
inline assembly to get decent speed". Nothing wrong with that, I can use
inline assembly in MSVC as well (or I can use an external assembly module,
not possible with PowerBASIC unless you write it as a DLL).
The humour is it his C code DID succeed in being something like 8
TIMES LARGER and no faster. Exactly the reason why so many
programmers are using PowerBASIC, they will not accept the BLOAT even
if the advantage was what f0dder has claimed.
CircleSieve: 4kb C++ exe versus 21.5kb PB exe, and 7x faster. (test of code
generation)
Sorting code: 80kb C++ exe versus 14.5kb PB exe, between 3x and 8x faster
depending on processor. (test of standard library quality). I believe most
people would prefer speed over size, 80kb is inconsequential, and it would
be easy to reduce it to a lot less anyway.
But obviously you want to compare against your latest sort. In other words,
handcrafted assembly that only works on integers, compared to vanilla C code
that's generic for any datatype, and has to "call comparefunc" for each
test.
I'm surprised your handtuned asm is only 8ms faster than the generic C
code...
.
- Follow-Ups:
- Re: f0dder, the agony and the ecstacy. :)
- From: hutch--
- Re: f0dder, the agony and the ecstacy. :)
- References:
- f0dder, the agony and the ecstacy. :)
- From: hutch--
- Re: f0dder, the agony and the ecstacy. :)
- From: f0dder
- Re: f0dder, the agony and the ecstacy. :)
- From: hutch--
- f0dder, the agony and the ecstacy. :)
- Prev by Date: Re: ROM BASIC, the REAL THING[tm] (well almost). :)
- Next by Date: Re: ROM BASIC, the REAL THING[tm] (well almost). :)
- Previous by thread: Re: f0dder, the agony and the ecstacy. :)
- Next by thread: Re: f0dder, the agony and the ecstacy. :)
- Index(es):
Relevant Pages
|
|
