Re: [julia-users] Julia implementation

[Scott Jones]

>From my own experiences, while I do believe rewriting it in C would make it 
faster, a much better option would be to adapt JuliaParser.jl.  Last year 
right when I first started with Julia, I thought I'd need to implement most 
of code that was performance critical (at least for me) in C, and call that 
from Julia (and was following examples in Julia itself where C is used). 
 However, I got schooled by some of the top Julia contributors (in 
particular Tony Kelman), that well-written, readable Julia code can still 
be as fast as C, and I have the microbenchmarks (about Unicode string 
conversions) to prove it.
Jeff recently told me that the parser actually isn't the biggest issue with 
replacing Scheme with Julia, it's rather the lowering code.
It would be nice to see that ported to Julia, and then do some performance 
comparisons.

Replacing all of the Scheme code with Julia (and moving more of the lower 
level stuff for Unicode from C to Julia) I think would greatly help 
allowing more contributors to work on the core language,
as it is, mad skillz are needed in Julia, Scheme, C, C++, and LLVM IR to 
work across the board.

On Tuesday, May 24, 2016 at 12:57:37 PM UTC-4, Stefan Karpinski wrote:
>
> Rewriting the parser in C would (probably) make it faster. So would 
> compiling it using e.g. the recently-open-sourced ChezScheme 
> , which is a less drastic measure.
>
> On Tue, May 24, 2016 at 12:47 PM, Ford Ox 
> > wrote:
>
>> Thank you very much.
>>
>> One more question : Is there any speed to gain,  when all that stuff 
>> would be rewritten in the lowest possible language? (I guess that is 
>> assembler or machine code :D) 
>
>
>

Re: [julia-users] Julia implementation

[Stefan Karpinski]

Rewriting the parser in C would (probably) make it faster. So would
compiling it using e.g. the recently-open-sourced ChezScheme
, which is a less drastic measure.

On Tue, May 24, 2016 at 12:47 PM, Ford Ox  wrote:

> Thank you very much.
>
> One more question : Is there any speed to gain,  when all that stuff would
> be rewritten in the lowest possible language? (I guess that is assembler or
> machine code :D)

Re: [julia-users] Julia implementation

[Ford Ox]

Thank you very much. 

One more question : Is there any speed to gain,  when all that stuff would be 
rewritten in the lowest possible language? (I guess that is assembler or 
machine code :D) 

Re: [julia-users] Julia implementation

[Didier Verna]

Stefan Karpinski wrote:

> There's something delightful about the fact that in order to change
> the syntax of Julia, you must first prove yourself proficient in a
> language that actively rejects the very concept of fancy syntax.

  :-D :-D :-D

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Julia implementation

[Stefan Karpinski]

On Tue, May 24, 2016 at 10:56 AM, Isaiah Norton 
wrote:

>

- Scheme: because Julia is a Trojan Horse to finally make the world use
> Lisp. because it keeps the pesky peasants out. because it's a great
> compiler language and allowed fast implementation and iteration. There is
> some interest in moving the front end to pure Julia, and the parser has
> been ported already (JuliaParser.jl) -- that's about ~1/3 of the job.
> Porting the lowering and sorting out bootstrapping is a fair amount of
> effort and would likely need to be done by people who could be making more
> user-relevant improvements elsewhere. So far, doing so hasn't been a
> priority.
>

There's something delightful about the fact that in order to change the
syntax of Julia, you must first prove yourself proficient in a language
that actively rejects the very concept of fancy syntax.

Re: [julia-users] Julia implementation

[Isaiah Norton]

I would suggest to read src/README.md and the Devdocs (
http://docs.julialang.org/en/latest/devdocs/julia/) for an overview of the
organization of the codebase.


> What is not implemented in julia?
> What language is it implemented in? (I think that arrays come from c,
> right?)


- frontend (parsing and lowering): small Scheme variant called flisp, also
written by Jeff Bezanson
- runtime (primitives, allocation, GC): C
- code generation: C++
- various libraries are written in C, Fortran, etc. (PCRE, BLAS, GMP,
libgit2, ...)

Why is it implemented in that particular language?


- C: because is the lowest-common-denominator for system implementations.
- C++: because it is the most straight-forward way to interface with LLVM.
- Scheme: because Julia is a Trojan Horse to finally make the world use
Lisp. because it keeps the pesky peasants out. because it's a great
compiler language and allowed fast implementation and iteration. There is
some interest in moving the front end to pure Julia, and the parser has
been ported already (JuliaParser.jl) -- that's about ~1/3 of the job.
Porting the lowering and sorting out bootstrapping is a fair amount of
effort and would likely need to be done by people who could be making more
user-relevant improvements elsewhere. So far, doing so hasn't been a
priority.


On Tue, May 24, 2016 at 10:24 AM, Ford Ox  wrote:

> Docs state that most of the julia language is implemented in julia itself.
> What is not implemented in julia?
> What language is it implemented in? (I think that arrays come from c,
> right?)
> Why is it implemented in that particular language?
>
>

Re: [julia-users] Julia implementation of zlib and gzip decompression

[Stefan Karpinski]

I kind of figured that, but thought I'd point out its existence anyway. I
think it's great to have gzip implemented in pure Julia since there are a
lot of cases where all you need is to be able to decompress something and
you don't want any dependencies.


On Mon, Jan 6, 2014 at 9:15 AM, Gunnar Farnebäck wrote:

> That's actually also a gzip decompression implementation, so there's a
> large overlap in that they both implement the inflate algorithm. Otherwise
> the interfaces are rather different and her implementation includes a
> visualization branch whereas my implementation is two orders of magnitude
> faster.
>
> Den lördagen den 4:e januari 2014 kl. 19:03:33 UTC+1 skrev Stefan
> Karpinski:
>>
>> Possibly relevant is Julia Evan's gzip implementation:
>>
>> http://jvns.ca/blog/2013/10/24/day-16-gzip-plus-poetry-equals-awesome/
>>
>>
>> On Sat, Jan 4, 2014 at 6:54 AM, Gunnar Farnebäck 
>> wrote:
>>
>>> At some point when I had trouble loading zlib I wrote a pure Julia
>>> implementation of zlib and gzip decompression.
>>>
>>> Pros:
>>> * Written in Julia.
>>> * No external dependencies.
>>>
>>> Cons:
>>> * Only supports decompression and only from a buffer (i.e. no streaming).
>>> * Substantially slower than zlib (about five times when I wrote it,
>>> current status unknown).
>>> * Much less tested than zlib.
>>>
>>> Is this of interest to someone else, e.g. as a package or as a
>>> performance test?
>>>
>>> The code can be viewed at
>>>
>>> https://gist.github.com/GunnarFarneback/8254567
>>>
>>>
>>

Re: [julia-users] Julia implementation of zlib and gzip decompression

[Gunnar Farnebäck]

That's actually also a gzip decompression implementation, so there's a 
large overlap in that they both implement the inflate algorithm. Otherwise 
the interfaces are rather different and her implementation includes a 
visualization branch whereas my implementation is two orders of magnitude 
faster.

Den lördagen den 4:e januari 2014 kl. 19:03:33 UTC+1 skrev Stefan Karpinski:
>
> Possibly relevant is Julia Evan's gzip implementation:
>
> http://jvns.ca/blog/2013/10/24/day-16-gzip-plus-poetry-equals-awesome/
>
>
> On Sat, Jan 4, 2014 at 6:54 AM, Gunnar Farnebäck 
> 
> > wrote:
>
>> At some point when I had trouble loading zlib I wrote a pure Julia 
>> implementation of zlib and gzip decompression.
>>
>> Pros:
>> * Written in Julia.
>> * No external dependencies.
>>
>> Cons:
>> * Only supports decompression and only from a buffer (i.e. no streaming).
>> * Substantially slower than zlib (about five times when I wrote it, 
>> current status unknown).
>> * Much less tested than zlib.
>>
>> Is this of interest to someone else, e.g. as a package or as a 
>> performance test?
>>
>> The code can be viewed at
>>
>> https://gist.github.com/GunnarFarneback/8254567
>>
>>
>

Re: [julia-users] Julia implementation of zlib and gzip decompression

[Stefan Karpinski]

Possibly relevant is Julia Evan's gzip implementation:

http://jvns.ca/blog/2013/10/24/day-16-gzip-plus-poetry-equals-awesome/


On Sat, Jan 4, 2014 at 6:54 AM, Gunnar Farnebäck wrote:

> At some point when I had trouble loading zlib I wrote a pure Julia
> implementation of zlib and gzip decompression.
>
> Pros:
> * Written in Julia.
> * No external dependencies.
>
> Cons:
> * Only supports decompression and only from a buffer (i.e. no streaming).
> * Substantially slower than zlib (about five times when I wrote it,
> current status unknown).
> * Much less tested than zlib.
>
> Is this of interest to someone else, e.g. as a package or as a performance
> test?
>
> The code can be viewed at
>
> https://gist.github.com/GunnarFarneback/8254567
>
>