search for: deoptimize

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

...r() { call @foo() [ "deopt"(XXX) ] } def @baz() { call @bar() [ "deopt"(YYY) ] } ``` Right now according to the semantics 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()...

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),

...(i.e. JavaScript's (a/b)|0). I concede that a > trapping intrinsic would allow you to make this one case work, in > cases where your profiling told you that the corner cases are rare. > > - Arrange to spill all state to the stack just to be able to throw an > exception and/or deoptimize - i.e. you're crazy enough to think that > the branch you just saved was more expensive than a bunch of stack > traffic. > > I believe that the currently proposed intrinsics give us more of what > we want on x86, than does your proposal, since they are more general, > and...

...of a branch (which was probably cheap > to begin with). > > Hence, what you want to do - one way or another, regardless of whether > this proposed intrinsic is added - is to branch on the corner case > condition, and have the slow case of the branch go to a basic block > that deoptimizes. Unless of course you have profiling that says that > the case does happen often, in which case you can have that basic > block handle the corner case inline without leaving optimized code > (FWIW, we do have such paths in WebKit and they are useful). > > So the question for me...

...ive 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 not, we should deoptimize at this point and quit execution of the compiled code. According to http://llvm.org/docs/LangRef.html#llvm-experimental-guard-intrinsic, the guard looks like this: define void @llvm.experimental.guard(i1 %pred, <args...>) { %realPred = and i1 %pred, undef br i1 %realPred, label %continue...

...ng patchpoint > to do your trapping deopt, what I mean is that the performance of > doing this would suck for reasons that are not related to > deoptimization or trapping. I'm not claiming that deoptimization > performs poorly (trust me, I know better) or that trapping to > deoptimize is bad (I've done this many, many times and I know better). > I'm saying that with the current patchpoint intrinsics in LLVM, as > they are currently specified and implemented, doing it would be a bad > idea because you'd have to compromise a bunch of other optimizations &...

...existing patchpoint to do  > your trapping deopt, what I mean is that the performance of doing this would  > suck for reasons that are not related to deoptimization or trapping. I'm  > not claiming that deoptimization performs poorly (trust me, I know better)  > or that trapping to deoptimize is bad (I've done this many, many times and I  > know better). I'm saying that with the current patchpoint intrinsics in  > LLVM, as they are currently specified and implemented, doing it would be a  > bad idea because you'd have to compromise a bunch of other optimizations to ...

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 >>>

...te0, if resumed to may actually write something else to *ptr. Making the call to @something() read/write/may unwind does not solve the problem -- even if the call to @something() wrote to *ptr (or threw an exception), we could still fold k to 100. The novel control flow here is that `@caller`, if deoptimized with `state0`, will execute some arbitrary code, and **return** to @caller at the callsite to @callee. (Btw: things are a little different inside our JVM because of the way we register dependencies, but I'm trying to make a LLVM-centric argument here.) At this point, I think it is most strai...

> 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 >

...re 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 not, we should deoptimize at this point and quit execution of the compiled code. According to http://llvm.org/docs/LangRef.html#llvm-experimental-guard-intrinsic, the guard looks like this: > > > > define void @llvm.experimental.guard(i1 %pred, <args...>) { > > %realPred = and i1 %pred, undef >...

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