[julia-users] Re: Julia Summer of Code

2015-05-16 Thread Oscar Blumberg
I just added (what I think is) a cool project for anyone who would want to 
dive deep into the compiler. It may be on the hard end of the spectrum but 
we all know what happens when you tell a student something is "too hard" ;)

https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-specialized-call-site-method-caching

On Friday, May 15, 2015 at 1:57:24 PM UTC-4, Viral Shah wrote:
>
> Folks,
>
> The Moore Foundation is generously funding us to allow for 6-8 Julia 
> Summer of Code projects. Details will be published soon, but if you are 
> interested, please mark your calendars and plan your projects.
>
> -viral
>


[julia-users] Re: Julia Memory Management

2016-05-26 Thread Oscar Blumberg
When video game people say that they usually mean "tracing gc" instead of 
"gc" and it's about the latency, not the throughput, which Yichao explained.
A game has a soft deadline every few tens of milliseconds to render to the 
screen and gc pauses can make the experience miserable.
Interestingly a lot of games actually have a tracing gc that handles some 
objects, either because they embed a managed scripting language for 
gameplay or even because they have a C++ gc (I'm looking at you Unreal 
Engine).
The key is to keep the number of managed object small-ish and collect them 
incrementally every frame.
The general saying "gc is a no go for real-time games" usually comes with a 
strawman where every single 3 component vector is heap allocated.

On Thursday, May 26, 2016 at 2:13:15 PM UTC-4, Ford Ox wrote:
>
> This is the wrong question to ask
>>
>  
> I wanted to write 'good enough' but then I discarded it since its too 
> broad term. It was a mistake.
>
> I was wondering, whether there will ever be so well rounded GC, that ... 
> "reference counting, manual allocation / freeing and all that c++ stuff 
> will be obsolete."
>
> Reacting to Jeff post
>
> I always hear from people working in game industry (graphics) that GC 
> languages can't be used, since it always causes some minor lags. Is that 
> another misinformation?
>


Re: [julia-users] jl_tuple2

2016-06-28 Thread Oscar Blumberg
https://github.com/JuliaLang/julia/blob/master/src/julia.h#L588

On Monday, June 27, 2016 at 2:16:01 PM UTC-4, Stephen Chisholm wrote:
>
> Yichao, could you explain why this is unsafe? Do you know of an 
> alternative which is safe?
>
> On Monday, 20 June 2016 16:31:29 UTC-3, Yichao Yu wrote:
>>
>> On Mon, Jun 20, 2016 at 3:27 PM, Stephen Chisholm  
>> wrote: 
>> > While helping out with 
>> > 
>> http://stackoverflow.com/questions/37913625/call-julia-svd-from-c/37929076#37929076
>>  
>> > I noticed jl_tuple2 was removed in 
>> afd4eb038dcd9fa3e512509f4c332a9e7763ba59 
>> > by Jeff Bezanson while refactoring tuples.  Just wondering if anyone is 
>> able 
>> > to help me find an alternative.  Below is what I used to be able to do. 
>>  My 
>> > current work around is to use jl_eval_string("(2,2)"), but I'm hoping 
>> that 
>> > there is still a way to build the dims parameter without a call to 
>> > jl_eval_string. 
>> > 
>> > 
>> >   double m[] = {1,2,3,4}; 
>> > 
>> >   jl_value_t *array_type = jl_apply_array_type(jl_float64_type, 2); 
>> >   jl_tuple_t *dims = jl_tuple2(jl_box_int64(2), jl_box_int64(2)); 
>>
>> FYI, this is generally unsafe. 
>>
>> >   jl_array_t *jl_m = jl_ptr_to_array(array_type, m, dims, 0); 
>> > 
>> > 
>>
>