ELelcritch·Mar 12, 2016
Found this to be pretty handy at times: [Devec](https://github.com/lindahua/Devectorize.jl).
In Julia: A Fast Language for Numerical Computinglindahua
Devectorize.jl
Julia2013–2016
lindahua / Devectorize.jl
Devectorize.jl
A Julia framework for delayed expression evaluation
8Distinct people
10Mentions
0Explicit recommenders
117GitHub stars
What to know before exploring
What it is
A Julia framework for delayed expression evaluation
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year10 dated mentions
Observed mentions: 2013-02-12 17:35:22 UTC to 2016-03-12 22:53:17 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
10 sourcesJulia's for loops are comparable to C in performance, and its vectorized operations are comparable to Numpy/R, although some cases can be optimized using https://github.com/lindahua/Devectorize.jl (see the benchmarks table)
In Comparison – R vs. Python: head to head data analysisThis is a common refrain: drop down to C, C++, Fortran for the computation intensive parts. It works, but only to a degree. The inefficiencies lie in the vectorization semantics of the host language(s) that leads to extra copies and extra levels of indirection. So this dual language mode of operation typically does not approach what one could have obtained had one disposed the baggage entirely, except for I/O. Usually in the quest for better speed, that is what remains, as one moves progressively larger portions of the application in the C, C++, Fortran part of the code. A reason I like Julia is that I can largely avoid this dual language annoyance, and enjoy the succinctness of pithy vectorized expressions using https://github.com/lindahua/Devectorize.jl
In Python, Machine Learning, and Language Wars. A Highly Subjective Point of View> The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run.
Then it is not surprising at all that you do not get any speed benefit. I would expect a serious slowdown.
Idiomatic MATLAB and Numpy has lots of vectorized expressions because they are so crappy at loops. However, in vanilla Julia those vectorized expressions cannot be JIT'ed. Now if you were to write them out as explicit loops then JIT will take a stab at making things faster.
I do like the economy of words of vectorized expressions a whole lot, this is the reason why I am so excited about https://github.com/lindahua/Devectorize.jl
In Julia: A fresh approach to numerical computingDevectorize – A Julia Framework for De-vectorized Evaluation
5 points · Open discussionI had to look up Devectorize.jl: https://github.com/lindahua/Devectorize.jl
The point, I think, is not that vectorizing is slow. It's that you don't want to be myopic when you do it. Your point about time spent filling and copying vectors is independent of what Devectorize is trying to do.
Yes, when you vectorize code, you need to have a prologue and an epilogue which gets the data in the correct format for the SIMD operations. This prologue and epilogue has a cost, and if it's larger than the gain from the SIMD operations, then it's not worth vectorizing. (This can happen if, say, you only have 4 elements to vectorize.) However, we have to do this cost-analysis all the time. Figuring out when it's beneficial to vectorize code has been around as long as we've vectorized code.
Devectorize.jl is not about that problem. Rather, it's about wh
Read the rest
en you have a chain of expressions, and the operators in those expressions have implied loops. The naive thing to do is to myopically execute each one of those loops, creating and passing around temporary vectors. The Devectorize framework is given an entire expression, and is able to analyze where the implied loops are, and figures out how to express that computation in a single loop.
We can tell these two concepts are independent because the ideal situation is to first use Devectorize on an expression, and then vectorize the result!
For the record, the approach taken by Devectorize.jl is similar to the problem that expression templates (http://en.wikipedia.org/wiki/Expression_templates) in C++ try to solve. Through template trickery and operator overloading, we can put off evaluating an expression, avoiding the temporaries and unnecessary memory traversal that a naive execution implies. The Boost library uBLAS (micro Base Linear Algebra Subprograms, http://www.boost.org/doc/libs/1_55_0/libs/numeric/ublas/doc/...) uses this technique.
You might be interested in:
https://github.com/lindahua/Devectorize.jl
(not 100% general yet AFAIK, but already very useful. The code is a great read too)
In How The Rise Of The "R" Computer Language Is Bringing Open Source To ScienceI was put off when it seemed that the language doesn't support vectorization the way that Matlab does
Yea, coming from matlab it just feels so wrong to write out loops by hand. Fortunately it seems some people are working on trying to solve that here: https://github.com/lindahua/Devectorize.jl
In Julia for Numerical Computation in MIT Courses> Once the speed with Matlab-like syntax improves, I'll try again.
The @devec macro should help, meanwhile:
@devec r = a .* b + c .* d + a
... will devectorize the expression. It's not perfect, but it's definitely useful.
https://github.com/lindahua/Devectorize.jl
In Comparison of Matlab, R, and Julia for data analysis (2012)> Julia's benchmarks just turned me off. They are ignoring the "reasonable idioms" of each language, specifically focusing only on RECURSIVE and ITERATIVE algos.
I read the benchmarks as an invitation to experiment (which I am) - not as a call to language war; if it doesn't float your boat, then that's cool (but you might want to check it out again in a year or two). Your concerns are specifically addressed on the front page in the benchmark discussion (http://julialang.org):
"These benchmarks, while not comprehensive, do test compiler performance on a range of common code patterns, such as function calls, string parsing, sorting, numerical loops, random number generation, and array operations. It is important to note that these benchmark implementations are not written for absolute maximal performance (the fastest code to compute fib(20)
Read the rest
is the constant literal 6765). Rather, all of the benchmarks are written to test the performance of specific algorithms, expressed in a reasonable idiom in each language. ... The point of these benchmarks is to compare the performance of specific algorithms across language implementations, not to compare the fastest means of computing a result, which in most high-level languages relies on calling C code."
We all know C compilers make fast machine code, so it seems kind of silly to tediously write apple-oranges benchmarks in ways which will usually just end up benchmarking language X FFI anyway. Excepting BLAS stuff (as noted) pure Julia is within 2x of C, and that is really the take-home message of the benchmarks.
Here's why these small, hot-point benchmarks matter: the reasonable idiom in Julia is to rewrite slow algorithms in the same language. See this recent contribution for a great example of what is possible:
https://github.com/lindahua/Devectorize.jl
This combination of meta-programming expressiveness with speed in one language is really quite profound. Among other things, I think it will go a long way towards reducing the impedance-mismatch between "C core developers" and "end-user" communities in other technical computing environments (see NumPy,R).
Julia has a beautiful, small, and stunningly accessible language implementation in C (isolated C++ for LLVM stuff); and it is certainly pragmatic by using BLAS,FFTW, etc. where appropriate --- but the numerical core is defined in Julia itself, and - IMHO - that is a very fundamental shift for building an open-source computing environment and community.
(LuaJIT is a masterpiece and it would be cool to see it in the benchmarks, but there are many reasons why I personally have no interest in numerical work using Lua)