Thank you for the advice !
I had to turn off the privacy configuration of my firewall for seeing "pencil&paper" (cookie related rules).
Does the thread title now better reflect the subject of this discussion ?

I started, crunching years ago, with UD - Phase I, hoping to "fight Cancer".

I was really looking forward to another Cancer project here with WCG. On the other hand, I hate having my machines waste their time, taking way to long on HCC units. I have two dual Clovertown rigs and it was sad to see how long an HCC WU took on them.

So until I hear that the HCC issues are over and it is "all clear", by more than a few people, I'm done with them. Back to FAAH and Dengue, for me; I changed my Project profile and excluded HCC.

Hi Jean,
you're right, I will try to find a better formulation in order to not induce people on the false way.
I hope everything is going well by you, since news from Decrypthon team are rare currently ...
Have a nice week-end,

I suppose I'll dip my toe into the water again. Brrr. . . it's chilly!

A page fault occurs when the core wants to access memory that is not loaded into cache. This will slow things down because the kernel will have to load a new page from memory into the cache, while the core waits. Any application with a lot of page faults will run more slowly than one with only a few. But there is a second possible problem with performance. Multiple cores can 'queue up' a series of page faults so that each core has to wait until its own page fault gets serviced. This is called memory contention. If a number of cores are running applications with a high number of page faults, then performance will drop even more because of this memory contention.

How can this performance inefficiency be cured? The normal way is to run a preprocessing step over the data arrays and produce a new array that clusters data together the way that the program will access it. Sometimes this is possible. Unfortunately, sometimes it is not. It all depends on the algorithm. Even when it is possible, it produces unreadable data structures. This need not be a problem but when developing a new program that has to be rapidly changed to match research needs it is almost always a problem.

[A personal reminiscence. A generation ago I spotted a neat 15-25 line section in an image processing assembler routine that I could optimize to speed up the program by 10%-15%. Even with paperwork, this change only cost me 2 or 3 days and we were running it constantly on a number of computers, so I considered it time well spent. I actually congratulated myself about this. (sob..) A little more than 2 years later the new computers changed the cache organization and I suddenly realized that my change was bound to cause problems down the road if the cache changed even more. After thinking it over for an hour, I eliminated the change. Programming to meet specific cache designs is very dangerous practice that has to be considered very suspiciously.]

So what is my estimate of the situation? I don't think that it makes sense to reprogram the application for this. The project scientists should be concentrating on the results and overworking the programmers to change the application to produce better results. Faster should be ignored at this stage.

But how should individual members of the World Community Grid feel about this? The high page-fault count is simply an artifact of the algorithm. It will slow down the flops/second but that will not matter as such. The CPU time spent running the kernel to load in new pages will show up as reduced credit, but for a single core the points impact should not be substantial. Memory contention will be much more substantial, so 4 and 8 core machines would show a much greater drop in points if running more than 1 HCC work unit. The WCG scheduler is sending out the HCC work units so a member can eliminate HCC from these multi-core machines without slowing down progress on HCC. And they could then run other projects such as FAAH and DDT that would otherwise have to run on the single core computers that can handle HCC with the greatest efficiency.

An unrelated note. Some days ago someone posted a work unit awarded 8.3 points in this thread. This was immediately reported to the WCG staff. I don't know what went wrong and we have a number of more urgent issues, but it is an error unrelated to the main problem being addressed in this thread.

Lawrence

Many thanks Lawrence for these clear explanations.
Indeed after the problem has been identified, I think that many of us have deselected the HCC project for their multicore-machines.
However this particular behavior is curious especially because it not occurs with this dimension for other projects.
I agree with you regarding the danger caused by particular software optimizations which would have been initiated for fitting specific hardware constraints.
I wish you large success by further supporting WCG.
Cheers,