Quote:
Originally Posted by Bug John
His theory is based exactly on the same as yours, your personal feelings.
No, it is based on what Anet has repeatedly told us.
Quote:
Haven't you noticed too how good drops are when a new campaign has just been released ? And how fast this quality disappears as more people reach the new zones ?
Not really. They were consistent to me. Up until the anti-farming code was removed I noticed that the first few times I zoned in an area I got better drops - but that was true on each and every character and I just needed to rotate around where I was at and do some missions to get back to the good drops. At the least my gp/hour only has changed on the major AI changes or farming changes listed in the update notes since I purchased prophecies (about 3 months after release).
Quote:
I know gaile said this isn't true, but do you really think anet would explain how the anti farm codes work ? That would make these codes useless.
First off, if they didn't want it known they just wouldn't talk about it. Secondly you already believe nothing other than how you feel - be happy and go with it. I generally try and base what I believe on more than simply a feeling, especially when there is decent data.
Quote:
|
Originally Posted by KartMan
that's because of "prediction", nowadays most CPU architecture has this feature I think, if you call a function with the same parameters, it is highly likely that it will return the same "value" or "array" in our case.
Umm, I do not think you know what "prediction" in modern CPU's are.
Branch prediction in modern CPU's make sure the pre-fetch queue has the correct data in it. The pre-fetch queue will generally hold a number of instructions and (IIRC, it's been a few years) the needed data in high speed on-processor memory, as long as the processor is pulling from there then it generally doesn't have to wait for a much slower read to another memory subsystem (and hopefully to RAM as little as possible), if it predicts the branch incorrectly then the processor has to wait and all the data in the queue dumped and rebuilt. Simple branches are pretty easy - the pre-fetch queue just loads up both branches and discards what isn't used - however with loops and such it isn't so easy. We used to do what is called "loop unrolling": instead of making the loop as small as possible you made it is large - if you knew the loop would repeat in multiples of five - make it five repeated lines. It could *really* speed things up. Nowadays the predictors do a MUCH better job and it isn't really needed, and in some cases can slow things way down because the processor is better able to handle it with pipelines and other modern structures. Note that this is something you only worry about in assembly, not a high level language - your compiler unrolled loops and such.
In no case is the computer somehow fooled because you called a function with the same parameters, if that were true then all sorts of things would fail miserably. It sure isn't uncommon to have a while loop call a single function until it's return value changed - if what you wrote was true that would *never* work. You are correct in that this is where branch prediction has come along ways, but it will not force the same outcome unless all the variable have the same content to begin with. That is caused by the programmer, not the processor, branch prediction, or a cache. |
) cause that's not happening all the time while they get killed at the same time (and it also never happened to me, and i'm sure to the majority of GW players).
