search for: deoptimized

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

On 04/29/2014 10:44 AM, Filip Pizlo wrote: > LD;DR: Your desire to use trapping on x86 only further convinces me > that Michael's proposed intrinsics are the best way to go. I'm still not convinced, but am not going to actively oppose it either. I'm leery of designing a solution with major assumptions we don't have data to backup. I worry your assumptions about

On 04/29/2014 12:39 PM, Filip Pizlo wrote: > On April 29, 2014 at 11:27:06 AM, Philip Reames > (listmail at philipreames.com <mailto:listmail at philipreames.com>) wrote: >> On 04/29/2014 10:44 AM, Filip Pizlo wrote: >>> LD;DR: Your desire to use trapping on x86 only further convinces me >>> that Michael's proposed intrinsics are the best way to go.

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

Andy - If you're not already following this closely, please start. We've gotten into fairly fundamental questions of what a patchpoint does. Filip, I think you've hit the nail on the head. What I'm thinking of as being patchpoints are not what you think they are. Part of that is that I've got a local change which adds a very similar construction (called

On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com) wrote: On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames  <listmail at philipreames.com> wrote:  > Andy - If you're not already following this closely, please start. We've  > gotten into fairly fundamental questions of what a patchpoint does.  >  > Filip,  >  > I think you've hit the nail on

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

> 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