similar to: julia language unfair comparisons against R

Folks, We are contemplating holding a Birds of a Feather session titled "Julia and LLVM: Implementing a fast dynamic language for technical computing" at the LLVM 2012 European Conference on April 12-13 in London. http://llvm.org/devmtg/2012-04-12/ Would this be of interest to the LLVM developer and user community? It would be great if you could drop me a line. It will help us gauge

My purpose in mentioning the Julia language (julialang.org) here is not to start a flame war. I find it to be a very interesting development and others who read this list may want to read about it too. It is still very much early days for this language - about the same stage as R was in 1995 or 1996 when only a few people knew about it - but Julia holds much potential. There is a thread about

Hi All, I've just recently discovered the cmpfun function, and was wanting to to create a function to assign this to all the functions i have created, but without explicitly naming them. I've achieved this with: foo <- function(x) { print(x)} bar <- function(x) { print(x + 1)} > foo <- function(x) { print(x)} > foo function(x) { print(x)} > cmpfun(foo) function(x) {

When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make check fails reg-tests-1b.R at the following check: x <- c(1:2, NA) sx <- sd(x) !is.nan(sx) Here 'sx' should be 'NA' but it is 'NaN'. It turns out this problem only appears when the function is byte compiled with optimization level 3: mysd <- function (x, na.rm = FALSE) sqrt(var(if

Dear LLVM contributors, my name is Matthias, I am a graduate student majoring in computer science at the Vienna University of Technology, and I am glad to be one of this year's GSoC students who work for the Julia foundation. Julia is a relatively young programming language that uses LLVM for just-in-time compilation and the goal of my project is to integrate Polly in this environment to

Hi, I found the following issue in r-devel (2019-01-02 r75945): `foo<-` <- function(x, value) { bar(x) <- value * x x } `bar<-` <- function(x, value) { stopifnot(all(value / x == 1)) x + value } `foo<-` <- compiler::cmpfun(`foo<-`) `bar<-` <- compiler::cmpfun(`bar<-`) x <- c(2, 2) foo(x) <- 1 x # should be c(4, 4) #> [1] 3 3 If the functions

On 03/01/2019 3:37 p.m., Duncan Murdoch wrote: > I see this too; by bisection, it seems to have first appeared in r72943. Sorry, that was a typo. I meant r75943. Duncan Murdoch > > Duncan Murdoch > > On 03/01/2019 2:18 p.m., I?aki Ucar wrote: >> Hi, >> >> I found the following issue in r-devel (2019-01-02 r75945): >> >> `foo<-` <-

Luke, Thank you for sharing the benchmark results. The improvement is very substantial, I am looking forward to the release of the byte compiler! The arithmetic shows that x[i]<- is still the bottleneck. I suspect that this is due to a very involved dispatching/search for the appropriate function on the C level. There might be significant gain if loops somehow cached the result of the initial

I noticed some problems that cropped in the latest versions of R-devel (2016-11-08 r71639 in my case) for one of my packages. I _think_ I have narrowed it down to the changes to what gets byte-compiled by default. The following example run illustrates the problem I'm having: compiler::enableJIT(0) fun <- function(x) local(as.list(parent.frame(2))) fun(1) ## $x ## [1] 1 ##

Thanks for the reports. Will look into it soon and report back. Luke Sent from my iPhone > On Jan 3, 2019, at 2:15 PM, Martin Morgan <mtmorgan.bioc at gmail.com> wrote: > > For what it's worth this also introduced > >> df = data.frame(v = package_version("1.2")) >> rbind(df, df)$v > [[1]] > [1] 1 2 > > [[2]] > [1] 1 2

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.

Dear Community, in an earlier post, students working on LLVM were asked to provide a short report on their GSoC project. in the following I want to give an overview on the current status of my GSoC project and outline my next planned activities. Since my mentoring organization is Julia, I also send this to the according mailing list. *1. Activities so far:* As described in my proposal [1], I

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

I agree with the others that this seems great! I think this information can be super helpful for users both in learning and skimming assembly codes. As a maintainer of a LLVM frontend (JuliaLang), I'm additionally interested in whether some bits of this make sense to end up in libLLVM itself. Probably especially the collection code pieces. For context, I've previously written some code to

Mark, that's actually a fair statement, although your extra operator doesn't cause construction at parse time. You still call paste0(), but just add an extra layer on top of it. I also doubt that even in gigantic loops the benefit is going to be significant. Take following example: atestfun <- function(x){ y <- paste0("a very long", "string for

Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found

I'm working on some small improvements to SLPVectorizer.cpp so that it can deal with some tuple operations arising from Julia code. Being fairly new to LLVM, I could use some advice, particular from those familiar with the internals of SLPVectorizer. The motivation can be found in the Julia discussion https://github.com/JuliaLang/julia/issues/5857 . Here is an example of the kind of LLVM

>>>>> Suzen, Mehmet <msuzen at gmail.com> >>>>> on Mon, 30 Oct 2017 11:16:30 +0100 writes: > Hi Frank, You could upload your R source file to a public > URL, for example to github and read via RCurl, as source > do not support https as far as I know. well... but your knowledge is severely (:-) outdated. Why did you not try first?

Hello, I'm trying to fix a long standing issue we are having in Julia where when the file information switched, we weren't recording that correctly, so line information showed up in the wrong file. Basically we would always create a scope with the DISubprogram and the given line number. What I tried was to change the scope to be a DIFile instead so we'd get the correct file

On Wed, Jun 14, 2017 at 8:48 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote: > As I recall this has been discussed at least a few times (unfortunately I'm traveling so can't check the references), but the justification was never satisfactory. > > Personally, I wouldn't mind string continuation supported since it makes for more readable code (I had one of my