search for: deoptimizing

Dear R users, During the the running of DEoptim function which belongs to "DEoptim" package it automatically gives the output like the following: Iteration: 1 bestvalit: 181.379847 bestmemit: 0.226499 1.395852 Iteration: 2 bestvalit: 14.062649 bestmemit: 2.290357 5.597838 Iteration: 3 bestvalit: 14.062649 bestmemit: 2.290357 5.597838 Iteration: 4 bestvalit: 14.062649

Function DEoptim in package DEoptim for differential evolution defines an optional parameter fnMap: fnMap "an optional function that will be run after each population is created, but before the population is passed to the objective function. This allows the user to impose integer/cardinality constriants." Unfortunately, there is no further documentation decribing the kind of

Dear All, We are happy to announce the release of the new version of DEoptim (version 2.0-0) which is now available from CRAN. The DEoptim package [3] performs Differential Evolution (DE) minimization, a genetic algorithm-based optimization technique [2,3]. This allows robust minimization over a continuous (bounded or not) domain. The new DEoptim function calls a C implementation of the DE

Dear All, We are happy to announce the release of the new version of DEoptim (version 2.0-0) which is now available from CRAN. The DEoptim package [3] performs Differential Evolution (DE) minimization, a genetic algorithm-based optimization technique [2,3]. This allows robust minimization over a continuous (bounded or not) domain. The new DEoptim function calls a C implementation of the DE

Dear R Community, I am trying to optimize a water quality model that I am using. Based on conversations with others more familiar with what I am doing I plan to implement DEOptim to do this. The water quality model is interfaced through a GUI. I have the input file necessary to alter parameters and run the model as a text file. To do the optimization I have figured out the general procedure

...ntics of "deopt" operand bundles as in the LangRef, every call site above is readonly. However, it is possible for @baz() to write to memory if @bar is deoptimized at the call site with the call to @foo. You could say that it isn't legal to mark @foo as readonly, since the action of deoptimizing one's caller is not a readonly operation. But that doesn't work in cases like this: ``` global *ptr declare @foo() readwrite def @bar() { call @foo() [ "deopt"(XXX) ]; *ptr = 42 } def @baz() { call @bar() [ "deopt"(YYY) ]; int v0 = *ptr } ``` Naively, it looks like an...

I am trying to figure out how parameters are defined in a function that is used by DEOptim. That is, when I set upper and lower bounds for DEOptim how does it know which element of the function to apply those bounds to? For example, in DEOptim call below, when DEOptim goes into "optimfxn" how does it know what element of "optimfxn" to apply the upper and lower bounds to?

(the same mail was sent to the author) When I called the function DEoptim with control=list(strategy=1) or control=list(strategy=2) I got the error: Error in mui[rtd + 1, i] : incorrect number of dimensions Analysis of the source code of the DEoptim reveals the following fragment if (con$strategy > 5) st <- con$strategy - 5 ## binomial crossover else { st <-

Hi R-Core, i am using nnet and DEoptim, Xcc=matrix(rnorm(100,0.5,0.08),50,2) Ycr=matrix(rnorm(50,0.2,0.05),50,1) pred_regm1 <- function(A) { A1=A[1] A2=A[2] A3=A[3] regm1 <- nnet(Xcc,Ycr,entropy=T,size=A1,decay=A2,maxit=2000,trace=F,Hess=T,rang=A3,skip=T) dif=sum((predict(regm1,Xcc)-Ycr)^2) return(dif) } somar=DEoptim(pred_regm1,c(1,0.00001,0.01), c(25,0.999,0.95),

...lot of runtime support, but we already have most of it implemented for another compiler. From our perspective, the runtime requirements are not a major blocker. > > In a lot of languages, a divide produces some result even in the > exceptional case and this result requires effectively deoptimizing > since the resut won't be the one you would have predicted (double > instead of int, or BigInt instead of small int), which sort of means > that if the CPU exception occurs you have to be able to reconstruct > all state. A patchpoint could do this, and so could spilling all &...

...tion of where the deopt state comes from.) In fact, the more I look at this, the less difference I actually see between the approaches. >>> >>> In a lot of languages, a divide produces some result even in the >>> exceptional case and this result requires effectively deoptimizing >>> since the resut won't be the one you would have predicted (double >>> instead of int, or BigInt instead of small int), which sort of means >>> that if the CPU exception occurs you have to be able to reconstruct >>> all state. A patchpoint could do th...

Hello Everyone, I want to raise a discussion about @llvm.experimental.guard intrinsic and reasons why we should give up using it. Here is an alternative approach to representation of guards that resolves some of fundamental flaws that the current guards have. Basically, this intrinsic was introduced to model the following situation: we want to check that some condition is true, and if it's

...act, the more I look at this, the less >> difference I actually see between the approaches. >> >> >>>>> >>>>> In a lot of languages, a divide produces some result even in the >>>>> exceptional case and this result requires effectively deoptimizing >>>>> since the resut won't be the one you would have predicted (double >>>>> instead of int, or BigInt instead of small int), which sort of >>>>> means that if the CPU exception occurs you have to be able to >>>>> reconstruct all...

...uestion of where the deopt state comes from.) In  > fact, the more I look at this, the less difference I actually see between  > the approaches.  >  >  >  > In a lot of languages, a divide produces some result even in the exceptional  > case and this result requires effectively deoptimizing since the resut won't  > be the one you would have predicted (double instead of int, or BigInt  > instead of small int), which sort of means that if the CPU exception occurs  > you have to be able to reconstruct all state. A patchpoint could do this,  > and so could spilling all sta...

Hi, Sanjoy, On 2015-11-16 23:27, Sanjoy Das wrote: > Hi Vlad, > > vlad via llvm-dev wrote: >>> Vlad, >>> >>> My initial impression is that you've stumbled across a bug. I suspect >>> that we - the only active users of the deopt info in the statepoint I >>> know of - have been inverting the meaning of Direct and Indirect >>>

...at apple.com> wrote: > This clearly doesn't need operand bundles, but using an intrinsic > would permit special code motion semantics. It could be hoisted and > merged with other traps, but the condition could never be widened > beyond the union of the original conditions. Unlike deoptimizing > guards, it would need to be sequenced with memory barriers, but could By memory barrier, do you mean things like fences? > otherwise be hoisted as readnone. Can you clarify this a little bit? Are you talking about things like: *ptr = 42 @trap_if(%foo) => @trap_if(%foo) *ptr...

> Vlad, > > My initial impression is that you've stumbled across a bug. I suspect > that we - the only active users of the deopt info in the statepoint I > know of - have been inverting the meaning of Direct and Indirect > throughout our code. (i.e. we're consistent, but swapped on the > documented meaning) I've asked Sanjoy to confirm that, and if he >

Hi Sanjoy, Thanks for feedback! As for memory effects, currently I use " inaccessiblememonly " for it. It allows to prove that it doesn't alias with any other load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitching).

We'd like to propose a scheme to attach "operand bundles" to call and invoke instructions. This is based on the offline discussion mentioned in http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/088748.html. # Motivation & Definition Our motivation behind this is to track the state required for deoptimization (described briefly later) through the LLVM pipeline as a

Hi everyone, we started a new open source project Sulong: https://github.com/graalvm/sulong. Sulong is a LLVM IR interpreter with JIT compilation running on top of the JVM. By using the Truffle framework, it implements speculative optimizations such as inlining of function pointer calls through AST rewriting. One area of our research is to provide alternative ways of executing LLVM bitcode that