CKeichel said:
Note, that I don't say it's a lie to say the Caanoo is 10% slower then the Wiz, but if you come up with this, you should be able to say what you benched, otherwise it is completely pointless, cause nobody can verify or falsify these results.
Now you change the terms again, now you speak of "emulators" in general, before you spoke of fast emulators that don't use SDL. Note that there are emulators on the Caanoo, that use SDL.
You're nitpicking.
Where performance matters those SDL based emulators are going to be replaced by emulators not using it. Until then they're simply at a disadvantage compared to Wiz where the commonly used emulators that have any kind of performance dependency aren't using SDL already. So yeah maybe SNES on Caanoo is using SDL right now, but it isn't on Wiz, and eventually it's PocketSNES that should be on Caanoo. Just for example.
Where performance isn't limited in either case the whole question becomes moot.
CKeichel said:
I don't say, there can't be problems with Optimus benchmark, all I say is, that it is strange to say the Caanoo is 10% slower then the Wiz, and refuse to say, were these benchmark results come from or what exactly was benched and then, when a public benchmark shows something else, claim, that this benchmark may be faulty.
First of all, he did say a benchmark where he's observed 10%, it was in Picodrive - you're more than welcome to test it yourself and come up with your own findings to verify or deny this.
I'm not saying what other emulator he ran because he doesn't want it to be public. You may think it's "strange" but it's not that hard to imagine some reasons why someone isn't at liberty to talk about something like this. Think about it a little harder.
What you're leaving out of your explanations is that I have a validation behind everything I say. Caanoo is often slower, up to 10% so, than Wiz because CAS latency. Empirical support that this would happen - on Wiz, tweaking parameters that are also proportional to memory usage but less frequently can effect by at least 4-5%. Your rebuttal - changing CL on some PC caused a much smaller result. I gave several reasons why this PC would be less sensitive to CL but you just ignored it.
So now we see a test where Caanoo is faster. We already know it's not the same software running (we were comparing hardware, you know), we know the SDL is different and furthermore we know of variables that can effect this a lot.. so there are viable explanations for why this could be happening that have nothing to do with the software. What explanation is there that Caanoo hardware can be faster than Wiz hardware? In the scientific method experimental results are theoretically supreme, but an experiment can always be flawed and contained uncontrolled variables or incorrect methodology. Good science should always question experimentation with theory as much as it questions theory with experimentation.
You're saying now that it's not about doubting my comments, but you've posted saying this benchmark proves that my comment that Caanoo can be 10% slower is false. Well sorry but it doesn't prove that. Yes, it shows that there are software situations where this can happen, that are very sensitive to firmware version, but so what? That's always the case. I don't know why you're fighting me so hard on this if you say you're not against my comment. Lordus has already confirmed himself as my source and confirmed my comment so that really removes me from the equation.. if you have a problem with his comment either you think he's lying or you think he's incompetent. Otherwise what's your problem exactly?
Anyway, Optimus already said he'd do one that doesn't blit the screen and therefore removes SDL screen update performance out of the equation. Maybe we can get him to use the framebuffer directly, like everyone else who cares about performance should be doing.. he can use libcastor or something. If he wants direct 320x240 it'll mean diagonal tearing but I think for the sake of this benchmark that should be the preferred route.
EDIT: Okay, I see Optimus posted new results.
Honestly, I think the best thing to do is to do now is to a) make sure the time base is correct, and probably use hardware timers anyway B) check it out on other people's rigs, and make sure all the pertinent registers are set the same (clocks, RAM timings) as much as the hardware allows to confirm the same thing is tested c) release the source code so it can be thoroughly analyzed to see exactly where the cycles are spent...
Here's another question for you Optimus:
What kind of RAM are you accessing, is it purely stuff allocated with malloc or are you mmapping stuff that's in the "high" memory section? Or, despite not calling SDL_Flip, are you writing to an SDL_HWSURFACE? If you're writing to RAM allocated by SDL it's possible it's in the high region, and it's possible that one version has write buffering enabled and another doesn't. This makes a big difference in performance (which is why we had mmuhack/wARM stuff on GP2X and Wiz)
