They seem to have put a ban on me or on the mere mentioning of the topic of optimizing a certain piece of FPC code on the mailinglistm, even though I explicitly changed the thread topic. I did not know that it is not allowed to discuss concrete code examples (or certain types of code examples) on the FPC list. So I re-send a copy of my latest answer to this thread to you directly (and to the other mailing-list) which bounced from the list server.

here is the bounced mail:

2011/5/9 Lukasz Sokol :

> or they try to _parallelize_ it behind the machines' back ? Oh yeah, look:

Yes, but it also runs 5 times faster on only one CPU.

The reading into the buffer does not contribute any noteworthy amount of time according to my profiling. By FAR the most time is spent with building up the hash table with *millions* of entries (which includes looking up each potentially new entry before adding it).

Bernd Kreuss wrote

They seem to have put a ban on me or on the mere mentioning of the topic of optimizing a certain piece of FPC code on the mailinglistm, even though I explicitly changed the thread topic.

As I also replied to your mail sent to fpc-pascal-owner:

***
That topic [optimizing a certain piece of FPC code] is not banned per se. In fact, I let through a few initial messages after I had put in place a subject line filter, because they were indeed only about that. I completely agree that it was not consistent to later on reject all messages in that thread. That's also why it took a few days, because I was not sure about what to do.

The problem was that several messages mixed advocacy discussions with optimizing discussions, and that several people did already go through the trouble to subscribe to fpc-other and post their remarks to that list after the initial mail asking to continue the discussion there. Since I had to be inconsistent regarding at least one of the two parties, it seemed most appropriate to proceed along the lines of the request in the original mail I sent asking to move the discussion to fpc-other.

...

You are not placed in moderation mode, only (part of) the subject line of the thread you were posting in. ***

Jonas

--- On Sat, 5/14/11, Bernd Kreuss wrote:

-snip-

The intention behind k-nucleotide task was to test hash table performance.

It is allowed in general. In fact these benchmarks have been discussed several times on the fpc mailing lists. There were even some compiler optimizations. But afaik it turned out that these optimizations and the discussions didn't help any real world application. So it is an interesting sport for some programmers, but mostly a waste of time for all others. I guess that's the reason for moving this thread to fpc-other.

Mattias

Jonas Maebe wrote

As I also replied to your mail sent to fpc-pascal-owner:

I have overreacted, it simply was the wrong moment when I saw the bounced message in my inbox. Sorry.

Bernd

Mattias Gaertner wrote

But afaik it turned out that these optimizations and the discussions didn't help any real world application. So it is an interesting sport for some programmers, but mostly a waste of time for all others.

I think its still useful doing this sport to learn a bit about not so obvious oddities of the compiler that one would only notice by coincidence.

For example by doing this I have (accidentally) learned that (with FPC 2.4.2) the expression

(x shr 1) and $03

would for some reason be translated into *much* smaller and faster code (it reduced the total time of a tight loop by roughly factor two!) than the following code to achieve the same:

(x and $06) shr 1

which I would have never intuitively expected to happen. And I believe there exist more such "tricks". For example using different loop constructs, it seems for example after a bit of experimenting I should often favor the repeat until loop over all other types of loops.

Bernd