On Tue, Feb 4, 2014 at 2:48 PM, Raul Miller <[email protected]> wrote:
> > Mostly what I want for J is a compiler for a limited subset of the > language. This would let us address a variety of performance issues, > and would also introduce some new problems. Problems, though, that we > should welcome. > > I have also thought about JIT compiling C code from J and using cd to execute it. I have used this approach from PicoLisp[1], which uses GCC or TCC[2] and shells out. It could also be done through libtcc. This should enable high performance code. I'd be interested in benchmarking it some time. [1] - https://code.google.com/p/picolisp/source/browse/cygwin/tcc.l?r=729464680d070c2f3cb63c2f93b3269997ebc017 [1] - https://code.google.com/p/picolisp/source/browse/misc/fibo.l [2] - http://bellard.org/tcc/ On Tue, Feb 4, 2014 at 2:48 PM, Raul Miller <[email protected]> wrote: > My impression also is that array thinking is crucial to getting good > performance out of computer systems. In today's economy, though, we > need to deal with multiple programming languages if we're going to get > any of the really good jobs (either that or work in finance - those > guys are starved for really good programmers, but even there having a > background in multiple programming languages might help). > > That said, here's my take on Julia's feature list: > > Multiple dispatch: we've got this, in a carefully tuned sense, we have > better things to emphasize. > Dynamic type system: we've got this. > Good performance: we've got this. Room to play here, though. > Built-in package manager: we've got this. > Lisp-like macros and other metaprogramming facilities: we've got this. > Call Python functions: use the cd facility (need documentation though). > Call C functions directly: use the cd facility > Powerful shell-like capabilities for managing other processes: see below > Designed for parallelism and distributed computation: we need more work > here > Coroutines: related to parallelism, see below > User-defined types: overrated, but see below > Automatic generation of efficient, specialized code for different > argument types: see below > Elegant and extensible conversions and promotions for numeric and > other types: see below > Efficient support for Unicode, including but not limited to UTF-8: > we've got this > MIT licensed: GPL works just fine > > Mostly what I want for J is a compiler for a limited subset of the > language. This would let us address a variety of performance issues, > and would also introduce some new problems. Problems, though, that we > should welcome. > > Hypothetically speaking, J (or subsets) could be a language for use on > GPU clusters, on large distributed clusters, and for a variety of > other contexts. There's no technical reason we couldn't have process > management vocabularies in the language. But if we go there we'd need > to support the resulting user community, and that needs someone to > pilot it and support it. Lots of people, potentially. It's not just > about the job possibilities - we'd need textbooks for teaching people > and drawing connections to interesting topics, we'd need to support > the academics who found some relevance in our approaches and we'd have > to do that while managing to trim back some of the suggestions. > > It seems to me that we could have a J subset targeted at just the > features needed to implement LAPACK and wired into gcc for code > generation. > > It also seems to me that once we had this we could use that subset to > bootstrap a J implementation. Lots of work needed to do that, though, > and we'd probably need a lot of Roger Hui's help if we wanted to get > that done any time soon. > > And then there's the support facilities. Honestly, nothing I am > proposing here compares in importance to getting J version 8 to have > the feature set of J version 6. But it's also good, I think, to have > some momentum for future work going also. > > But a lot of Julia's feature set (user defined types, in particular) > run counter to array thinking. Array thinking pushes arbitrary > complexity into the high level components and regularity into the low > level components. This means that its results tend to scale well and > tend to expose problems early. But this can be a problem as much as a > solution. Sometimes the right approach is not to scale well but to > just hide the problems, and maybe even make them shiny and attractive. > So I think we, as a community, have to be a bit more tolerant of that > kind of thing. User defined types are about enshrining complexity at > the lowest levels of the coding system, and it's an excellent tool for > creating messes but it's a popular tool and maybe if we can bootstrap > ourselves in J that will move us closer to this approach for > messiness. > > And, of course, we've already got rather elegant support for existing > numeric types, it's creating new ones where we start running into > issues. > > Still, before user defined types, it would also be good to introduce > process management, and process management demands a couple things > from J - a notation and tool set for communicating with processes > using J sentences (or a subset) as the language between them and also > a notation and tool set for starting and stopping those processes. > > That said, quaternions are a good example of a useful numeric type > that's not supported by J. Quaternions map rather nicely onto SSE > instructions (http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) > and also map rather nicely onto opengl and onto directx. A problem, > though, is that the internal organization needed for efficient and > logical use in opengl conflicts with the internal organization neded > for effecient and logical use in directx. > > Anyways... there's a ton of work to do, and I'm trying to motivate > myself to start chewing into it. > > Thanks, > > -- > Raul > > > > > On Tue, Feb 4, 2014 at 1:38 PM, Devon McCormick <[email protected]> > wrote: > > I went to a talk about a year ago by the developers of this language: I > > walked out at the break. > > > > The two important things I learned are: most people's understanding of > > arrays is abysmal and Javascript's performance is pretty amazing. > > > > In fact, my frustration at the primitive state of understanding about > > arrays was in part what motivated my recent J talk. > > > > Their performance comparison slide was where I noticed that Javascript > was > > the best performer for many of their tests. > > > > > > > > On Tue, Feb 4, 2014 at 1:21 PM, Raul Miller <[email protected]> > wrote: > > > >> http://julialang.org/ > >> > >> What can we learn from this? > >> > >> I think we've a lot of catching up to do, on the implementation side, > >> and on the integration side. (And maybe a few things to teach the > >> folks at MIT, also.) > >> > >> Thanks, > >> > >> -- > >> Raul > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > > > > > > > -- > > Devon McCormick, CFA > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
