Comment Re:Did n't even know (Score 0) 89
I get that my point is, I'm aware of flash, dreamweaver, etc even though I don't use them yet I've never heard of this product.
I get that my point is, I'm aware of flash, dreamweaver, etc even though I don't use them yet I've never heard of this product.
I use Visual Studio and never heard of it before today yet apparently I should have because it is now being integrated in to a product that I use on a daily basis.
that Microsoft even had a design suite. I guess that shows how successful it was.
Just saying that going with Android makes Nokia another "me too" company totally discounts that Noka phones are always beautifully designed and very robust.
The last two nokia phones I've had have terrible software problems but I could not fault the hardware. Where as my experience with HTC phones one had a joystick that broke and my current HD2 has had the USB power connector fail on me.
If they had gone with Android they could have easily competed with Samsung and had a good percentage of the Android smartphone market. The problem is Elop somehow managed to convince people that with Windows Mobile he could restore past glory and be like Apple. Sure they now have nearly have 100% of the Windows Mobile market, but whats that at the moment? 1% of smartphones?
The thing is Elop does n't understand the industry, he came from Microsoft. He's a Microsoft man, the question at the time should have been something like this "We have two available OS options, one has a proven record of being something customers want and the other has failed pretty badly up to now." . Which one would you go with? Sure you will have to compete with Samsung with the same OS, but they're now competing with Apple, Samsung and everyone else with a different OS and failing badly.
Regardless, it's a moot point now but I don't recall anyone at the time saying this was going to end well for Nokia.
Your blender only goes up to 9? Mines goes to 11.
I was under the impression that Itanium was all but dead. I'm guessing Intel must be contract bound to bring out new versions.
There is no way the goverrnment could enforce that kind of behaviour, if they could they would have used that ability to collect the correct amount of corporation tax in the first place.
The problem is VAT is n't a tax on companies, it is a tax on consumers with the companies being able to claim back their VAT expenses due to them acting as tax collectors for the government. An increase in VAT would immediately be passed on to the consumer.
> In the end, the few uses of conditional execution
That why x86 introduced cmov for doing conditional mov ?
I'd wager that there is n't a conditional move uOP when the x86 cmov instruction is decoded, in fact on the original P6 arch there is n't a major speed improvement by using cmov in fact cmov performance various considerably from processor to processor.
I meant 43% not 47%.
I'd wager that a large percentage of the 47% are businesses with a large number of seats and pretty much a standard application set, introducing a new application into these kind of environments are normally a big descision anyway with the likelyhood of a role out of new hardware/OS.
If the support contract for your software has come to an end and the supplier is no longer willing to support older software then you obviously have a business case for an upgrade. However as Microsoft will provide security updates for XP until 2016 why upgrade now?
If you are a company that has a working system that runs fine, why would you force an upgrade just because XP is n't used by consumers any more? Even if you put the economic costs at zero which it certainly is n't and the summary brushes aside way to casually; you always have a risk factor of unforseen issues getting passed testing.
No business should upgrade for the sake of technology fashion, weather it be OS or applications. Hell you see companies running custom DOS programs all the time.
This is why modern x86 processors have a trace-cache for decoded instructions.
in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
New x86 instructions did n't use escape codes, they used unused opcode space, the instruction format has n't changed much since the 386. In fact when going to 64-bits the default data size and some of the fields meanings where changed but other than that nothing radical.
so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
This makes no sense, instructions on modern x86 processors are decoded and stored in the trace cache, in a loop the processor is executing pre-translated instructions. In fact on AMDs latest CPU architecture instructions cant be sent to the execution units fast enough.
intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
AMD has n't done this for years, and when they did it was because their processors had higher a IPC count than Intels at the time so MHz was not a fair metric to compare the processors.
but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Erm, Intel had VLIW, remember Itanium? Other than in highly parallel number crunching workloads it was being outperformed by Intels own x86s. For general computing VLIW sucks, program execution is just too dynamc.
Every modern CISC chip is basically a dynamic translator on top of a RISC core.
And that's the problem for power consumption. You can cut power to execution units that are not being used. You can't ever turn off the decoder ever (except in Xeons, where you do in loops, but you leave on the micro-op decoder, which uses as much power as an ARM decoder) because every instruction needs decoding.
If it was just the case of turning off execution units for a processor with a simpler decoder then the Cortex-A9 would n't have the need for the extra low-power fifth core.
Thus spake the master programmer: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"
