# Fantastic progress in master branch!
**URL:** https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868
**Category:** Internals & Design
**Created:** [November 3, 2017, 8:39pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868 "2017-11-03T20:39:36Z")
**Posts on this page:** 18
**Page:** 2
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [November 6, 2017, 4:24pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/21 "2017-11-06T16:24:09Z")
> [@John\_Gibson](#):
>
> 3.448 JavaScript
It blows my mind that JavaScript is this fast. Can you imagine the amount of time and money that must have gone into this number? And all that effort for such a horrible, [horrible](https://eamodeorubio.github.io/thejshorrorshow/#/) language.
I’m very excited about constant propagation. Any comments on the effect this might have on compile times?
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [November 7, 2017, 2:46pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/22 "2017-11-07T14:46:14Z")
> [@ExpandingMan](#):
>
> I’m very excited about constant propagation. Any comments on the effect this might have on compile times?
Compile times are already a problem that we need to address more generally. The way forward to better compile times is to implement several larger solutions, including the following:
1. Interpreting more code rather than compiling everything;
2. More thorough pre-compilation and caching of generated code at various levels;
3. Better specialization heuristics so that we can more often compile a single generic version of code when specialization isn’t necessary.
All these improvements should more than compensate for spending a little more time on compilation when it can really improve performance. Fortunately, the nice thing about optimizations is that they don’t (by definition) change the behavior of the code, so they can happen at any time.
---
### Author:  [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)
#### Post date: [November 8, 2017, 10:08am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/23 "2017-11-08T10:08:41Z")
There is a plaform without perl ? what is the world coming to.
---
### Author:  [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)
#### Post date: [November 8, 2017, 10:11am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/24 "2017-11-08T10:11:46Z")
Those are fightin’ words around these parts 😉
---
### Author:  [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)
#### Post date: [November 8, 2017, 10:49am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/25 "2017-11-08T10:49:57Z")
Me too. I am doing data science/analytics after 8 years of theoretical/computational physics (I have a bunch of papers in the pipeline, hope I can get them out [!]) I use Julia. But, I am learning and using python for some things now because: I have to work with other people; we are pretty sure what the python API and ecosystem will look like in two years, etc. (The depth and breadth of python is great. But, immediately I am sorely missing the ability to “talk about types” at the core of the language.)
Exact diagonalizations of QM models like @mason is doing are a bread-and-butter task for which Julia is well suited. In fact, for a very large number of physical science projects, the code is shared by one or a few people. And its lifetime is measured in months. Or maybe a couple of years. And there is usually no PHB vetoing your language choice. This makes physical science a great vector for Julia. In the past two years I did get one new postdoc to try Julia for a project. I offered basically unlimited support. I don’t think it was language partisanship that prevented uptake, rather perceived practicality. I gave a Julia talk a the Barcelona supercomputer center too. There is obviously a great interest. The room was full, which doesn’t happen often; I hope someone gave it a try. My contacts there have not had time to try it for anything yet, but have a genuine interest. My guess is that language adoption has some features of dynamic growth of a scale-free structure. There won’t be a critical-mass event, but adoption will still be in a sense fast.
---
### Author:  [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)
#### Post date: [November 8, 2017, 11:05am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/26 "2017-11-08T11:05:53Z")
A possible reason is in [this post](http://blog.kevmod.com/2017/02/personal-thoughts-about-pystons-outcome/). The author claims that being dynamic doesn’t, in itself, make a language hard to optimize. Python is more difficult to make fast than java script, because python has a “rich object model”. Python developers implemented a lot of cool features that were relativley easy to do in an interpreted language. But they were not thinking about the implications for building an optimizing compiler in the future.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [November 8, 2017, 11:27am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/27 "2017-11-08T11:27:29Z")
Another possible reason is that the JavaScript JIT compilers are very, very good at this stage, as a lot of effort (and money) went into them, and they really shine where
1. the “same” calculation is performed repeatedly,
2. and this “sameness” is cheap to check by the JIT.
Julia was designed to allow the compiler to reason about 2 (among other things).
An implied criticism of microbenchmarks with JS-style JIT compilers is that a small number of repeatedly executed hot code paths are not very informative about language performance for more complex code.
---
### Author:  [@vchuravy](https://discourse.julialang.org/u/vchuravy)
#### Post date: [November 14, 2017, 5:55pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/28 "2017-11-14T17:55:10Z")
20 posts were split to a new topic: [Adding VB to benchmark comparison](https://discourse.julialang.org/t/adding-vb-to-benchmark-comparison/7074)
---
### Author:  [@111](https://discourse.julialang.org/u/111)
#### Post date: [November 22, 2017, 12:28pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/29 "2017-11-22T12:28:33Z")
In my situation, my code is 1.3x faster when I switch from v0.6 to v0.7. however, the “Task Manager” of manjaro showed that the new version cost more memory. That is confusing.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [November 22, 2017, 12:54pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/30 "2017-11-22T12:54:32Z")
Speed versus memory is a standard tradeoff in computer science. In this case, the Julia compiler is probably specializing your code more aggressively, which means that more code is generated but that code runs faster.
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [November 22, 2017, 1:54pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/31 "2017-11-22T13:54:13Z")
Some benchmarks about a new inlining algorithm were posted [here](https://github.com/JuliaLang/julia/pull/22210#issuecomment-309297146) in graphical format. The new algorithm is again one of those optimizations that can both improve performance and cost more in terms of compile time. This is a difficult tradeoff, but as @StefanKarpinski points out there are several paths forward.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [November 22, 2017, 3:27pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/32 "2017-11-22T15:27:30Z")
But if we can AOT some package code then a large chunk of compile time is cutoff for most users, so that is a nice tradeoff.
---
### Author:  [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)
#### Post date: [November 22, 2017, 3:38pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/33 "2017-11-22T15:38:56Z")
> But if we can AOT some package code then a large chunk of compile time is cutoff for most users, so that is a nice tradeoff.
But we don’t have that currently. And compile time is currently a major issue for real life software. I have a GUI that starts up in 3 minutes and pressing certain buttons the first time freezes the system for more than 20 seconds. Don’t want to blame anything here but just make clear that compile time is a real issue currently. AOT of packages is a long term project that will certainly not be usable before 1.0. I hope that I will be proven wrong.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [November 23, 2017, 1:10am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/34 "2017-11-23T01:10:36Z")
Compile time is a top priority after getting 1.0 out, which we’ve hopefully made abundantly clear at this point – it seems like it gets brought up about once a week.
---
### Author:  [@pablosanjose](https://discourse.julialang.org/u/pablosanjose)
#### Post date: [December 3, 2017, 7:08pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/35 "2017-12-03T19:08:56Z")
It seems the IPO constant propagation PR ([https://github.com/JuliaLang/julia/pull/24362](https://github.com/JuliaLang/julia/pull/24362)) is about to drop (although only partially enabled for the moment, pending future optimisations). The nanosoldier benchmarks seem really good in mosts tests, but I am often puzzled to see apparent regressions in some others. So please, educate me: in this particular nanosoldier run for the #24362 PR ([https://github.com/JuliaCI/BaseBenchmarkReports/blob/25ad2f659d82ca7f65fe912ab9149d4e41c2aa4d/3c40a45\_vs\_eace3e9/report.md](https://github.com/JuliaCI/BaseBenchmarkReports/blob/25ad2f659d82ca7f65fe912ab9149d4e41c2aa4d/3c40a45_vs_eace3e9/report.md)), should I understand that apparent regressions in things like e.g. sparse - dense multiplications are actually real, or are they noise? How can one tell?
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [December 4, 2017, 5:12pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/36 "2017-12-04T17:12:15Z")
There’s something funny going on with nanosoldier (our benchmarking infrastructure) that’s causing more noise than usual and we haven’t gotten to the bottom of it yet. So unfortunately, the answer is “it’s hard to tell”. Fortunately, we have a lot of people working on core Julia who are pretty meticulous about performance testing on their own and nanosoldier is mostly just an additional safety net for catching unexpected regressions.
---
### Author:  [@pablosanjose](https://discourse.julialang.org/u/pablosanjose)
#### Post date: [December 5, 2017, 7:08am UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/37 "2017-12-05T07:08:55Z")
Right! Actually, the last run you launched yesterday came out quite different.
[https://github.com/JuliaCI/BaseBenchmarkReports/blob/c1a853ca11520522bafa859ebe7e82a612de4098/766e64c\_vs\_b8ee561/report.md](https://github.com/JuliaCI/BaseBenchmarkReports/blob/c1a853ca11520522bafa859ebe7e82a612de4098/766e64c_vs_b8ee561/report.md)
Spectacular…
---
### Author:  [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)
#### Post date: [June 20, 2018, 8:33pm UTC](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/38 "2018-06-20T20:33:31Z")
> [@pablosanjose](#):
>
> @Mason, this thread is pretty cool
>
> [Benchmark for latest julia? - #53 by John\_Gibson](https://discourse.julialang.org/t/benchmark-for-latest-julia/5991/53)
>
> It has updated the benchmarks of Julia against other languages. The big surprise for me, and some other people, has been SciLua, which apparently has a really sophisticated JIT compiler… It appears to be about as fast as Julia at the moment… without Julia scratching the surface 😃
I wonder, how does it compare to the current 0.7?
[Previous page](https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868.md?page=1)