ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Julia the Language

Sun Sep 13, 2020 10:54 pm

This semester I've been teaching two courses using Zoom. One class covers linear algebra and the other numerical methods. Since Julia is free, easy to use, performs well and runs on Windows, Macintosh and Raspberry Pi, I've been using it in both courses. For linear algebra the book

http://vmls-book.stanford.edu/

includes a supplement with Jupyter notebooks containing exercises and examples in Julia; for the numerical methods course I have adapted a classic text myself.

I thought I would start this thread to report how Julia works on the Raspberry Pi, what tricks are needed to get the latest version running in 32-bit mode Raspberry Pi OS and how performance compares to other platforms. Note that official Julia binaries are available at

https://julialang.org/downloads/

However, no 32-bit ARM version is available. The build process is involved due to the use of LLVM as a JIT compiler back end. I have not built the final 1.5.1 stable release for 32-bit yet, but did manage to build the 1.5.1 beta release. This post describes the official AARCH64 version of Julia 1.5.1 running on the beta test of 64-bit Raspberry Pi OS.

As Julia was designed to be a better MATLAB than MATLAB, it is interesting to see how well it performs the dense matrix-matrix multiply operations.

Code: Select all

A=rand(5000,5000); @time B=A*A;
A=rand(5000,5000); @time B=A*A';
A=rand(5000,5000); @time B=A'*A;
Each test was performed three times and the best score reported for each platform. Note that this is more a test of the OpenBLAS subroutine libraries than Julia itself, but at least it provides a frame of reference from which to compare other algorithms later.

The results were

Code: Select all

System         Mode         A*A       A*A'       A'*A
Ryzen 1920X  64-bit    1.255899   0.802027   0.795202
Odroid N2    64-bit   15.947735   8.637812   8.531214
Pi 4B        64-bit   17.630756   9.378660   9.343237
Rock64       64-bit  100.638612  48.773118  48.607579 
Except for the Ryzen 1920X, all the above tests were made with the same official AARCH64 version 1.5.1 binary. Notes on the hardware are
  • Ryzen 1920X -- 12 core 24 thread Threadripper.
  • Odroid N2 -- 4GB RAM with 4 A73 and 2 A53 cores.
  • Pi 4B -- 8GB RAM with 4 Cortex A72 cores.
  • Rock64 -- 4GB RAM with 4 Cortex A53 cores.
The RAM on the Rock64 was clocked at 400 MHz rather than the 786 MHz default due to stability problems.

[moderator: please don't change the subject halfway through the thread!]
Last edited by ejolson on Sat Apr 17, 2021 9:13 pm, edited 2 times in total.

dbrion06
Posts: 476
Joined: Tue May 28, 2019 11:57 am

Re: Julia the Language

Wed Sep 16, 2020 8:32 am

Well, thanks for the links:
*Boyd & Vanderbeghe book is free, sems well written and interesting .
*

I am puzzled of why multiplying a by its transpose is twice faster than multiplying A by itself. (your figures seem reliable).

I have tried to compare with another language, R, but my figures are not that reliable (it is on a very old 32 bits PC, with cygwin enabled; AFAIK, R has no timing instructions -it must be compiled with profiling enabled, and I cannot do that on cygwin; on a RPi, it can be done and RPi have no antiviruses that plague W$ stuff). I had to use system "time (therefore, I added time to launch R, time to generate 25E6 random numbers and time to mulitiply matrixes: I bet that the bias can be neglected)

Code: Select all

sh-4.1$ cat ./ec
time echo " for (i in 1:6) {
      a=matrix(runif(5000*5000), nrow=5000,ncol=5000)
      b=a %*%a
print(i)
}
" | R --vanilla
time echo " for (i in 1:6) {
      a=matrix(runif(5000*5000), nrow=5000,ncol=5000)
     b=a %*%t(a)
print(i)
}
" | R --vanilla
time echo " for (i in 1:6) {
      a=matrix(runif(5000*5000), nrow=5000,ncol=5000)
     b=t(a) %*%a
print(i)
}


Each trial lead to an average time of 4 minutes (240 seconds) on a 10 years old 32 bits PC... (there was no difference between time to multiply matrix by itself and time to multiply matrix by its transpose)

hippy
Posts: 10187
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Julia the Language

Wed Sep 16, 2020 12:25 pm

I installed Julia back in February using "sudo apt-get install julia".

That's version 1.0.3 and definitely runs 32-bit on a Pi 3B (non-plus). I'm not sure how much has changed with progression to 1.5.1 but that's an option for those who don't need the latest, don't want the rigmarole of building from source.

It was quite sprightly when testing my simplistic recursive Fibonacci benchmark -

Code: Select all

                           Fibo(24)    Fibo(42)

C             optimised :    0.008s      5.022s
Cython            typed :    0.109s      7.844s
Rust          optimised :    0.013s      8.476s
C#                 mono :    0.168s     10.887s
Julia             1.0.3 :    1.006s     12.172s
Go               1.11.6 :    0.014s     14.746s
Swift       interpreted :    0.871s     14.749s

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Wed Sep 16, 2020 3:09 pm

dbrion06 wrote:
Wed Sep 16, 2020 8:32 am
I am puzzled of why multiplying a by its transpose is twice faster than multiplying A by itself. (your figures seem reliable).
Due to different memory access patterns (rows with rows rather than rows with columns) multiplying A'*A results in about half the cache pressure as A*A. The data locality also makes the code for A'*A easier to vectorize.

Comparing the two different times gives one an idea of the balance between CPU and RAM speed. Since my Rock64 gave segmentation faults and kernel oops when memory was clocked at the default 786 MHz speed, the above timings were made using a 400 MHz memory clock. This is likely why A*A takes more than double the time for that board. I actually have a second Rock64 single-board computer that did run with RAM at 786 MHz. However, after two weeks the second one started acting funny and now only detects 1/4 of the physical RAM at boot. That's why I used the Rock64 with the slower memory for the test.

I've updated the original post to indicate this irregularity with the Rock64 timing. If anyone has a fully functional board, it would be great to see the results when multiplying matrices with Julia 1.5.1.

At any rate, the main point of this thread, after I figure it out, is how to install the latest version of Julia on 32-bit Raspberry Pi OS. More is coming soon!

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Sat Sep 26, 2020 3:45 am

According to the page

https://julialang.org/downloads/

running on ARMv7 (32-bit) is a Tier 3 architecture. To explain
Julia wrote: Tier 3: Julia may or may not build. If it does, it is unlikely to pass tests. Binaries may be available in some cases. When they are, they should be considered experimental. Ongoing support is dependent on community efforts.
At any rate, I created the file Make.user with the contents

Code: Select all

JULIA_CPU_TARGET := cortex-a72
MCPU := cortex-a72
in the root of the Julia source distribution, managed to type make -j4 and obtained what turned out to be version 1.6.0-DEV.684.

I had been expecting 1.5.2, but never mind. Compared to the 64-bit results, the 32-bit timings were quite similar.

Code: Select all

System         Mode         A*A       A*A'       A'*A
Pi 4B        32-bit   17.518252   9.493474   9.481969
Pi 4B        64-bit   17.630756   9.378660   9.343237
Again, this test mostly measures the performance of the OpenBLAS subroutine library; however, the results seem quite promising. At least it runs!

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Sat Sep 26, 2020 5:14 am

Here is a log of an interactive session running on a 2GB Pi 4B.

Code: Select all

$ grep "model name" /proc/cpuinfo 
model name  : ARMv7 Processor rev 3 (v7l)
model name  : ARMv7 Processor rev 3 (v7l)
model name  : ARMv7 Processor rev 3 (v7l)
model name  : ARMv7 Processor rev 3 (v7l)
$ julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.6.0-DEV.684 (2020-08-21)
 _/ |\__'_|_|_|\__'_|  |  Commit 8157ac6928* (36 days old master)
|__/                   |

julia> 1+1
2

julia> A=[1,2,3]
3-element Vector{Int32}:
 1
 2
 3

julia> B=[4,5,6]
3-element Vector{Int32}:
 4
 5
 6

julia> A*B'
3×3 Matrix{Int32}:
  4   5   6
  8  10  12
 12  15  18

julia> exit()
$ 
The system seems about as responsive as the x86 desktop I've been using. I'll be checking whether the Plots package installed correctly next.

dbrion06
Posts: 476
Joined: Tue May 28, 2019 11:57 am

Re: Julia the Language

Fri Oct 02, 2020 2:15 pm

Well, thanks to your Makefile.user, julia (seems very interesting) could run on my RPi with about (I am 5% slower, maybe more tasks) the same timings.

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Sat Mar 27, 2021 4:13 am

It seems I'm not having as much luck compiling the official 1.6.0 release of Julia as the development version described above.

viewtopic.php?p=1732534#p1732534

After some time I get the message

Code: Select all

    JULIA usr/lib/julia/corecompiler.ji
Segmentation fault
in my build output. This is on an 8GB Pi so I don't think I'm running out of RAM. I've tried the same
options as above and also adding

USE_BINARYBUILDER := 0

to the Make.user file. The build always stops in the same place.

It seems 32-bit ARM is still a user-supported platform for Julia, so I'm posting here, in case anyone here has been tracking the development and knows how to build the latest release. As the 1.6.x series may be the next long-term supported version and Julia is a good language for teaching numerical computation, I'd like to get this problem resolved.

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Thu Apr 01, 2021 5:24 pm

ejolson wrote:
Sat Mar 27, 2021 4:13 am
It seems I'm not having as much luck compiling the official 1.6.0 release of Julia as the development version described above.

viewtopic.php?p=1732534#p1732534

After some time I get the message

Code: Select all

    JULIA usr/lib/julia/corecompiler.ji
Segmentation fault
in my build output. This is on an 8GB Pi so I don't think I'm running out of RAM. I've tried the same
options as above and also adding

USE_BINARYBUILDER := 0

to the Make.user file. The build always stops in the same place.

It seems 32-bit ARM is still a user-supported platform for Julia, so I'm posting here, in case anyone here has been tracking the development and knows how to build the latest release. As the 1.6.x series may be the next long-term supported version and Julia is a good language for teaching numerical computation, I'd like to get this problem resolved.
I still have no luck--even less trying to compile it as ARMv6 for the Pi Zero. Unfortunately, a web search for Julia on the Raspberry Pi seem to rank this thread as either 1 or 2, the other being the 2017 blog post

https://www.raspberrypi.org/blog/julia- ... pberry-pi/

There is also

https://juliaberry.github.io/

however, all it does is point to the download page

https://julialang.org/downloads/

which has been conspicuously missing a 32-bit ARM binary for at least a year.

My understanding is that Julia is becoming popular in machine learning and scientific computation. My experience is that it combines a Python-like interactive REPL, the speed of just-in-time compilation and simple vector notation along with linkages into a large collection of well-established subroutine libraries.

Although the interactive execution environment takes some time to warm up, once it's running it is very responsive on the Raspberry Pi. I've tried it in my teaching and it seems to work well for students who have had minimal prior programming experience without forcing them to perform every task using an external library. In particular. they can implement their own algorithms without being restricted to scripting libraries written by someone else without the trouble of coding anything in Fortran or C.

Right now 32-bit ARM is a Tier 3 unsupported platform. which means
julialang.org wrote: Julia may or may not build. If it does, it is unlikely to pass tests. Binaries may be available in some cases. When they are, they should be considered experimental. Ongoing support is dependent on community efforts.
it would appear that community involvement is necessary to get it running at all. Even better would be if the Raspberry Pi Foundation were to realize the educational benefit of Julia running well on affordable single-board computers such as the Pi and somehow sponsor the upstream development for 32-bit ARM. Since earlier development versions of 1.6.0 worked, it would seem getting the stable release working should be fairly easy.

emma1997
Posts: 1551
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: Julia the Language

Fri Apr 02, 2021 8:14 pm

Wake me up when Mandelbrot The Language catches on.

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Fri Apr 02, 2021 8:21 pm

emma1997 wrote:
Fri Apr 02, 2021 8:14 pm
Wake me up when Mandelbrot The Language catches on.
I don't understand your reply. Are you asleep?

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Fri Apr 02, 2021 8:33 pm

For those who haven't heard of Julia, here are two recent articles discussing its growing popularity.

https://www.hpcwire.com/2021/01/13/juli ... hallenger/

https://www.nextplatform.com/2021/03/22 ... s-in-2021/

Interestingly, both articles suggest that Julia may eventually replace Python in many use cases.

emma1997
Posts: 1551
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: Julia the Language

Fri Apr 02, 2021 8:44 pm

ejolson wrote:
Fri Apr 02, 2021 8:33 pm
Interestingly, both articles suggest that Julia may eventually replace Python in many use cases.
If Julia runs at even half the speed of C, skips those ridiculous indentation tricks, and avoids coming out with COMPLETELY incompatible versions every couple years then good to go.
ejolson wrote:
Fri Apr 02, 2021 8:21 pm
I don't understand your reply. Are you asleep?
Julia... Mandelbrot... get it ????

nevermind

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Sat Apr 03, 2021 12:40 am

emma1997 wrote:
Fri Apr 02, 2021 8:44 pm
Julia... Mandelbrot... get it ????
Aha! It seems I was asleep. Thanks for clearing that up!

emma1997
Posts: 1551
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: Julia the Language

Sat Apr 03, 2021 2:53 am

lol. Since it's Friday nite I assumed 'asleep' was euphemism for 'partying' or 'drinking' or 'smoking' which are not hobbies of mine either.

Thanks for the links. I'll check in more detail when I get a minute. I've always been fascinated by languages ever since ASM and BASIC days and threw together a few primitive compilers and interpreters myself since then. Unfortunately at this late date fancy-schmancy newcomers personally not candidates as serious toolsets. Although I must admit Heaters Rust-o-philia did lead me to revisit that briefly and if I had to pick a new language...

In any case, speaking of asleep, time to put the desktop to rest for another Analog Weekend.

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Julia the Language

Sat Apr 03, 2021 4:31 am

emma1997 wrote:
Sat Apr 03, 2021 2:53 am
Thanks for the links. I'll check in more detail when I get a minute. I've always been fascinated by languages ever since ASM and BASIC days and threw together a few primitive compilers and interpreters myself since then. Unfortunately at this late date fancy-schmancy newcomers personally not candidates as serious toolsets. Although I must admit Heaters Rust-o-philia did lead me to revisit that briefly and if I had to pick a new language...
Take a look at D
Its very capable, an alternative to C++ but much easier.

The compiler is called "gdc" (part of GCC). See "man gdc" for info.

It seems to be included with Raspberry Pi OS 64-bit, but you may need "sudo apt install gdc" to get it on Raspberry Pi OS 32-bit.

Heater
Posts: 18335
Joined: Tue Jul 17, 2012 3:02 pm

Re: Julia the Language

Sat Apr 03, 2021 11:24 am

emma1997 wrote:
Sat Apr 03, 2021 2:53 am
Although I must admit Heaters Rust-o-philia did lead me to revisit that briefly and if I had to pick a new language...
Ha! You just made me choke on a byte of my Dr.Oetker Rustica Pizza. I had not realises my Rust-o-philia had gone so far.
emma1997 wrote:
Sat Apr 03, 2021 2:53 am
In any case, speaking of asleep, time to put the desktop to rest for another Analog Weekend.
That sounds like a very good tradition to have.
Memory in C++ is a leaky abstraction .

Heater
Posts: 18335
Joined: Tue Jul 17, 2012 3:02 pm

Re: Julia the Language

Sat Apr 03, 2021 11:45 am

jahboater wrote:
Sat Apr 03, 2021 4:31 am
Take a look at D
It's very capable, an alternative to C++ but much easier.
It seems to be. That is certainly welcome.

I took a look. Turns out it needs a garbage collector to get anything useful done and lacks the correctness checking of Rust. A lack of community around it means very few useful libraries are available. Meanwhile it's not really a contender for the higher levels of abstraction of the likes of Python, Javascript, Julia.

Am I the only one who has had enough of programming languages? They sprout like weeds, every one some kind of mutant of what came before. After having had to learn and use a dozen different languages over the years my brain is screaming "Enough already, this is insane, what a senseless waste of human life."

A few years ago I started to listen and promised myself I would never waste a minute learning YAFL again. Since then I found myself breaking that promise and getting into Javascript and Rust, thankfully both language offering unique and sophisticated features not seen elsewhere. And hence proving worthwhile from an intellectual curiosity (fun) point of view as well as being very practically useful.

I'm done, Javascript and Rust will last me to the end of my days. With C and C++ nipping my heels along the way I'm sure.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Julia the Language

Sat Apr 03, 2021 11:57 am

Heater wrote:
Sat Apr 03, 2021 11:45 am
Turns out it needs a garbage collector to get anything useful done .
Well that's the big no-no for me.
For me, systems programming and GC are mutually excusive!

But see this convincing note:
https://dlang.org/spec/garbage.html

However:
It is not always obvious when the GC allocates memory, which in turn can trigger a collection, so the program can pause unexpectedly.
The time it takes for a collection to complete is not bounded. While in practice it is very quick, this cannot normally be guaranteed.
The time it takes for a collection to complete is not bounded. While in practice it is very quick, this cannot normally be guaranteed.
These seem unsuitable for a systems programming language.

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Julia the Language

Sat Apr 03, 2021 12:02 pm

Heater wrote:
Sat Apr 03, 2021 11:45 am
They sprout like weeds, every one some kind of mutant of what came before.
Well true, otherwise we would still be programming in binary :)
(having done that a few times, I so glad they invented assembler).

I still find the new languages interesting - from an academic point of view.
Also recent forms of older languages such as "modern" Fortran.

One day I'll find a language that's as ubiquitous, capable, fast, popular, stable, and mature, as C ....

Heater
Posts: 18335
Joined: Tue Jul 17, 2012 3:02 pm

Re: Julia the Language

Sat Apr 03, 2021 12:43 pm

jahboater wrote:
Sat Apr 03, 2021 12:02 pm
Well true, otherwise we would still be programming in binary :)
(having done that a few times, I so glad they invented assembler).
It's been down hill ever since assembler: https://www.cs.utah.edu/~elb/folklore/mel.html :)
jahboater wrote:
Sat Apr 03, 2021 12:02 pm
I still find the new languages interesting - from an academic point of view.
Also recent forms of older languages such as "modern" Fortran.
To my mind there was a huge leap of abstraction and usefulness in the jump from arranging bits or programming in hex (bin there, done that as well) to assembler.

There is then another huge leap in abstraction, intellectual interest and usefulness, in the jump from assembler to Algol.

Then there is the endless tedium of endless reincarnations of the same ideas. I draw a line between Algol, C, Pascal, C++, Ada, Coral, PL/M, even Java and BASIC. Not necessarily in that order. All the same old, same old. With perhaps slightly difference emphasis on this programming technique/style or the other. Just a waste of life learning new syntax and new libraries and new tools, just to be able to do the same old stuff the same old way yet again.

Likely I have had to use the wrong languages. For intellectual stimulation and something very different there are the likes of Lisp, Scheme, Haskell, Prolog. Languages with very different ideas about programming than the main stream.
jahboater wrote:
Sat Apr 03, 2021 12:02 pm
One day I'll find a language that's as ubiquitous, capable, fast, popular, stable, and mature, as C ....
Gotta love C. Simple, minimalist, just enough to qualify as a portable high level language. Something one man can implement a compiler, from scratch, for in a reasonable amount of time.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Julia the Language

Sat Apr 03, 2021 6:17 pm

Heater wrote:
Sat Apr 03, 2021 12:43 pm
It's been down hill ever since assembler: https://www.cs.utah.edu/~elb/folklore/mel.html :)
Love it!!!!!!
Heater wrote:
Sat Apr 03, 2021 12:43 pm
To my mind there was a huge leap of abstraction and usefulness in the jump from arranging bits or programming in hex (bin there, done that as well) to assembler.

There is then another huge leap in abstraction, intellectual interest and usefulness, in the jump from assembler to Algol.

Then there is the endless tedium of endless reincarnations of the same ideas. I draw a line between Algol, C, Pascal, C++, Ada, Coral, PL/M, even Java and BASIC. Not necessarily in that order. All the same old, same old. With perhaps slightly difference emphasis on this programming technique/style or the other. Just a waste of life learning new syntax and new libraries and new tools, just to be able to do the same old stuff the same old way yet again.
Well said. +1
Heater wrote:
Sat Apr 03, 2021 12:43 pm
Gotta love C. Simple, minimalist, just enough to qualify as a portable high level language. Something one man can implement a compiler, from scratch, for in a reasonable amount of time.
I fear a quest to find something actually better than C is doomed to failure.
That is, find a successor that has all the positive attributes of C, without compromise, and yet has valuable new features.

Which perhaps explains why C is still #1 after nearly five decades ....

Heater
Posts: 18335
Joined: Tue Jul 17, 2012 3:02 pm

Re: Julia the Language

Sat Apr 03, 2021 8:16 pm

jahboater wrote:
Sat Apr 03, 2021 6:17 pm
I fear a quest to find something actually better than C is doomed to failure.
I think we should be wary of using words like "better". At least not without qualifying what we are comparing. Else we end up comparing very different things that are not really comparable.

For example, can we say C is better than assembler? Maybe, for a given job. Certainly not for all. Still one can write assembler that the C language has no idea about. Thing is C and assembler are at different levels of abstraction. They both suit their intended abstraction level very well.

One could compare things at the same abstraction level. Debating this assembler syntax vs that assembler syntax. Or, at a higher level of abstraction, comparing C to Pascal or PL/M. Higher still we can debate the merits of Python vs Javascript vs Julia or whatever.

So, in my view, it's not about finding something better than C. It's about finding a new, different, thing at a higher level of abstraction. Preferably without losing performance or bloating code size along the way, for most of the jobs we want that new thing for.
jahboater wrote:
Sat Apr 03, 2021 6:17 pm
That is, find a successor that has all the positive attributes of C, without compromise, and yet has valuable new features.
As much as I love C, for the reasons stated above, I really would like a C like language with:

1) A proper type system.

2) A text string type.

3) Like a high level language like C relieves the programmer of a lot of book keeping busy work, like constructing loops, function calls and so on he had to do in assembler, I'd like a language that takes care of the busy work of taking care of memory allocation/deallocation.

4) The ability to add methods to objects, thus removing the need to pass struct pointers around all the time.

5) A way to extend existing objects with new methods (No not OOP).

6) A way to easily write asynchronous code. Thus removing the overheads of threads.

7) A module system.

8) No header files.

Not asking much, am I?
jahboater wrote:
Sat Apr 03, 2021 6:17 pm
Which perhaps explains why C is still #1 after nearly five decades ....
As far as I can tell it is not: https://madnight.github.io/githut/#/pul ... sts/2020/4
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Julia the Language

Sat Apr 03, 2021 10:05 pm

Heater wrote:
Sat Apr 03, 2021 8:16 pm
jahboater wrote:
Sat Apr 03, 2021 6:17 pm
I fear a quest to find something actually better than C is doomed to failure.
I think we should be wary of using words like "better". At least not without qualifying what we are comparing. Else we end up comparing very different things that are not really comparable.

For example, can we say C is better than assembler? Maybe, for a given job. Certainly not for all. Still one can write assembler that the C language has no idea about. Thing is C and assembler are at different levels of abstraction. They both suit their intended abstraction level very well.

One could compare things at the same abstraction level. Debating this assembler syntax vs that assembler syntax. Or, at a higher level of abstraction, comparing C to Pascal or PL/M. Higher still we can debate the merits of Python vs Javascript vs Julia or whatever.
Yes exactly.
Heater wrote:
Sat Apr 03, 2021 8:16 pm
So, in my view, it's not about finding something better than C. It's about finding a new, different, thing at a higher level of abstraction. Preferably without losing performance or bloating code size along the way, for most of the jobs we want that new thing for.
I saw this text somewhere on the net about abstraction:
Each level of abstraction you apply over and above assembler means added
complexity and more generic functionality to encompass all the possible use
cases. That means each thing you want to do will take more time and more
resource per call. C is (so far) the lightest practical abstraction of
assembler that we have, hence its one of the fastest high level languages.

Expanded:

All computers execute assembly. How that assembly gets written is very
important. If you write it by hand, you are only performing the operations that
you require. But assembler is really really hard to write so some smart people
started abstracting it.

C was not the first abstraction language, but C is a very fast language because
it closely maps to the groups of assembly instructions you need to perform
simple tasks. Moreover, C gives you direct access to memory and resources,
meaning you can manipulate these things yourself (thus increasing performance
by optimizing how you use the memory/resources).

As has been pointed out, while C is fast, its not very safe. So some more smart
people decided that they would abstract from C to make it easier (and safer) to
write good code. As computers have been getting exponentially faster for most
of computing history, this approach made sense. However, every layer of
abstraction (read language) over and above C more or less boils down to a C
call, or groups of C calls. *This is the really important point*. There are
very few language compilers and VMs that convert from a language directly to
assembly - they typically convert to C libraries that are then converted to
assembly (those that do compile to assembly instead of C are screaming fast
such as the LuaJIT which has hand written assembler). Some VMs have an
intermediary abstraction layer (C#, Java), but in the end, Languages very
rarely boil down to straight assembler calls. The .Net VM for instance uses
Intermediate Language which is JIT compiled to its own VM internal
instructions, which in turn execute assembler.

In order to make the C calls that you abstract safe, there needs to be checks
made to ensure proper functioning, as well as abstractions that allow for
larger groupings of common scenarios. Each safety check, each generalized
function, and every extra resource that is used during the abstraction adds
time and resources to your total execution path.

As an example in practical terms, if you can write 10 lines of C to perform a
task (and you know its safe because of the code is custom written for that
functionality) a higher level language would need say 50 lines of C (an example
only) to check if there are resource violations or to abstract something to a
level to be useful across more use cases.

So in our example, our other language would need 5 times the number of calls to
perform the same action. That wouldnt be bad if language abstraction was
simple, but its not. So if you had a function that needed to call your custom C
code 100 times, you would be executing 1000 C instructions. But because we
wrote it in other language we abstracted it to work in more cases and be safer,
we now need to execute 5000 C instructions.

But what if we abstracted our abstraction (Im looking at you Python) and made
it really generic? What if that new abstraction was done at the cost of say two
calls to our original library, plus some other stuff? Now we are looking at
some serious performance penalties. instead of 5000 lines of C, we are now at
10,000+ lines of C. Which is could be very noticeable, depending on how often
that abstraction-abstraction is called.

This is a super simplified view of the problem, but you get the point:
Abstractions can cause non-linear and even exponential increases in resources
to simplify coding for the programmers. The same thing is easily applicable to
all computer resources including memory, disk access, networking, etc.
Heater wrote:
Sat Apr 03, 2021 8:16 pm
I really would like a C like language with:

1) A proper type system.
Yes, the C typedef isn't much more than an alias! Useful in places.
Heater wrote:
Sat Apr 03, 2021 8:16 pm
2) A text string type.
You noted once before that there was little mention of "strings" in the C standard. Which is true.
But then there is a reason, for that. They are very simple, there is nothing much to say about them. The clear relationship between C strings and array's of any other type is a good thing in my book. Vast amounts of complex text handling code has been written over the years with these simple strings.
They are simply arrays of chars, with a handy literal notation, a NUL terminator, and a few simple library functions to manipulate them.
Most importantly, their access is extremely efficient, there is only one byte of space overhead, and they are conceptually simple for beginners.
Once you start messing with things like this:

typedef struct { size_t length; char text[]; } string;

it all goes horribly wrong when you think about the practicalities of it.
Heater wrote:
Sat Apr 03, 2021 8:16 pm
3) Like a high level language like C relieves the programmer of a lot of book keeping busy work, like constructing loops, function calls and so on he had to do in assembler, I'd like a language that takes care of the busy work of taking care of memory allocation/deallocation.
Smart pointers I suppose? TBH, I've never found memory allocation/deallocation to be a huge issue. Its just programming. I very rarely have bugs here. Its all very simple. But then I have been programming in C for such a long time that the care needed to avoid bugs in this area is second nature. Same with array bound checks and similar stuff. My bugs tend to be elsewhere!
Heater wrote:
Sat Apr 03, 2021 8:16 pm
Not asking much, am I?
Well this sort of list is personal and would differ from user to user.
Not sure what my list would look like.
I don't use all the features of C now, such as the C11 generics and the async stuff!

I'm a big fan of static error checking and I am pleased that modern C compilers do as good a job as any other language at advanced error detection and diagnostics. Run time checking, where object values cannot be determined by data-flow analysis or any other method, must involve run-time overhead which is a no-no in my book (I can add checks myself in sensitive places).

ejolson
Posts: 7476
Joined: Tue Mar 18, 2014 11:47 am

Re: Julia the Language

Sat Apr 03, 2021 11:01 pm

Heater wrote:
Sat Apr 03, 2021 8:16 pm
So, in my view, it's not about finding something better than C. It's about finding a new, different, thing at a higher level of abstraction. Preferably without losing performance or bloating code size along the way, for most of the jobs we want that new thing for.
The attraction of Julia is not just a higher level of abstraction, but the interactivity: Julia has a read, evaluate, print loop just like Python. This means Julia can be used as an interactive calculator and learned one line at a time through experimentation.

What it means to me--the combination of the convenience of Python with the speed of C--is not just efficient abstraction but an interactive computing environment in which not every problem has to be solved by a clever application of the right subroutine library when a simple loop will suffice.

Just as Python replaced Basic, could Julia be the successor to Python?

Return to “Other programming languages”