On Monday, October 19, 2015 at 5:06:45 PM UTC+2, Tamas Papp wrote:
>
> On Mon, Oct 19 2015, Steven G. Johnson <steve...@gmail.com <javascript:>>
> wrote:
>
> > On Sunday, October 18, 2015 at 10:01:20 AM UTC-4, Stefan Karpinski
> wrote:
> >>
> >> There are different styles and levels of writing code in every
> language.
> >> There's highly abstract C++ and there's low-level pointer-chasing C++
> >> that's basically C. Even in C there's the void*-style of programming
> which
> >> is effectively dynamically typed without the safety. Given this fact,
> I'm
> >> not sure what solving the two language problem would look like from the
> >> perspective this post is posing. Enforcing only one style of
> programming
> >> sounds like a problem to me, not a solution. On the contrary, I think
> one
> >> of Julia's greatest strengths is its ability to accommodate a very
> broad
> >> range of programming styles and levels.
> >>
> >
> > Even forgetting about pointers etc, the fact is that highly optimized
> code
> > often looks very different from unoptimized code in any language. e.g.
> > the simplest way to implement a matrix multiplication in C is three
> loops.
> > Getting decent performance (compared to peak flops) requires 100+
> lines
> > of code. Super-optimized implementations require tens of thousands of
> > lines of code. This has nothing to do with safety and pointers, and
> > everything to do with locality (for caches) and unrolling (for
> registers).
> >
> > There is no language in which optimization doesn't typically involve
> > rewriting critical code.
>
> Still, in a nice language the programming effort vs speed curve should
> not be too steep. Eg you can get 80% of the speed with 20% of the
> effort, both compared to the absolute super fastest solution.
>
> Julia is a nice language: with a few simple rules that one pick ups up
> after a bit of experience (= mistakes) [1], it does not take a whole lot
> of extra effort to write reasonably fast code. Getting within a factor
> of 2-5 of C with significantly less effort is enough for a lot of
> applications, especially considering that in scientific computing a lot
> of code is only used a few times (analyze a problem, estimate a model,
> etc). For the rest, one can optimize further.
>
> The "two language problem" is really about a discontinuity in the effort
> vs speed curve. You hit the limits of Language A, you have to go to
> Language B, which is significantly different. In Julia you can make a
> lot of incremental optimizations.
>
> I define Language C := Union{A,B}. Then it solves the two language problem.
> Best,
>
> Tamas
>
> [1] http://docs.julialang.org/en/release-0.4/manual/performance-tips/
>
