something is changing...

hehehe ... I waited for this for long time!

who?

something is changing...

hehehe ... I waited for this for long time!

who?

You waited for a long time to have a massive number of compute errors?

i think you will find that those compute errors are bad work units rather than a fault on who?'s system

something is changing...

hehehe ... I waited for this for long time!

who?

You waited for a long time to have a massive number of compute errors?

---

63. (1) (b) "music" includes sounds wholly or predominantly characterised by the emission of a succession of repetitive beats

i think you will find that those compute errors are bad work units rather than a fault on who?'s system

something is changing...

hehehe ... I waited for this for long time!

who?

You waited for a long time to have a massive number of compute errors?

And you don t test new code without errors.
I did hunt down my bug one per one, on a known working code, sub routing by subrouting.
i am testing the last bits (Port part from Alex is in debug mode)
I was very busy at work, did not have much time, for those who followed, they understand why.

who?

i think you will find that those compute errors are bad work units rather than a fault on who?'s system

Looks like you're right... As you probably gather from my very low RAC, I haven't been paying much attention to the goings on here... I scanned only the top-level pages... I did see a thread about some bad workunit headers, but I thought they had been taken care of by now...

Oh well...

And you don t test new code without errors.

Looks like I jumped the gun on that one. I had only scanned your result list. I didn't drill down into the tasks to see that others had also errored out...

Sorry... :(

i am testing the last bits (Port part from Alex is in debug mode)

If you're trying to show an architectural superiority and/or a coding superiority, I think you should match clock speeds. With you at nearly 1GHz above the Mac Pro systems, the difference in clock and/or other microarchitecture changes will have an impact if the codebase is essentially the same.

I was very busy at work, did not have much time, for those who followed, they understand why.

I didn't specifically follow, but I do know that IDF is a mere 3 weeks away and you probably have something to do for that...

Francois are you going to run it a stock speed or not?

---

Francois are you going to run it a stock speed or not?

hahaha, Stock speed? what is that? This is an extreme edition CPU :)

who?

Francois are you going to run it a stock speed or not?

hahaha, Stock speed? what is that? This is an extreme edition CPU :)

who?

LOL....I'll second that one....phased Penny at 4.58ghz.....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Yes, but mark, you haven't been hyping some 'wonderful' code for over 18 months.

Who has repeatedly claimed that his code would be superior to Alex's V8, however, if he doesn't run the machine at stock speed, there is no way of knowing. The lack of willingness to do so suggests more hot air.

---

Yes, but mark, you haven't been hyping some 'wonderful' code for over 18 months.

Who has repeatedly claimed that his code would be superior to Alex's V8, however, if he doesn't run the machine at stock speed, there is no way of knowing. The lack of willingness to do so suggests more hot air.

Listen, I did post most of my code on this forum, and it is pretty simple to use it. I did not hide anything, so, put your critics into your pocket, and start compiling what I posted here. Stop complain, I am not your mom, I am not in charge of giving you what ever.

If you can't compile the code I posted here, well, you should not be throwing rocks at me. Thanks!

A Vista machine will be TOP 1, and you can only watch! hehehehehe

who?

Who?, you are the last person who should complain about some one doubting you. You tried to spread blatant LIES regarding Alex's code.

As for throwing rocks, I am actually doing no such thing, if you bother to read my post and not get all defensive, I am just saying that until your machines start posting better times than the top Mac Pro's, all of your talk means nothing. If your code is as good as you so claim, then I will be one of the first to say well done.

If when you put your code live, you run the machines at stock speed we could see how much of an improvement you have really achieved.

---

I agree. It will be much easier to plot a statistically-significant graph of the absolute merit of the code improvements once we see a sustained run at a declared (and verifiable) CPU speed. Stock/nominal would be easiest.

Otherwise, we have to fall back on normalisation techniques such as we used for Joe's 'Estimates and Deadlines revisited' They reveal the strengths and weaknesses of different coding strategies and platforms at different angle ranges, but disguise absolute diffences between platforms - witness the recent, unsuspected, observation that Linux apps appear to be 50% slower than Windows applications. (circumstances still to be fully analysed).

If when you put your code live, you run the machines at stock speed we could see how much of an improvement you have really achieved.

Urmm... no. We (or at least I and others who have collected data) have a base of the CPU times for a host of results at differing angle ranges at 2992 MHz for host 4089150 and near 4000 for host 4081480.

Running new code at those speeds will provide a direct code improvement measure. Running at stock would give less basis of comparison for the code improvement, not more.

---

I agree. It will be much easier to plot a statistically-significant graph of the absolute merit of the code improvements once we see a sustained run at a declared (and verifiable) CPU speed. Stock/nominal would be easiest.

Otherwise, we have to fall back on normalisation techniques such as we used for Joe's 'Estimates and Deadlines revisited' They reveal the strengths and weaknesses of different coding strategies and platforms at different angle ranges, but disguise absolute diffences between platforms - witness the recent, unsuspected, observation that Linux apps appear to be 50% slower than Windows applications. (circumstances still to be fully analysed).

One more time, I will offer cpu time on my phased Penny quad to serve as a testbed for any optimized core 2 code that is offered by a bona fide coder....

It is pretty stable now at 4.58ghz.....

Fred W. is collecting data right now on the 2.4v beta SSE4 compile I am running, and then the current plan is to cut back to SSSE3 and then SSE3 so that he can graph some direct comparisons of the 3 different versions on the same platform.

A new, hand coded SSE4 opti app would be a welcome addition to the test mix.......or even a new SSE3 or SSSE3 code compile if anybody thinks they have any new approaches to offer.....I am not sure at this point if anybody is actively working on new code.....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

A Vista machine will be TOP 1, and you can only watch!hehehehehe

If when you put your code live, you run the machines at stock speed we could see how much of an improvement you have really achieved.

Urmm... no. We (or at least I and others who have collected data) have a base of the CPU times for a host of results at differing angle ranges at 2992 MHz for host 4089150 and near 4000 for host 4081480.

Running new code at those speeds will provide a direct code improvement measure. Running at stock would give less basis of comparison for the code improvement, not more.

This assumes using the same -puter & not an ES Nehalem w/ a modified stderr and cpu ID ;>)

---

Running new code at those speeds will provide a direct code improvement measure. Running at stock would give less basis of comparison for the code improvement, not more.

This assumes using the same -puter & not an ES Nehalem w/ a modified stderr and cpu ID ;>)

By no means is it bullet-proof. My point is that specifying running at stock does not add comparability. I made none of the assumptions you specify, and was not talking about assurance against falsification.

By the way, I look forward to seeing Nehalem here with real enthusiasm.

---

A Vista machine will be TOP 1, and you can only watch!hehehehehe

If when you put your code live, you run the machines at stock speed we could see how much of an improvement you have really achieved.

Urmm... no. We (or at least I and others who have collected data) have a base of the CPU times for a host of results at differing angle ranges at 2992 MHz for host 4089150 and near 4000 for host 4081480.

Running new code at those speeds will provide a direct code improvement measure. Running at stock would give less basis of comparison for the code improvement, not more.

This assumes using the same -puter & not an ES Nehalem w/ a modified stderr and cpu ID ;>)

...and again I pointed out that the best that can be done with the current setup is to match speed down to 3GHz (or 2992MHz... whatever). Since the "stock" speed is 3.2GHz for the 9775, it is still a higher clock speed, so you're not comparing clock-for-clock. Even with matched speeds, the architecture differences will still add some variance, as the 5365 is different than the 9775.

This is why what is being done is not the proper way to "prove" a performance gain of "new" technologies, be that new technology either hardware or software. The company / individual claiming the technological advance should always be willing and able to assist with independent verification in a "clean room" type lab environment. As it stands right now, there are too many variables.

A Vista machine will be TOP 1, and you can only watch!hehehehehe

If when you put your code live, you run the machines at stock speed we could see how much of an improvement you have really achieved.

Urmm... no. We (or at least I and others who have collected data) have a base of the CPU times for a host of results at differing angle ranges at 2992 MHz for host 4089150 and near 4000 for host 4081480.

Running new code at those speeds will provide a direct code improvement measure. Running at stock would give less basis of comparison for the code improvement, not more.

This assumes using the same -puter & not an ES Nehalem w/ a modified stderr and cpu ID ;>)

...and again I pointed out that the best that can be done with the current setup is to match speed down to 3GHz (or 2992MHz... whatever). Since the "stock" speed is 3.2GHz for the 9775, it is still a higher clock speed, so you're not comparing clock-for-clock. Even with matched speeds, the architecture differences will still add some variance, as the 5365 is different than the 9775.

This is why what is being done is not the proper way to "prove" a performance gain of "new" technologies, be that new technology either hardware or software. The company / individual claiming the technological advance should always be willing and able to assist with independent verification in a "clean room" type lab environment. As it stands right now, there are too many variables.

And that is why I have offered my rig to be a 'clean room' to test any claimed advances in code alone..........

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

A Vista machine will be TOP 1, and you can only watch!hehehehehe

If when you put your code live, you run the machines at stock speed we could see how much of an improvement you have really achieved.

Urmm... no. We (or at least I and others who have collected data) have a base of the CPU times for a host of results at differing angle ranges at 2992 MHz for host 4089150 and near 4000 for host 4081480.

Running new code at those speeds will provide a direct code improvement measure. Running at stock would give less basis of comparison for the code improvement, not more.

This assumes using the same -puter & not an ES Nehalem w/ a modified stderr and cpu ID ;>)

...and again I pointed out that the best that can be done with the current setup is to match speed down to 3GHz (or 2992MHz... whatever). Since the "stock" speed is 3.2GHz for the 9775, it is still a higher clock speed, so you're not comparing clock-for-clock. Even with matched speeds, the architecture differences will still add some variance, as the 5365 is different than the 9775.

This is why what is being done is not the proper way to "prove" a performance gain of "new" technologies, be that new technology either hardware or software. The company / individual claiming the technological advance should always be willing and able to assist with independent verification in a "clean room" type lab environment. As it stands right now, there are too many variables.

And that is why I have offered my rig to be a 'clean room' to test any claimed advances in code alone..........

Clean room? With all that cat hair?

---