[R] F# vs. R

[Steven Lembark]

On Wed, 07 Jul 2010 14:34:05 -0300
Bernardo Rangel Tura <tura at 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
lembark at wrkhors.com                                    +1 888 359 3508