Zitat von Kuba Ober <[EMAIL PROTECTED]>: [...] > If you count the "efficiency" of such out-of-the-blue uncached truly > random > access in terms of clock cycles, current hardware may be 1-2 orders > of > magnitude less efficient than almost any 8-bit microcontroller out > there... > On most MCUs you can read a random byte out of the SRAM in say 1-4 > clock > cycles. On your commonplace modern multicore CPU, it may take a > hundred clock > cycles to do the same, and essentially the same amount of time in > terms of the > wall clock (a 2GHz CPU has only 100 times faster clock than a run of > the mill > 20MHz MCU). [...]
Given a RAM with a certain clock frequency, when the Microcontroller works at the same frequency as the RAM, and a CPU of a typical computer uses a much higher frequency, it's normal that the CPU has to wait longer. That's thze reasion why cache-RAM is used on more then one level. But there are also processors, that can lookup RAM while at the same time working on instructions that were fetched before. Some DSPs are really fast... for example Analog Devices' TigerShark can do between one and four operations in one clock cycle (on average two instructions per cycle). And itÄs a single-core DSP. When it runs at 600 MHz, it can do 32-Bit Floating-Point operations with 3.6 GFlops. http://www.analog.com/en/embedded-processing-dsp/tigersharc/content/tigersharc_benchmarks/fca.html OK, this is a very specific processor and comparing it with CPU's of the computers we are using today, is maybe a littlebid inproper. But I just wanted to say: a good design can do a lot things possible, which may not be used in many CPUs. For example the TigerShark also has links to other processors and therefore can be used in multi-processor systems. http://www.analog.com/en/embedded-processing-dsp/tigersharc/content/tigersharc_processor__architectural_features/fca.html http://www.analog.com/en/embedded-processing-dsp/tigersharc/content/tigersharc_architectural_backgrounder/fca.html And the idea of Links between processors was used in the 1980's by T-400 and T-800 from INMOS: http://en.wikipedia.org/wiki/Transputer It seems, they were too far ahead to be commercially successful. Ciao, Oliver P.S.: Remember the Altivec unit of G4-processor, for example... ...they also gave good speedup and Math-speed. So, a good CPU-design can give advanatges in speed. > > What I'm trying to say is that such random, small memory accesses > highlight > the inherent message passing / transactional overhead of the hardware > implementation. Those overheads amortize when you run real number > tasks, > not a made-up cold single byte access of course. But they are there. > > It's akin to mmaped file: you can use CPU's MMU to implement it in > the > usual OS/stock hardware framework, or you can have an FPGA handle > memory > transactions and talk directly to the hard drive. It doesn't change > the > fact that it's still a mmaped file :) > > Cheers, Kuba > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
