3 ms·

I think you may have unwittingly proved ACow_Adonis' point just now.

epistasis 13y ago
If so, I have absolutely no clue what the point was. He referred to Wirth's Law, but the way to make software faster as the hardware gets faster is to abandon the idea of individual unboxed numbers, and move to vectors, as that's what the hardware is using. R, like APL, is much better in its intended domain for being a vector-based language rather than a scalar based language. If the application domain is a scalar based domain, then R is probably the wrong tool for the job. If somebody doesn't understand the cases where vector-based language is better, they've probably never encountered the right application domain for R.
- zwieback 13y ago
  I think the original comment about unboxed numbers was not referring to vector vs. scalar but to boxing of primitive types (integers/floats) in object or other type wrappers: http://en.wikipedia.org/wiki/Object_type_(object-oriented_programming) http://en.wikipedia.org/wiki/Object_type_(object-oriented_pr.... It's easy to imagine situations where languages that directly support vector types could have performance benefits, especially on HW that supports vector instruction sets. On the other hand, languages that don't directly manipulate numbers in the native format of the CPU(s) will peform poorly for large datasets.
  - epistasis 13y ago
    I still don't know what the OP's point is, then. There are vector types and there are list/object types in R. The advantage of vectors over scalars for this field. Having to have a special case in the language of vector length equal to one is a disadvantage when all modern workstation architectures are vector based for computation. R is basically Lisp with syntactic sugar for BLAS/ATLAS and incredibly easy bindings for FORTRAN, C, and C++. If this description doesn't sound like an amazing combination for an application domain, then it's not in R's sweet spot.
    - freshhawk 13y ago
      Vectors vs scalars is a different issue than boxed/primitive types. Of course you want to be working with vectors for these kinds of problems. But the ability to work with vectors of primitives rather than vectors of boxed types is about enormous gains in efficiency and memory usage. This is one of the reasons that R is so slow compared to other tools.
- sveme 13y ago
  Now I am confused. My understanding is that when I apply a function on a vector etc. in R, I call some compiled C code in the background that translates this into a straightforward for loop. The hardware would not work on vectors but on scalars in this case and vectors are just a more condensed and more math-y interface for users. You're saying that R actually never works on scalars in the background? Maybe I'm missing something here.
- sixbrx 13y ago
  It almost has to be a vector based language given its speed shortcomings, because that's the easiest way to package the canned C routines in manageable chunks to speed things up. Which C routines are just loops that manipulate scalars, btw. Unfortunately "vector" operations typically cause a lot of temporary intermediate vectors that you never see, which is why a "scalar" language like Julia or C can provide such performance improvements when they handle the whole algorithm without the unnecessary intermediates having to be allocated and filled. I think the vector operations do provide a certain brevity though. Whether this is an advantage or not is very subjective. For myself, I prefer having anonymous functions and operations like "map" for transforming collections (including matrices and vectors) element wise, instead of having all operations that make sense on numbers automatically also operate element wise on vectors and matrices. (Because there are operations on vectors and matrices as a whole, sometimes with the same name as a scalar function, which can lead to confusion - exp being one example and multiplication being another). But I can understand opinions differ in that regard and a lot depends on how "general purpose" the surrounding programming context needs to be.
  - srean 13y ago
    Spot on. One major reason why languages such as numpy are slow compared to what they are implemented in is precisely what you said, gratuitous creation and destruction of costly temporaries. In the Numpy world this can be mitigated somewhat with tools like numexpr. R is lazy, so I expected it to be faster than Numpy so was surprised that its is so much slower. Julia seems headed in the right direction and I am very excited about it. I really wish they had a mechanism to desugar vectorization syntax in to dumb loops which could then be JITed. Vector syntax can be really expressive, aligned with the problem domain and succinct, I would hate to let go of that in the interest of speed. Its strange that many correlate verbosity with clarity/readability. @ihnorton sadly I can only offer a single upvote
    - ihnorton 13y ago
      You might be interested in: https://github.com/lindahua/Devectorize.jl https://github.com/lindahua/Devectorize.jl (not 100% general yet AFAIK, but already very useful. The code is a great read too)

If so, I have absolutely no clue what the point was. He referred to Wirth's Law, but the way to make software faster as the hardware gets faster is to abandon the idea of individual unboxed numbers, and move to vectors, as that's what the hardware is using. R, like APL, is much better in its intended domain for being a vector-based language rather than a scalar based language. If the application domain is a scalar based domain, then R is probably the wrong tool for the job. If somebody doesn't understand the cases where vector-based language is better, they've probably never encountered the right application domain for R.

zwieback 13y ago
I think the original comment about unboxed numbers was not referring to vector vs. scalar but to boxing of primitive types (integers/floats) in object or other type wrappers: http://en.wikipedia.org/wiki/Object_type_(object-oriented_programming) http://en.wikipedia.org/wiki/Object_type_(object-oriented_pr.... It's easy to imagine situations where languages that directly support vector types could have performance benefits, especially on HW that supports vector instruction sets. On the other hand, languages that don't directly manipulate numbers in the native format of the CPU(s) will peform poorly for large datasets.
- epistasis 13y ago
  I still don't know what the OP's point is, then. There are vector types and there are list/object types in R. The advantage of vectors over scalars for this field. Having to have a special case in the language of vector length equal to one is a disadvantage when all modern workstation architectures are vector based for computation. R is basically Lisp with syntactic sugar for BLAS/ATLAS and incredibly easy bindings for FORTRAN, C, and C++. If this description doesn't sound like an amazing combination for an application domain, then it's not in R's sweet spot.
  - freshhawk 13y ago
    Vectors vs scalars is a different issue than boxed/primitive types. Of course you want to be working with vectors for these kinds of problems. But the ability to work with vectors of primitives rather than vectors of boxed types is about enormous gains in efficiency and memory usage. This is one of the reasons that R is so slow compared to other tools.
sveme 13y ago
Now I am confused. My understanding is that when I apply a function on a vector etc. in R, I call some compiled C code in the background that translates this into a straightforward for loop. The hardware would not work on vectors but on scalars in this case and vectors are just a more condensed and more math-y interface for users. You're saying that R actually never works on scalars in the background? Maybe I'm missing something here.
sixbrx 13y ago
It almost has to be a vector based language given its speed shortcomings, because that's the easiest way to package the canned C routines in manageable chunks to speed things up. Which C routines are just loops that manipulate scalars, btw. Unfortunately "vector" operations typically cause a lot of temporary intermediate vectors that you never see, which is why a "scalar" language like Julia or C can provide such performance improvements when they handle the whole algorithm without the unnecessary intermediates having to be allocated and filled. I think the vector operations do provide a certain brevity though. Whether this is an advantage or not is very subjective. For myself, I prefer having anonymous functions and operations like "map" for transforming collections (including matrices and vectors) element wise, instead of having all operations that make sense on numbers automatically also operate element wise on vectors and matrices. (Because there are operations on vectors and matrices as a whole, sometimes with the same name as a scalar function, which can lead to confusion - exp being one example and multiplication being another). But I can understand opinions differ in that regard and a lot depends on how "general purpose" the surrounding programming context needs to be.
- srean 13y ago
  Spot on. One major reason why languages such as numpy are slow compared to what they are implemented in is precisely what you said, gratuitous creation and destruction of costly temporaries. In the Numpy world this can be mitigated somewhat with tools like numexpr. R is lazy, so I expected it to be faster than Numpy so was surprised that its is so much slower. Julia seems headed in the right direction and I am very excited about it. I really wish they had a mechanism to desugar vectorization syntax in to dumb loops which could then be JITed. Vector syntax can be really expressive, aligned with the problem domain and succinct, I would hate to let go of that in the interest of speed. Its strange that many correlate verbosity with clarity/readability. @ihnorton sadly I can only offer a single upvote
  - ihnorton 13y ago
    You might be interested in: https://github.com/lindahua/Devectorize.jl https://github.com/lindahua/Devectorize.jl (not 100% general yet AFAIK, but already very useful. The code is a great read too)