Hi, I find Julia great, but for the technical computing goal, my biggest grime with Julia (0.3.3 and 0.4.0-dev) at the moment is the lack of simple OpenMP-style parallelism. There is DArray and pmap, but they have large communication overheads for shared-memory parallelism, and also, quite frankly, an unintuitive parallelism model and lack of documentation.
I often have code of the OpenMP-style type: <lots of read-only-variables and large-memory-footprint parameters defined here> <define output to be an array of size N> for i=1:N <do something with read-only data related to i, write output to i'th element in output> # (i.e. all memory-writes are disjoint) end Doing this cheaply on a multicore shared-memory machine is currently difficult in Julia (on Windows at least), so I only use one out of my 12 cores. With C++ I have to add one line of "#pragma omp parallel for schedule(dynamic)" to use 12 out of 12 cores. Sebastian On Thursday, 4 December 2014 19:38:20 UTC, Stefan Karpinski wrote: > > Wow, that's a pretty interesting graph – I'd like to start using something > like that in presentations. Of course, it's bound to be contentious because > no one has really spent any effort on making the benchmark codes terser. In > fact, I was pretty cut-and-paste happy with the initial versions in other > languages because I just wanted to bang out something that worked in each > language, rather than take lots of time to figure out the most elegant way > to time things, for example. > > On Thu, Dec 4, 2014 at 2:25 PM, Simon Danisch <[email protected] > <javascript:>> wrote: > >> Hi, >> Recently I made a graphic, plotting code length vs speed from the Julia >> benchmarks and I was surprised how strongly it favors Julia: >> <https://lh3.googleusercontent.com/-7IPcrjXuxFY/VICwQ3TrgRI/AAAAAAAAJV0/_HmDWZiBrXQ/s1600/benchmarks.png> >> >> <https://lh3.googleusercontent.com/-7IPcrjXuxFY/VICwQ3TrgRI/AAAAAAAAJV0/_HmDWZiBrXQ/s1600/benchmarks.png> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> (I removed comments, newlines an normalized the length. For the speed I >> simply took the average of the benchmarks. Fortran has some weirdly high >> values in the csv on JuliaLang though.) >> >> Well using code length as a metric is a difficult issue, but I was happy >> about the nice, empty area around Julia ;) >> This could be strongly biased though, maybe someone with more knowledge >> about the benchmarks can immediately point out, that Julia is simply the >> most polished one. >> >> >> Am Donnerstag, 4. Dezember 2014 19:12:24 UTC+1 schrieb Páll Haraldsson: >> >>> >>> Hi, >>> >>> This is my first post here and since I've gotten your attention, my >>> answer: Julia is (or seems to be) good at "everything".[*] But I'm just not >>> sure.. [You could stop reading here.] >>> >>> I think Julia could be the last language people need to learn (and >>> should be the first).[*] Maybe I'm being incredibly naive thinking no >>> *better* language will come along and I need to qualify that[*] but it >>> seems people here, when saying the Wired article has it wrong (e.g. >>> Bezanson), are being modest (or know better than I do). Maybe I just do not >>> have enough perspective on languages/paradigms out there. I'm probably >>> ignorant on (new) language/paradigm research.. >>> >>> Is Julia ready for prime time (0.3.3 considered stable)? I see some talk >>> of breaking changes ("Array nirvana" and "staged functions" (for C++) will >>> they break anything?). I already recommend Julia for technical computing >>> (quant/financial) at least (to learn/try); there may be issues (especially >>> for those doing non-technical) - for now. That seems to be changing fast. >>> >>> I would be preaching to the choir saying Julia is great for its target >>> audience. But why do you just want to unify all of technical computing in >>> one language and not all of computing? "A fresh approach to technical >>> computing" might stop other people from considering Julia. I guess it's >>> good to have a niche but I hope other people do not get scared away. >>> >>> What is needed is to support all the important platforms so that people >>> will not overlook Julia as "it doesn't support my work or run on my >>> platform". This means the web (JavaScript as an "assembly language" >>> target), Android (and iOS..). >>> >>> >>> At least Bezanson seems to like (love?) Scheme ("femtolisp"). I wander >>> if Scheme/Lisp (or any language) is *clearly* better than Julia for >>> anything? Or would he stop using Scheme except to maintain Julia's core.. >>> [Maybe femtolisp should be removed from Julia (e.g. to bootstrap Julia)..] >>> >>> While functional style is getting more popular, people seem to like >>> imperative and Julia isn't either or. Can/should !-functions be enforced? >>> It is only a recommendation? >>> >>> I know Lisp-syntax is "simple". Maybe non-infix notation is "better" in >>> a language but only for the interpreter it seems; or in regular math, had >>> it been used first/what people are used to. I and most people just don't >>> see it. I wander if there is anything to this other than preference. The >>> S-expressions that come with Lisp and infix, do they have an inherent >>> advantage that Julia can't match? In other words, I think that means, are >>> Julia's "Lisp-like" macros and its homoiconicity as powerful as Lisp's? >>> >>> As for the (linked) lists (L in Lisp), of course we need lists (and >>> trees) sometimes and Julia has them, but as a basic data structure of a >>> language, seems to me to be a performance killer. I do not see caches >>> (locality of reference) going away any time soon.. >>> >>> >>> As all (Turing-complete) languages are equivalent in a sense, one can't >>> be more "powerful" than another; "C can implement Lisp", but without that >>> exception ("Greenspunning"), programming a new runtime, languages with real >>> macros can be more powerful. I used to associate macros with Lisp, are >>> there (m)any other "ALGOL-like"/non-S-expression/not-list-based >>> languages with real macros? Is Julia a first? I understand macros are the >>> key to Lisp's power and Lisp is said to be the most powerful language. >>> >>> >>> In short is there any area where another language (which one and for >>> what) would be (*clearly*) better (not just slightly, see my metric below)? >>> Maybe I'm not asking the right people.. I can assume people here have >>> language theory covered (the basic three (more?) categories including logic >>> programming/Prolog) that I know (and, I guess, a deeper understanding than >>> I do). >>> >>> >>> If course which language (syntax) is best, is partly a value judgment; >>> maybe somewhat a personal taste and objectively there may be no best >>> language. >>> >>> >>> People focus much on the speed of Julia. My metric is not (just) the >>> speed. I see basically just that dimension (parallel is part of that) and >>> then readability as important. And that means how short the programs can be >>> (without getting cryptic). I could maybe go with programming fault rates as >>> a third or safety/fault-tolerance (see Erlang or hard real-time) as some >>> third/fourth metric but fault rate is stated as being (roughly) independent >>> of lines of code. So let's just stick with how short you can make code >>> (while keeping readability) as a metric. Is there a reason Lisp or Prolog >>> (or Haskell or other language I know less about) should win that metric (by >>> a non-trivial/low constant amount at least)? Are there likely to be (m)any >>> as good available or better ones available in the future? While also being >>> good on the speed metric? I would really like to know because I really know >>> of no other language. Any candidates that are even about as good? OCaml and >>> Racket come to mind, just not sure they can compete and win. >>> >>> >>> Readability is maybe subjective and Perl and Haskell are not, at least >>> to me.. Julia is, but maybe it's just my upbringing in imperative.. >>> >>> >>> >>> * Caveats/possible doubts for some >>> >>> What I mean by "best language" is judging it on the language merits not >>> based on any particular missing library for some specific use. [However, I >>> would like to know where they need improving, especially for "non-technical >>> use", to see how "practically best" Julia is and possibly improve the >>> situation.] Imagine if other languages did not have a headstart. Given the >>> library headstart, I also think Julia would be best since you can use >>> (almost) any library you are likely to need right now. Are there important >>> libraries/languages that can't be supported right now or theoretically. And >>> how mature is the support for R, MATLAB (does it include Octave support?), >>> Java and C++? >>> >>> You can call Java, meaning the JVM. Would it be impossible reuse Java >>> code without the JVM or the other way to compile Julia (a executable or the >>> whole environment) to Java (or CLR)? Is a C2Java available/possible? As >>> Julia2C (and f2c) is available and assuming C2Java, couldn't Julia run in >>> the JVM? Or in JavaScript (see Emscripten C2JavaScript compiler). >>> >>> Yes, you can't call all languages. It seems though, all that matter, >>> except maybe Objective-C/Swift, C#, COBOL? and few others; which ones are >>> not callable right now? Is CLR support in general possible or important? >>> >>> >>> Parallel >>> >>> In the long run, supporting parallel and resulting speed seems to be >>> what would make or break new languages and I just do not know what language >>> could be best at parallel. Any theoretical reason to suspect another >>> language than Julia? Auto-parallel would be nice; any reason another >>> language could do better with auto-parallel than Julia? That is, did the >>> developers shoot themselves in the foot, not doing pure functional (or lazy >>> vs. eager)? Microsoft made some "breakthrough" recently so imperative >>> languages are not (much?) worse off than pure functional. Anyone know more >>> about this? >>> >>> I assume Julia has, at least non-parallel, speed covered. If not (for >>> now) I assume it could at least never get slower than C than by some low >>> constant factor (if not, it can call C anyway so not a big problem). I just >>> trust the developers when they say that they can close the gap with C. And >>> I assume C (for non-parallel) using restrict keyword can't really be beat >>> by much speed-wise in any language. Assembly included. [Still, will Julia >>> support assembly directly (or does already?) in any way? Could it be done >>> in some way that is still portable (translated for other CPUs?).] >>> >>> >>> Garbage collection >>> >>> Is a plus for almost all programmers and while some disagree even that >>> seems not a good objection to Julia as best for everything (eventually). GC >>> can be disabled (possibly helping with real-time functionality in the short >>> term) or by calling C. Java has hard-real-time GC (even concurrent). I >>> assume Julia could to (an implementation issue and not a "language" one) >>> use all the GC algorithms Java can. I assume multi-dimensional arrays will >>> not be an issue (seem to recall some array issues with Java's GC that were >>> overcome). >>> >>> For game programming, would it be a good strategy to disable GC and run >>> GC manually at every vblank? Would beat C/C++ with malloc/free? >>> >>> >>> Game programming >>> >>> I mentioned games and a friend replied, "you wouldn't use Julia", au >>> contraire?! At least 3D games are about the only heavy users of computer >>> power (and often physics heavy) I can think of for ordinary users. Would >>> any other language (C++) be clearly better/faster? See next for event >>> driven: >>> >>> >>> GUI programming >>> >>> GTK (does it also work (well) for Windows/Mac with Julia?). With C++ >>> recently covered Qt should work (perfectly eventually?). Would any other >>> language be clearly better for GUI work with Qt (or otherwise)? Plex >>> language for GUI and/or business application? [What is currently best?] >>> >>> Even RAD/Visual Basic-style programming is just based on BASIC (or >>> Pascal in case of Delphi or lately what C#?). Julia doesn't have the GUI >>> part of that equation but could and it wouldn't be any worse as a part of a >>> such larger system, right? >>> >>> Same argument for individual games or engines (Unity uses JavaScript, >>> C#, could use Julia). >>> >>> >>> Android could work (already?), iOS probably (Apple requires using XCode >>> to submit to the app store, ok w/Julia2C?). >>> >>> >>> Database programming >>> >>> Julia supports *databases* but does it support the relational model as >>> best as possible? I'm not sure what should be in the languages themselves. >>> Not too familiar with: >>> https://en.wikipedia.org/wiki/Dataphor >>> >>> See: https://en.wikipedia.org/wiki/The_Third_Manifesto >>> >>> I have mixed feelings about OO in relation to RDMS (see ORM). >>> >>> For an opposing view to relational-only-best-programming, see (nothing >>> "should" use separate relational database, use only objects in memory): >>> >>> http://prevayler.org/ >>> >>> >>> At least PHP can't support this concept but this has been ported e.g. to >>> C# and I think Julia could (should?) have an implementation. Not seeing if >>> multiple dispatch (not "regular OO") should be any problem. >>> >>> [I haven't yet looked into it much, Julia has some serialization support >>> and not much else needed.] >>> >>> >>> >>> Maybe there are better 4GL languages? I only know Informix 4GL (and >>> Delphi in the GUI world).. not ABAP (SAP's), RPG or some later (or earlier >>> 4GL's that most have "died"..?). >>> >>> I see Julia supports ODBC (most (relational) databases covered) and >>> SQLite, MongoDB (and JSON). Any data(base) problems you know of? >>> >>> PostgreSQL at least supports Python for stored procedures. I assume an >>> extension for Julia could be done.. >>> >>> SQL or MDX (not really competitors to Julia, no more than other >>> non-Turing-complete ("non-programming") languages (HTML, XML). Could query >>> languages be better worked into Julia. Macros would help? Maybe changed >>> syntax (SQL->LINQ)? >>> >>> >>> First programming language >>> >>> I see three (more?) universities have started teaching Julia. For Matrix >>> methods (I guess replacing MATLAB). I don't know if any have used it as a >>> first language, but why not..? >>> >>> Unlike many common alternatives (e.g. C/C++/Java) I understand Julia >>> avoids Hoare's "billion dollar mistake" - pointers (and like newer Java >>> etc. has GC and easier than OO Java or Ruby). >>> >>> >>> First programming language for (really young) kids >>> >>> May not compete directly with Scratch, Alice etc. but note Scratch is >>> really a "GUI-wrapper" using Squeak language (a dialect of Smalltalk). >>> >>> Julia even could be competitive here. >>> >>> >>> Hard real-time >>> >>> Something like the Metronome GC algorithm could work Julia? >>> http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/41809/1/04-2432A.pdf >>> >>> Then at least I'm sure Julia *could* work but would it be "best" for >>> that "environment": >>> >>> Could Julia do similar to Atom? I don't know it or the other languages, >>> like those two for real-time: >>> http://lambda-the-ultimate.org/node/4488 >>> "You might take a look at Atom, which is a DSL embedded into Haskell, >>> and is used to produce real-time code for commercial products. It's open >>> source, so you can see what they do. You could also look at the book >>> Compiling Esterel, or some of Stephen Edwards' papers on the same topic. >>> >>> Synchronous reactive programming languages, like Esterel and Lustre, >>> typically execute the `whole graph` (whole program) on a per-cycle basis." >>> >>> https://en.wikipedia.org/wiki/Esterel >>> "Difficult to compile in the general case, but simple correctness >>> criteria exist".. >>> >>> >>> AI >>> >>> Lisp (and Prolog(?)) was popular for AI. Isn't "symbolic" pretty much >>> covered in Julia? Is Julia worse for something like that? Or anything you >>> can think of that Lisp is good for? >>> >>> Most have probably not heard of Replicode language for strong AI and I >>> do not really know to much about it or even if it's Turing-complete or >>> right to compare that to regular "programming languages". >>> >>> [Any AI languages/"systems" I should know about?] >>> >>> >>> Formal methods >>> >>> https://en.wikipedia.org/wiki/Z_notation >>> "Why Z?" with "Because it is the ultimate language!" >>> >>> I just do not know enought about Z-notation or formal in general, is Z >>> even a programming language (Turing-complete)? Just a "specification >>> language"? >>> >>> >>> Operating systems (including "web browser" (OSes)).. >>> >>> Linus famously doesn't like C++, wander if he would like Julia.. Would >>> or could Julia be considered a "systems programming language" (is Lisp..?)? >>> Seen articles saying so.. *Could* Julia at least work with C to build an OS >>> or even in Linux? That is made work to without major changes to the >>> *language*? But possibly to the implementation. Lisp machines had their own >>> OS written in Lisp. Maybe they only had single-tasking (non-preemptive) and >>> not fair to say OS in the modern sense (were just running Lisp?). >>> >>> >>> Alien OSes (such as RISC OS?) >>> >>> Only three platforms, but could be extended to run in non-Unix.. >>> >>> >>> * "Exotic" hardware >>> >>> Decimal floating point hardware. DFP (or even BCD) can be emulated, just >>> a library issue or native instructions used. And supporting both the >>> hardware and software format. I may recommend some small changes to core >>> (non-library) Julia just the same.. Not sure if a library (a first step) >>> will do. >>> >>> It seems Julia can support all current hardware (Julia2C) and as I'm not >>> up to speed on GPU's I reserve judgment there, but would like to know if >>> Julia supports "automatically" or could (OpenCL.jl is not for that?). Same >>> with FPGA's (unusual bitwidths.. But see myhdl.org "From Python to >>> Silicon!") using Julia as a HDL.. And Micron's automata processor. >>> >>> >>> Microcontrollers >>> >>> 4-bits are out.. but very hard to find anyway. >>> >>> 8-bit and 16-bit almost dead? Seems would work but 32-bit (ARM) is >>> killing them anyway.. >>> >>> Even Python had been proposed for microcontrollers: >>> http://www.micropython.org/ >>> >>> Since even Python can work, including for interrupt handling, then I >>> assume Julia could work in that space also. >>> >>> >>> >>> Adapteva's co-processor CPU. Very memory constrained (32 KB per core for >>> code, data and stack.. best not to use more..). How small could Julia >>> executables get (or the parts of executable, kernels, the coprocessor would >>> run)? >>> >>> GreenArray Forth chips are another story.. even more constrained.. >>> >>> >>> Lower than 32-bit CPUs (or maybe non-standard 18/36-bit etc..) >>> >>> Yes for serial; impossible for parallel (atomic issues)? Then Julia >>> would be "worse" than C, but not really in the modern age.. >>> >>> 8-bit bytes assumed (and no support for non-two's complement CPUs) is >>> also hardly a limitation (except FPGA support?). >>> >>> >>> Binary-coded decimal (4-bit) also not an issue, BCD not a means to an >>> end, seems fixed or floating point decimal would be better. >>> >>> >>> >>> Quantum computers >>> >>> Quantum computing, I do not know to well, has at least one programming >>> language, probably better than Julia in that case.. >>> >>> >>> Am I missing major areas? >>> >>> Best regards, >>> Palli. >>> >> >
