[ / / / / / / / / / / / / / ] [ dir / abdl / animu / arepa / ausneets / clang / had / leftpol / vg ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Email
Comment *
File
Select/drop/paste files here
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 8620524b3fbd927⋯.png (70.01 KB, 960x280, 24:7, JuliaBenchmarks.png) (h) (u)

[–]

 No.932434>>932435 >>932458 >>932715 >>933121 >>933151 >>933833 >>937135 >>940859 >>943908 >>959107 [Watch Thread][Show All Posts]

Why isn't /tech/ using Julia?

It seems to be a very well designed language, combining many of the best aspects of common lisp, python, and MATLAB, into the perfect high level language capable of heavy duty number crunching. It makes programming for large HPC clusters easy.

But don't take my word for it!

https://graydon2.dreamwidth.org/189377.html

http://www.stochasticlifestyle.com/like-julia-scales-productive-insights-julia-developer/

https://www.nextplatform.com/2017/11/28/julia-language-delivers-petascale-hpc-performance/

https://tpapp.github.io/post/common-lisp-to-julia/

:^)

 No.932435

>>932434 (OP)

By the way, I'm not just speaking about the language itself, but the JIT compiler design too, which is a large part of the reason it is so fast.

Of course the language is designed in tandem with the JIT, so I don't consider them separate entities.

And since it targets LLVM, I don't see any alternative implementations ever developing outside the main one.


 No.932446

The original Julia paper.


 No.932458>>932462 >>932469

>>932434 (OP)

Does it beat PyPy or Numba?

IronPython and Jython does not count.


 No.932462

>>932458

Also Pyston is for LLVM, Jython is for JVM, IronPython is for .NET


 No.932469

>>932458

I don't know. Maybe you could take their benchmark code and implement PyPy and Numba versions of the Python code?

I suspect Numba might win in some and Julia in others.

This discussion is relevant.

https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236/10

http://www.laketide.com/julia-vs-r-vs-python/

:^)


 No.932645>>933082

One it reaches 1.0, it will start to become popular.


 No.932658>>933013 >>933017

File (hide): 89972025d20582f⋯.png (29.91 KB, 630x389, 630:389, julia BTFO.png) (h) (u)


 No.932715>>934085 >>934316

>>932434 (OP)

i'm not autistic


 No.932923>>933013

>MATLAB

Wolfram is better.


 No.933013

>>932923

Wolfram is write only.

>>932658

The performance difference you are showing is negligible considering the large increase in development time and decrease in readability Rust would bring.

If Rust can something built in or on top of it that allows for formal verification of correctness, then I think it would be perfect for mission critical systems like avionics.

For pure number crunching with no real-time constraints, Julia is far superior.

Heck, the OP links to a blog by the creator of Rust (first link) where he states clearly that Julia is a great goldilocks language with tons of promise.

If he thought it was useless because of Rust (his creation), then I'm sure he would have said so.

Long story short, kys.

:^)


 No.933017>>934085

>>932658

holy shit that font is unbelievable


 No.933082

>>932645

No it won't. Python or bust


 No.933104>>933107

I think Python is fundamentally too dynamic to do what Julia does without losing correctness. Its strength is in its fast libraries. You can get faster than CPython, but there are limits.

My experience is mainly with CPython and scipy, though, not with other Python implementations and Julia.


 No.933107>>933125 >>933147 >>934085

>>933104

Anaconda, the company that made the Conda containers (and the one who helped maintained the SciPy libraries and Jupyter notebook), has an incentive to make Python out perform Julia at all cost, as to not loose users. Anaconda is R-friendly BUT they are competing with Julia


 No.933121>>933125 >>933463 >>934085 >>934699

>>932434 (OP)

I tried Julia once and the startup times due to the JIT were really really bad. Is the intended use case of this language for large calculations you start and let run for a long time? Because quick scripting does not appear to be the language's strong suit.


 No.933125

>>933107

Lots of people have incentives. This job can't be done, and moreover it can't be done well. Read the stochasticstyle.com link in the OP.

and python is just a terrible, awful language. don't keep using just because you wasted some time on it.

>>933121

this + the focus on number crunching + popularity are why I don't use Julia. I like that it's run from source (critical for sysadmin stuff) but I can't justify installing it or even running it on servers. I like that efficiency is possible but I don't do much that's actually focused on numbers. Even a statistical work (in-depth metrics for managers) was mostly webdev... and it relied on fast start-up times because I could use CGI. And all my free 'meme language' points are allocated elsewhere.


 No.933147

>>933107

Well-written SciPy code is barely affected by the performance of the Python interpreter.


 No.933151>>933159 >>933174 >>933178

>>932434 (OP)

Benchmarks that show a language beating C by large margins are a huge red flag that it's propaganda.

- these benchmarks come from the Julia authors themselves.

- they're testing the most recent version of their shit vs an ancient version of GCC. Julia 0.6.x came out Jun 2017. GCC 4.8.x came out March 2013.

- they're not actually testing performance of optimized hot loops, instead it tests performance of subjective 'pretty' code by the Julia dev's standard:

>It is important to note that the benchmark codes are not written for absolute maximal performance (the fastest code to compute recursion_fibonacci(20) is the constant literal 6765). Instead, the benchmarks are written to test the performance of identical algorithms and code patterns implemented in each language.

- subjective 'pretty' code by the Julia devs' standard isn't like you'd actually write in C. For example, this is part of the "matrix_statistics" test above where they're writing C code like you would if it were garbage collected and allocations were cheap:


struct double_pair randmatstat(int t) {
dsfmt_t dsfmt;
dsfmt_init_gen_rand(&dsfmt, 1234);

int n = 5;
struct double_pair r;
double *v = (double*)calloc(t,sizeof(double));
double *w = (double*)calloc(t,sizeof(double));
double *a = (double*)malloc((n)*(n)*sizeof(double));
double *b = (double*)malloc((n)*(n)*sizeof(double));
double *c = (double*)malloc((n)*(n)*sizeof(double));
double *d = (double*)malloc((n)*(n)*sizeof(double));
double *P = (double*)malloc((n)*(4*n)*sizeof(double));
double *Q = (double*)malloc((2*n)*(2*n)*sizeof(double));
double *PtP1 = (double*)malloc((4*n)*(4*n)*sizeof(double));
double *PtP2 = (double*)malloc((4*n)*(4*n)*sizeof(double));
double *QtQ1 = (double*)malloc((2*n)*(2*n)*sizeof(double));
double *QtQ2 = (double*)malloc((2*n)*(2*n)*sizeof(double));
(cont.)

- the C code benchmarks free() per iteration but the Julia code's benchmarks don't include garbage collection.

As expected, the benchmarks are bullshit. Here's the source if you're curious:

https://github.com/JuliaLang/Microbenchmarks


 No.933159>>933160

>>933151

Looks like we should redo all tests with state of the art C, Python, JS and Go.


 No.933160>>933163

>>933159

>JS and Go

why?


 No.933163>>933164 >>933416


 No.933164

>>933163

>memeshit

Why?


 No.933174

>>933151

>the fastest code to compute recursion_fibonacci(20) is the constant literal 6765

lmfao


 No.933178>>933179 >>933183 >>933416

>>933151

>they're writing C code like you would if it were garbage collected

but they're not though, since they're

>free() per iteration

that's more like comparing code using linear types to control memory vs. GC.

>the benchmarks are bullshit

1. use some alternate allocators and show how that affects timings

2. add idiomatic_randmatstat()


 No.933179>>933183

>>933178

>julia defense force


 No.933183

>>933179

>>933178

>>julia defense force

It's JIDF, Julia Internet Defense Force!


 No.933416>>933423 >>933424

>>933163

Go is not very good language and there are better alternatives.

https://github.com/ksimka/go-is-not-good

>>933178

>but they're not though, since they're

what did S/he mean by this?


 No.933423

>>933416

>Go is not very good language

That's quite the understatement tbh. Go was literally made for retards.

>The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

>It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.


 No.933424>>933534


 No.933452

Why don't you just use assembly? lol


 No.933463

File (hide): 679425966a74d7f⋯.png (178.18 KB, 629x736, 629:736, mechajyo_mini.png) (h) (u)

>>933121

https://stackoverflow.com/questions/10268028/julia-compiles-the-script-every-time/10711762#10711762

>Most of Julia is written in itself, then parsed, type-inferred and jitted, so bootstrapping the entire system from scratch takes some 15-20 seconds. To make it faster, we have a staged system where we parse, type-infer, and then cache a serialized version of the type-inferred AST in the file sys.ji. This file is then loaded and used to run the system when you run julia. No LLVM code or machine code is cached in sys.ji, however, so all the LLVM jitting still needs to be done every time julia starts up, which therefore takes about 2 seconds.

>This 2-second startup delay is quite annoying and we have a plan for fixing it. The basic plan is to be able to compile whole Julia programs to binaries: either executables that can be run or .so/.dylib shared libraries that can be called from other programs as though they were simply shared C libraries. The startup time for a binary will be like any other C program, so the 2-second startup delay will vanish

IMO you are all too critical. Julia hasn't even had its 1.0 release and you are comparing it to mature languages like Python that have had 27 years to polish themselves and gain users/libraries etc...


 No.933534>>933589 >>934433

>>933424

>Stallman is an SJW

Welp.


 No.933589>>933609

>>933534

That's not that SJWy, as Stallman goes.

Do you know anything at all about the guy?


 No.933609>>933650 >>933665

>>933589

Yes, he is GNU/fucked, and he like birds and hates babies. He is also an autist.


 No.933650>>933656

>>933609

>implying


 No.933656

>>933650

What is perse implying?


 No.933665

>>933609

You forgot that he's also Jewish.


 No.933833

>>932434 (OP)

I'm actually impressed by LuaJIT. Faster than Go and Java. I'm surprised people aren't writing full desktop applications and webservers in it.


 No.934085

>>932715

Don't lie.

>>933017

I don't think it's that great.

>>933107

Way to miss the point, there are fundamental limits to how fast python can get due to its dynamic nature.

Using numpy and scipy or cython becomes like writing in a different language, it becomes verbose and doesn't look like standard python.

And the interpreter is still there between the byte code and machine code.

Julia is going to allow saving JIT'd code as .so files in the future if someone needs quick startup, like this guy >>933121


 No.934316

>>932715

>>>/out/ is that way then


 No.934433

>>933534

>There are those who claim that we have an obligation to refer to someone using whatever pronouns person might choose. I disagree with that position, on grounds of principle and grounds of practice. I think we should respect other people's gender identification, but which pronouns we use for any particular gender identification is a separate matter --- a matter of grammar. We do not owe it to anyone to change our grammar according to per wishes.

He's a faggot alright, but definitely not an SJW faggot.


 No.934699>>952470

>>933121

>this + the focus on number crunching + popularity are why I don't use Julia

Julia is a general purpose language. The initial focus on number crunching because they wanted to have an initial user base who are interested in serious HPC type stuff, since that domain currently doesn't have any good high level language solutions.

If the initial user base was web developers, well, I'm pretty sure we all know it would have become a monstrosity in design. The native number crunching semantics (basically MATLAB semantics) are actually going to become a library IIRC for 1.0

All that said, it can be used for web development. e.g. https://github.com/essenciary/Genie.jl

Because it is a general purpose language.


 No.934767>>935465 >>937241

>Metaprogramming

> The strongest legacy of Lisp in the Julia language is its metaprogramming support. Like Lisp, Julia represents its own code as a data structure of the language itself. Since code is represented by objects that can be created and manipulated from within the language, it is possible for a program to transform and generate its own code. This allows sophisticated code generation without extra build steps, and also allows true Lisp-style macros operating at the level of abstract syntax trees. In contrast, preprocessor "macro" systems, like that of C and C++, perform textual manipulation and substitution before any actual parsing or interpretation occurs. Because all data types and code in Julia are represented by Julia data structures, powerful reflection capabilities are available to explore the internals of a program and its types just like any other data.

That's good. Nim and Rust have similar capabilities, far more sophisticated than the C/C++ preprocessor.


 No.935465

>>934767

Rust is probably too low level, but I wonder if Nim will end up being a major competitor to Julia?


 No.937135

>>932434 (OP)

They were only slightly influenced by lisp, which is a good thing.


 No.937241>>959394

>>934767

Metaprogramming is pure cancer and the part of a C++ project most likely to go malignant and kill it.


 No.940859

>>932434 (OP)

Okay, I just started using Julia the other day and it's great. Easily my new favorite language!


 No.943908

>>932434 (OP)

>Why isn't /tech/ using Julia?

Because if you want to be a hipster and use a modern programming language that nobody else uses like Julia, Nim is a billion times better.


 No.943921

functional programming with imperative datastructures is a pretty sick feature performance wise, but dynamic typeing is pretty lame from a safety perspective. Also because memory management is so hidden from the programmer is make optimising for cache line length to avoid cache misses and timing allocations deallocations / garbage collection impossible if those are things which are important to you, and they ought to be if you're concerned with performance because cache misses are real hogs. Multiple dispatch and overloading are horrible features to have in your object model if you're interesting in optimising anything at all because they obfuscate what your program is actually doing where and the less clear you make what your program is doing the more impossible it becomes to optimise.

All in all Julia is great for non-programmers who don't know how to optimise code to right moderately efficient throw-away code in environments where safety isn't a priority, which is exactly what it's design for, but that's not my use case.


 No.952458>>952465

"metaprogramming" is almost exclusively used to mend the flaws of the programming language.

Prove me wrong.


 No.952465

>>952458

sure.

and the most important flaw of a programming language is "it has no way to do this new amazing thing that we didn't even know was a good idea when the language was designed"


 No.952470>>959112

>>934699

Julia doesn't even have buffered I/O, which is why people are on their gitter asking "why is this Python hello-world loop 500x faster than this identical Julia loop", and are getting answers like "oh that depends on the terminal. why do you want to do that anyway?".

The optimizations required are completely trivial, and wouldn't compromise Julia's focus, but Julia doesn't have them. So if you want to use your 'general purpose' language to write a simple unix filter, to turn 300G of logs into 30G of time-series data or something a number cruncher *could not even imagine wanting to do*, then the best way to start is to hack on Julia itself.


 No.959107>>959123 >>959647

>>932434 (OP)

Most people on /tech/ aren't anywhere close to HPC or mathematical computing. And if they were, all the docs are in Python, MATLAB, or R, even if there are bindings into Julia. It's just "why bother?".


 No.959112

>>952470

Buffered I/O exists to cover for shitty programming. It's not necessary.


 No.959123

>>959107

>Most people on /tech/ aren't anywhere close to HPC or mathematical computing. And if they were, all the docs are in Python, MATLAB, or R

This. When I was in college we did everything in Matlab. Most papers I read were in Matlab or python. I didn't see any R, but my understanding is that R is better suited for statistical.analysis of large datasets, which wasn't really what I was doing. My datasets were fairly large though.


 No.959394

>>937241

I don't think Julia metaprogramming is very similar to C++ metaprogramming.


 No.959424

I like lisp syntax.


 No.959647

>>959107

Julia has hit 1.0 now, so code written now should work on future versions.

Python is finished!




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
58 replies | 4 images | Page ?
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / abdl / animu / arepa / ausneets / clang / had / leftpol / vg ][ watchlist ]