Actually I didn't have time enough to check all the posts,Originally Posted by phantomotap
I've been quite busy lately.
I didn't even see somebody was trying to buid a mega-array. :-)
Or I just skipped it thinking it was too much to handle.
Thanks anyway for your comments, no matter what.
A profiler runs in the background as another program.
The output is just everyone's formatting of a string of random numbers. It's not important.
I arranged a test on my computer for a few versions we've seen in this thread, and posted the results in the headtohead.txt file (the very post you replied to). If you just wanted to know which one is the fastest of them all, then anyone could run a profile and tell you. So I did. I posted the code so people understood what I profiled. Then they could argue about the results, except, spoiler: nobody cares.
The fact that I did this test on my computer and not yours -- that I have no idea what kind of profile you really need -- is exactly why information like what CPU architecture I have; what compiler, version, and build options I used are important. After all, if you want to format integers on a CRAY supercomputer, my podunk system means nothing to you.
Though, I can guess you're not after anything like that. TBH, this is getting quite out of hand and silly. There are plenty of people in computer science who think they care about performance. They care (emotionally) about wasted milliseconds. When I posted my recursive version, everyone took a big performance ........ all over it.
Don't get me wrong, they were correct . It still only took about 300 milliseconds to format the average integer. In private tests, Adak's method was only about 20 milliseconds faster. If you are in such dire straights that you need that improvement, fine, but I do not think you have the foundation to be making such judgments. You should not be worrying about it. There should not be a great difference between competent, correct versions in terms of speed.
Think about performance on a case by case basis for now. You have some idea how patient I was, waiting for one million formats to occur and be displayed. You are most likely not going to be using it like that.
Last edited by whiteflags; 07-07-2010 at 01:28 PM.
Absolutely. And let me also hilight that correctness is far more important than speed. The first version I posted, using sprintf is absoultely far preferable to my later versions because it was quick and easy to write, easy to read, and clearly correct.
Something like the last version I wrote is the kind of thing that should only be the domain of library writers. I.e. I wouldn't be surprised if when taking out the lines that add commas, that it gives Microsoft's itoa a run for its money.
The typical programmer shouldn't have to deal with this kind of thing though.
Elysia and Adak, I think the rest of us are past caring about whatever the disagreement is, and you know each other's position. There is nothing more to be said.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
or whatever the length of your buffer is.Code:#define BUF_LEN 15
memmove needs
#include <string.h>
I was going to ask a moderator to delete those posts once we have reached a settlement.
The algorithm is usually much more important than whether it's coded in C or assembly.Actually your test is about 5 times faster than the one I used last.
It is however faster than assembly tests somebody did, so it is quite
improbable that it is just the better compiler, something else should be
the reason.
A quicksort written in C compiled by a lousy compiler will still be orders of magnitude faster than a bubble sort coded in optimal assembly, on large arrays.
Even when it's the same algorithm, unless you have extensive experience in assembly and VERY good understanding of the hardware you are working on (how many cycles each instructions take, what instructions can be executed in parallel, what's the cost of branch misprediction etc), you probably still won't beat a modern optimizing compiler.
Modern compilers are just way too smart. And they have all the extensive hardware knowledge coded in.
Usually the best optimization is to keep your code as simple as possible (but with a fast algorithm), so the compiler can optimize better.
So you can have the argument again at a later time when you've conveniently forgotten everything you said?
I take it back. My last version was a waste of time. Compilers already perform the same optimisation trick, except that they are able to do it using the high 32-bit part of a 64 bit result from multiplication of two 32-bit numbers. This means that they can do the same tricks themselves, but more efficiently.
See here: ridiculous_fish » Blog Archive » Labor of Division (Episode 1)
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Forget that Adak uses Turbo C? That's unlikely to happen...So you can have the argument again at a later time when you've conveniently forgotten everything you said?
Either it's deletion time or it's moving time. But putting all this in a special thread?
Why don't you just leave things alone and appreciate this thread with all its warts. Maybe if you leave things alone, you will remember how ugly this thread was. If we let you delete history, you both will never learn from it.
Tough, because you guys mix the on-topic stuff with the off-topic stuff. Just live with it.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
o_OI take it back. My last version was a waste of time.
Bummer.
Soma
To clarify that, I was going to ask to either delete the posts or move them. Ask if the keyword.
And initially, I was going to ask not because it looks bad to me, but because it looks bad to everyone else (like hijacking).
Anyway, the moderators judgment is final.
Besides, it is also possible to edit the non-topic stuff.
Thanks.
Now it compiles, but the output is weird:
Maybe I forgot something else.Code:Testing version : 0.60 ---------------------- The value of num is: -1234567890 The formatted value of num is: ☼ Elapsed ClickTime: 1,420 to perform 10,000,000 cycles of the formatting function
Attached the whole source for your convenience. :-)
Well, Malcom your code wasn't a waste of time at all.
You had a very nice idea and coded it with standard C, with
outstanding performance.
Even if some compiler is able to do that, it doesn't mean that
your effort if worthless.
I have appreciated it very much. And I'm going to study it as well
time and knowledge permitting.
:-)
