# Choosing a numerical programming language for economic research: Julia,

**URL:** <https://discourse.julialang.org/t/choosing-a-numerical-programming-language-for-economic-research-julia/85697>\
**Category:** Community\
**Tags:** blog, blog-post\
**Created:** [August 13, 2022, 7:37am UTC](https://discourse.julialang.org/t/choosing-a-numerical-programming-language-for-economic-research-julia/85697 "2022-08-13T07:37:53Z")\
**Posts on this page:** 1\
**Showing post:** 103

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 16, 2022, 3:40pm UTC](https://discourse.julialang.org/t/choosing-a-numerical-programming-language-for-economic-research-julia/85697/103 "2022-08-16T15:40:55Z")

</div>

Thanks for the write-up.

A.  
I noticed here, likely added after posted date(?), in case others missed that link: [Web appendix for the Python, R, Julia and Matlab language comparison in 2022 on Jon Danielsson's ModelsandRisk.org](https://modelsandrisk.org/appendix/speed_2022/)

> p.s.
> 
> It is possible to significantly speed up the calculations by taking advantage of [SIMD](https://en.wikipedia.org/wiki/Single_instruction,_multiple_data). That is easily accomplished in Julia with @turbo. We have not explored how to do the same in the other 4 languages, but are open to suggestions.
> 
> ```julia
> [code with @turbo]
> 
> ```
> 
> Using `@turbo` speeds this Julia code up 2.3 times, but that is not a fair comparison to the other languages.

So it looks like your other Julia code is 1.54x slower than C (and slower than Python+Numba), showing in the graphs, is actually not the fastest, with that Julia code 33% faster than C? I think it’s actually fair to Julia to show best case, is it really unfair to the other languages? At least if such is not available there (or much more complicated to implement)?

B.

> When using Julia, we use two versions, standard and without bonds checking, @inbounds.

You have a typo “bond”, but I would clarify further:

> When using Julia, we use two versions of the code, standard and code applying the @inbounds macro, i.e. disabling bounds-checking.

It felt like you were saying you used non-standard Julia [tools], but using `@inbound` is very much standard practice, especially in packages. Note though you can disable globally (and that’s the fair comparison to C) with:

```julia
$ julia --inline=no

```

I think actually you can fix your code to avoid bounds-checks without `@inbounds` or the global option, and maybe merging the loops back is possible (was it really, a needed, part of the speed-up trick?).

B.  
On reading compressed CSV files, and you using CSV.jl. It was the fastest package of all language (when subtracting first-use latency).

> [@\[ANN\] DLMReader 0.4.5 with one Big Enhancement](https://discourse.julialang.org/t/ann-dlmreader-0-4-5-with-one-big-enhancement/83729):
>
> I am excited to announce that DLMReader version 0.4.5 has been released. The new release includes several performance enhancements and bug fixes. For instance, reading multiple observations per line and type detecting are allocating less and performing better. However, the biggest enhancement of the 0.4.5 release is the significant reduction in the time to the first read. I have managed to reduce the package latency in Mac and Linux more than 4 times in the case of reading small files with homo…

I’m not sure which is fastest or easiest API, others to consider:

> [@\[ANN\] TableReader.jl - A fast and simple CSV parser](https://discourse.julialang.org/t/ann-tablereader-jl-a-fast-and-simple-csv-parser/22335):
>
> I’m excited to announce that my new package, [TableReader.jl](https://github.com/bicycle1885/TableReader.jl), is registered as an official package. You can now install it by add TableReader in the package management mode of REPL. As the title says, this is a new CSV parser written for Julians. The expected response is “Why yet another? We already have several packages to read CSV!”. Yes, you are absolutely right. We already have CSV.jl, CSVFiles.jl, CSVReader.jl, TextParse.jl, and more. But please give me a moment to explain the motivation of…

> **[GitHub - queryverse/CSVFiles.jl: FileIO.jl integration for CSV files](https://github.com/queryverse/CSVFiles.jl)**
>
> FileIO.jl integration for CSV files. Contribute to queryverse/CSVFiles.jl development by creating an account on GitHub.

> [@How to read a compressed CSV file?](https://discourse.julialang.org/t/how-to-read-a-compressed-csv-file/19719/4):
>
> Can’t you do myDT = open(`7z e -y -bso0 -so mycompress.7z`, "r") do io load(Stream(format"CSV", io)) |\> DataFrame end to load it from a pipe just like in R?

C.

> All four languages easily support GPU programming.

A bit surprising, I thought others not as good for GPU use, and at some point at least Python not good at all.

---

_[View the full topic](https://discourse.julialang.org/t/choosing-a-numerical-programming-language-for-economic-research-julia/85697)._