On Wed, 07 Jul 2010 14:34:05 -0300 Bernardo Rangel Tura <t...@centroin.com.br> wrote:
> F# is public, but is not open source. > > F# run in windows but run in AIX, linux, MAC, UNIX etc? > > Compiled code should run faster than R, but is precise? > > Compiled code should run faster than R, but is reliable? > > Compiled code should run faster than R, but have 2.440 packages for > extend your capacities? > > Compiled code should run faster than R, but critical code is in C o > FORTRAN > > So I think the F# is not a good alternative, if your concern is velocity > dou you look Littler There is noguarantee that F# would be faster than R even if it is "compiled". R is not -- so far as I can see -- interpreted: the source code is compiled on input to an intermediate format and executed via a bytecode engine. Hmmm... sounds familliar, kinda like Perl and Java and Phytnon and C. C? Yes. Kindly recall that C ocmpilers output assembly code -- the *.a files that gcc gracefully removes for you since few people bother to hand-craft their assy any more. The object files are the result of feeding C's assembly output through an assembler. Unless you can really describe the registers, L1 & L2 locations of every piece of text, BSS, and stack/heap you are the mercy of whomever wrote the C compiler and data handling libraries you link with. Net result: C is not guaranteed to run any faster than native "R" code. Also recall that most of the code today runs on # x86-lineage equipment, where CPU is free to # replace some portions of the assembly with # microcode, execute computations out of order, # and use branch prediction to try and # accelerate execution. Net result: CPU's look kinda like bytecode engines these days. It is worth remembering in any time comparison that R, C, assembly, and well-optimized machine code all block at exactly the same rate: zero. Much of the time in many R programs is spend idle waiting for I/O to disks, memory, and screens. Yup: "memory". Intel still uses the IBM 360 motherboard layout; even the AMD's end up blocking for memory I/O since the on-board controller has to wait for signals from sticks that run at a fraction of CPU clock speed. Unless you can pre-load the entire execution cycle into L1 & L2 there is no way to avoid blocking. Java also introduces the downside of depending on the JVM authors to properly control the performance for your application. In my -- rather limited -- exposure to the beastie, it hasn't handled heavy-duty number crunching or really large I/O all that well. Net result is that the time you save writing code in R will probably outweigh any differences in computation speed between R and even well-written Fortran, probably C, and certianly almost any other language. Happy hacking. -- Steven Lembark 85-09 90th St. Workhorse Computing Woodhaven, NY, 11421 lemb...@wrkhors.com +1 888 359 3508 ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
