[BrandonS113]

sure, for parameters par (what is optimized for), data vector x (typical length from 10 to 20), constants n and n2, a typical function is

  if((1 - par[3]^2)<0 ) return(100)
  if(par[1] + par[2] \* par[5] \* sqrt(1 - par[3]^2)<0) 
  return(500 )
  tmp <- (x - par[4])^2 + par[5]^2
  tmp2 <- par[1] + par[2] \* (par[3] \* (x - par[4]) + 
  sqrt(tmp))
  result <- ((sqrt(tmp2) - Ce) / n2)^2
  result <- sqrt(sum(n \* result) / n)
  if(is.na(result)) return(1111)
  return(result)

[DNF2]

I'm not that good at reading R. But if the Julia code is similar, then this code is type unstable, sometimes returning an Int, sometimes a Float. That harms performance.

Generally, it looks like a function where Julia could have a significant performance advantage.

[BrandonS113]

R looks pretty much the same as Julia here. Don't think its unstable. Its all float. Nlopt passes parameters as float, data is float. Can't see how it could return int.

But I'll take a second look at the julia version of it. We optimised R as much as possible. might have missed a julia trick. simd perhaps. Except we also run it on ARM

[DNF2]

Maybe it's all floats in R, but in Julia, `return 500` means an Int is returned. But it's really hard to determine whether the Julia code is unstable based only on the R code.