genetic improvement - phdopen.mimuw.edu.plphdopen.mimuw.edu.pl/zima15/petke-slides/gi.pdf ·...

Genetic Improvement

Justyna Petke

Centre for Research in Evolution, Search and TestingUniversity College London

CREST Justyna PetkeGenetic Improvement

Thank you

Mark Harman Yue Jia Alexandru Marginean

What does the word “Computer” mean?

Oxford Dictionary

“a person who makes calculations, especially with a calculating machine.”

Wikipedia“The term "computer", in use from the mid 17th

century, meant "one who computes": a person performing mathematical calculations.”

What does the word “Computer” mean?

Oxford Dictionary

“a person who makes calculations, especially with a calculating machine.”

Wikipedia“The term "computer", in use from the mid 17th

century, meant "one who computes": a person performing mathematical calculations.”

in the beginning ...

The First Computer?

Different People have different opinions

Who are the programers

it’s always been people

lots of people

why people?

human computers seem quaint today

will human programmers seem quaint tomorrow ?

programming is changing

RequirementsRequirements

Functional Requirements

Non-Functional Requirements

Memory

Execution Time

Battery

Bandwidth functionality of the Program

Software Design Process

Multiplicity

Multiple Devices

Conflicting Objectives

Multiple Platforms

Which requirements must be human coded ?

humans have to define these

Which requirements are essential to human ?

we can optimise these

Pareto Front

each circle is a program found by a machine

Pareto Front

different nonfunctional

properties havedifferent paretoprogram fronts

Failed Test Cases

Why can’t functional properties be optimisation objectives ?

Optimisation

2.5 times faster but failed 1 test case?

Optimisation

double the battery life but failed 2 test cases?

ConformantGI

VS. HereticalGI

functional correctness

is king

conforms totraditional

ConformantGI

VS. HereticalGI

is king

correctness meanshaving sufficient resources

for computation

conforms to acompelling new

orthodoxy

ConformantGI

VS. HereticalGI

is king

correctness meanshaving sufficient resources

for computation

conforms to acompelling new

orthodoxy

there’s nothing correct about a flat battery

can it work ?

Software Uniqueness

500,000,000 LoCone has to write approximately 6 statements before one is writing unique code

Software Uniqueness

500,000,000 LoCone has to write approximately 6 statements before one is writing unique code

M. Gabel and Z. Su. A study of the uniqueness of source code. (FSE 2010)

The space of candidate programs is far smaller than we might suppose.

Software Robustness

after one line changes up to 89% of programs that compile run without error

Software Robustness

after one line changes up to 89% of programs that compile run without error

W. B .Langdon and J. Petke Software is Not Fragile. (CS-DC 2015)

Software engineering artefacts are more robust than is often assumed.

CREST Justyna Petke

Genetic Improvement for Software Specialisation

CREST Justyna Petke

Question

Can we improve the efficiency of an already highly-optimised piece of

software using genetic programming?

Genetic Improvement Justyna Petke

Contributions

Introduction of multi-donor software transplantation

Use of genetic improvement as means to specialise software

Genetic Improvement

Program Representation

Changes at the level of lines of source code

Each individual is composed of a list of changes

Specialised grammar used to preserve syntax

Example

Code Transplants

GP has access to both:

• the host program to be evolved

• the donor program(s)

code bank contains all lines of source code GP has access to

Mutation

Addition of one of the following operations:

delete

replace

Example

Crossover

Concatenation of two individuals

by appending two lists of mutations

Fitness

Based on solution quality and

Efficiency in terms of lines of source code

Avoids environmental bias

Fitness

Test cases are sorted into groups

One test case is sampled uniformly from each group

Avoids overfitting

Selection

Fixed number of generations

Fixed population size

Initial population contains single-mutation individuals

Selection

Top-half of population selected

Based on a threshold fitness value

Mutation and Crossover applied

Genetic Improvement

Filtering

Mutations in best individuals are often independent

Greedy approach used to combine best individuals

Question

Can we improve the efficiency of an already highly-optimised piece of

software using genetic programming?

Motivation for choosing a SAT solver

Boolean satisfiability (SAT) example:

x1 ∨ x2 ∨ ¬x4

¬x2 ∨ ¬x3

• xi : a Boolean variable

• xi, ¬xi : a literal

• ¬x2 ∨ ¬x3 : a clause

Bounded Model Checking

Planning

Software Verification

Automatic Test Pattern Generation

Combinational Equivalence Checking

Combinatorial Interaction Testing

and many other applications..

MiniSAT-hack track in SAT solver competitions

- good source for software transplants

Question

Can we evolve a version of the MiniSAT solver that is faster than any

of the human-improved versions of the solver?

Experiments: Setup

Solvers used:

MiniSAT2-070721

Test cases used:

∼ 2.5% improvement for general benchmarks (SSBSE’13)

MiniSAT-hack track in SAT solver competitions

- good source for software transplants

Question

Can we evolve a version of the MiniSAT solver that is faster than any

of the human-improved versions of the solver for a particular

problem class?

Experiments: Setup

Solvers used:

MiniSAT2-070721

Test cases used:

from Combinatorial Interaction Testing field

Use of SAT-solvers limited due to poor scalability

SAT benchmarks containing millions of clauses

It takes hours to days to generate a CIT test suite using SAT

Experiments: Setup

Host program:

MiniSAT2-070721 (478 lines in main algorithm)

Donor programs:

MiniSAT-best09 (winner of ’09 MiniSAT-hack competition)

MiniSAT-bestCIT (best for CIT from ’09 competition)

- total of 104 new lines

Results

Solver Donor Lines Seconds

MiniSAT (original) — 1.00 1.00

MiniSAT-best09 — 1.46 1.76

MiniSAT-bestCIT — 0.72 0.87

MiniSAT-best09+bestCIT — 1.26 1.63

Question

How much runtime improvement can we achieve?

Results

MiniSAT-gp best09 0.93 0.95

Results

Donor: best09

13 delete, 9 replace, 1 copy

Among changes:

3 assertions removed

1 deletion on variable used for statistics

Results

Mainly if and for statements switched off

Decreased iteration count in for loops

Results

MiniSAT-gp bestCIT 0.72 0.87

Results

Donor: bestCIT

1 delete, 1 replace

Among changes:

1 assertion deletion

1 replace operation triggers 95% of donor code

Results

MiniSAT-gp best09+bestCIT 0.94 0.96

Results

Donor: best09+bestCIT

Among changes:

5 assertions removed

4 semantically equivalent replacements

3 operations used for statistics removed

∼ half of the mutations remove dead code

Results

MiniSAT-gp best09+bestCIT 0.94 0.96

MiniSAT-gp-combined best09+bestCIT 0.54 0.83

Results

Combining results:

56 out of 100 mutations used

Among changes:

8 assertion removed

95% of the bestCIT donor code executed

Conclusions

Introduced multi-donor software transplantation

Used genetic improvement as means to specialise software

Achieved 17% runtime improvement on MiniSAT

for the Combinatorial Interaction Testing domain

by combining best individuals

GPProgra

msProgra

msMiniSatImprov

Non-functional property Test

FitneTest

Sensitivity Analysis

Justyna Petke, Mark Harman, William B. Langdon and Westley WeimerUsing Genetic Improvement & Code Transplants to Specialise a C++ programto a Problem Class (EuroGP’14)

Multi-doner transplantSpecialized for CIT

17% faster

MiniSat

GECCO Humie

silver medal

Inter version transplantation

Bowtie2

GPProgra

msProgra

msBowtie

FitneTest

Genetic Improvement of Programs

W. B. Langdon and M. HarmanOptimising Existing Software with Genetic Programming. TEC 2015

70 times faster30+ interventions

HC clean up: 7slight semantic improvement

Cuda GPProgra

msProgra

msCuda

Improv

FitneTest

Genetic Improvement of Programs

W. B. Langdon and M. HarmanGenetically Improved CUDA C++ Software, EuroGP 2014

7 times fasterupdated for new hardware

automated updating

FitneTest

Memory speed trade offs System

malloc

System

optimisedmalloc

Fan Wu, Westley Weimer, Mark Harman, Yue Jia and Jens Krinke Deep Parameter OptimisationConference on Genetic and Evolutionary Computation (GECCO 2015)

Improve execution time by 12% or achieve a 21% memory consumption reduction

FitneTest

Reducing energy consumption

Ensemble

AProVE

MiniSatCIT

MiniSat

MiniSatEnsemble

AProVE

Improved MiniSatCIT

Improved MiniSat

Bobby R. Bruce Justyna Petke Mark HarmanReducing Energy Consumption Using Genetic ImprovementConference on Genetic and Evolutionary Computation (GECCO 2015)

Energy consumption can be reduced by as much as 25%

FitneTest

Grow and graft new functionality

FitneTest

Sensitivity Feature

Grow Graft

HumanKnowledge Feature

Host System

Mark Harman, Yue Jia and Bill Langdon, Babel Pidgin: SBSE can grow and graft entirely new functionality into a real world system Symposium on Search-Based Software Engineering SSBSE 2014. (Challenge track)Chall

enge T

FitneTest

Real world cross system transplantation

Earl T. Barr, Mark Harman, Yue Jia, Alexandru Marginean, and Justyna Petke Automated Software Transplantation (ISSTA 2015)

featureHost’

featureSuccessfully autotransplanted new functionality and passed all regression tests for 12 out of 15 real world systems

Automated Software TransplantationE.T. Barr, M. Harman, Y. Jia, A. Marginean & J. Petke

ACM Distinguished Paper Award at ISSTA 2015

coverage in

article in

2647 shares of

Video Player

Start from scratch

Why Autotransplantation?Check open

source repositories Why not handle H.264?

~100 players

Human Organ Transplantation

Automated Software Transplantation

OrganOrgan

Organ Test Suite

Manual Work:

Organ Entry

Organ’s Test Suite

Implantation Point

μTransHost

Stage 1: Static Analysis

Host Beneficiary

Stage 2: Genetic

Programming

Stage 3: Organ

Implantation

Organ Test Suite

Implantation Point

Organ Entry

Stage 1 — Static Analysis Donor

OEENTRY

VeinOrgan

Matching Table

Dependency Graph

Implantation Point

Stm: x = 10; -> Decl: int x;Donor: int X -> Host: int A, B, C

Stage 2 — GPS1 S2 S3 S4 S5 … Sn

Matching Table

V3H V4H

Donor Variable ID

Host Variable ID (set)

V1H V2H

Individual

V1D V1H

V2D V4H

S1 S7 S73

M1:M2:

…Genetic Programming

Algorithm 1 Generate the initial population P ; the functionchoose returns an element from a set uniformly at random.Input V , the organ vein; SD, the donor symbol table; OM , the host

type-to-variable map; Sp, the size of population; v, statements inindividual; m, mappings in individual.

1: P := ∅2: for i := 1 to Sp do3: m, v := ∅, ∅4: for all sd ∈ SD do5: sh := choose(OM [sd])6: m := m ∪ {sd → sh}7: v := { choose(V ) }8: P := P ∪ {(m, v)}9: return P

variables used in donor at LO. For each individual, Alg. 1 firstuniformly selects a type compatible binding from the host’svariables in scope at the implantation point to each of theorgan’s parameters. We then uniformly select one statementfrom the organ, including its vein, and add it to the individual.The GP system records which statements have been selectedand favours statements that have not yet been selected.

Search Operators During GP, µTrans applies crossoverwith a probability of 0.5. We define two custom, crossoveroperators: fixed-two-points and uniform crossover. The fixed-two-points crossover is the standard fixed-point operator sepa-rately applied to the organ’s map from host variables to organparameters and the statement vector, restricted to each vec-tor’s centre point. The uniform crossover operator producesonly one offspring, whose host to organ map is the crossover ofits parents’ and whose V and O statements are the union of itsparents. The use of union here is novel. Initially, we used con-ventional fixed-point crossover on organ and vein statementsvectors, but convergence was too slow. Adopting union spedconvergence, as desired. Fig. 4 shows an example of applyingthe crossover operators on the two individuals on the left.After crossover, one of the two mutation operators is ap-

plied with a probability of 0.5. The first operator uniformlyreplaces a binding in the organ’s map from host variablesto its parameters with a type compatible alternative. Inour running example, say an individual currently maps thehost variable curs to its N_init parameter. Since curs isnot a valid array length in idct, the individual fails theorgan test suite. Say the remap operator chooses to remapN_init. Since its type is int, the remap operator selects anew variable from among the int variables in scope at theinsertion point, which include ‘hit_eof, curs, tos, length,. . . ’ . The correct mapping is N_list to length; if the remapoperator selects it, the resulting individual will be more fit.

The second operator mutates the statements of the organ.First, it uniformly picks t, an offset into the organ’s statementlist. When adding or replacing, it first uniformly selects aindex into the over-organ’s statement array. To add, it insertsthe selected statement at t in the organ’s statement list; toreplace, it overwrites the statement at t with the selectedstatement. In essence, the over-organ defines a large set ofaddition and replacement operations, one for each uniquestatement, weighted by the frequency of that statement’sappearance in the over-organ. Fig. 5 shows an example ofapplying µTrans’s mutation operators.

At each generation, we select top 10% most fit individuals(i.e. elitism) and insert them into the new generation. Weuse tournament selection to select 60% of the population forreproduction. Parents must be compilable; if the proportionof possible parents is less than 60% of the population, Alg. 1generates new individuals. At the end of evolution, an organ

that passes all the tests is selected uniformly at random andinserted into the host at Hl.

Fitness Function Let IC be the set of individuals thatcan be compiled. Let T be the set of unit tests used in GP,TXi and TPi be the set of non-crashed tests and passed testsfor the individual i respectively. Our fitness function follows:

fitness(i) =

!13 (1 +

|TXi||T | + |TPi|

|T | ) i ∈ IC

0 i /∈ IC(1)

For the autotransplantation goal, a viable candidate must,at a minimum, compile. At the other extreme, a successfulcandidate passes all of the TO

D , the developer-provided testsuite that defines the functionality we seek to transplant.These poles form a continuum. In between fall those individ-uals who execute tests to termination, even if they fail. Ourfitness function therefore contains three equally-weightedfitness components. The first checks whether the individualcompiles properly. The second rewards an individual forexecuting test cases to termination without crashing and lastrewards an individual for passing tests in TO

Implementation Implemented in TXL and C, µScalpelrealizes µTrans and comprises 28k SLoCs, of which 16k isTXL [17], and 12k is C code. µScalpel inherits the limita-tions of TXL, such as its stack limit which precludes parsinglarge programs and its default C grammar’s inability to prop-erly handle preprocessor directives. As an optimisation weinline all the function calls in the organ. Inlining eases slicereduction, eliminating unneeded parameters, returns andaliasing. For the construction of the call graphs, we use GNUcflow, and inherit its limitations related to function pointers.

5. EMPIRICAL STUDYThis section explains the subjects, test suites, and research

questions we address in our empirical evaluation of automatedcode transplantation as realized in our tool, µScalpel.

Subjects We transplant code for five donors into three hosts.We used the following criteria to choose these programs. First,they had to be written in C, because µScalpel currentlyoperates only on C programs. Second, they had to be popularreal-world programs people use. Third, they had to be diverse.Fourth, the host is the system we seek to augment, so it had tobe large and complex to present a significant transplantationchallenge, while, fifth, the organ we transplant could comefrom anywhere, so donors had to reflect a wide range of sizes.To meet these constraints, we perused GitHub, SourceForge,and GNU Savannah in August 2014, restricting our attentionto popular C projects in different application domains.

Presented in Tab. 1, our donors include the audio stream-ing client IDCT, the simple archive utility MYTAR, GNUCflow (which extracts call graphs from C source code), Web-server3 (which handles HTTP requests), the command lineencryption utility TuxCrypt, and the H.264 codec x264. Ourhosts include Pidgin, GNU Cflow (which we use as both adonor and a host), SOX, a cross-platform command line au-dio processing utility, and VLC, a media player. We use x264and VLC in our case study in Sec. 7; we use the rest in Sec. 6.These programs are diverse: their application domains

span chat, static analysis, sound processing, audio streaming,archiving, encryption, and a web server. The donors vary insize from 0.4–63k SLoC and the hosts are large, all greater3https://github.com/Hepia/webserver.

Weak Proxies: Does it execute test cases without

crashing?

Does it compile?Strong Proxies: Does it produce the correct output?

Do we break the initial functionality?

Have we really added new functionality?

How about the computational effort?Is autotransplantation useful?

Research QuestionsRegression TestsAcceptance Tests

Research QuestionsDo we break the initial functionality?

How about the computational effort? Is autotransplantation useful?

Have we really added new functionality?

Empirical Study

15 Transplantations 300 Runs 5 Donors 3 Hosts

Case Study:

H.264 Encoding Transplantation

ValidationRegression

Augmented Regression

Donor Acceptance

Acceptance Tests

Manual Validation

Host Beneficiary

Subjects

Minimal size: 0.4k

Max size: 422k

Average Donor:16k

Average Host: 213k

Subjects Type Size KLOC

Idct Donor 2.3Mytar Donor 0.4Cflow Donor 25

Webserver Donor 1.7TuxCrypt Donor 2.7

Pidgin Host 363Cflow Host 25SoX Host 43

Case Studyx264 Donor 63VLC Host 422

Feedback-Controlled Random TestGeneration

Kohsuke Yatoh1∗, Kazunori Sakamoto2, Fuyuki Ishikawa2, Shinichi Honiden12

1University of Tokyo, Japan,2National Institute of Informatics, Japan

{k-yatoh, exkazuu, f-ishikawa, honiden}@nii.ac.jp

ABSTRACTFeedback-directed random test generation is a widely usedtechnique to generate random method sequences. It lever-ages feedback to guide generation. However, the validity offeedback guidance has not been challenged yet. In this pa-per, we investigate the characteristics of feedback-directedrandom test generation and propose a method that exploitsthe obtained knowledge that excessive feedback limits thediversity of tests. First, we show that the feedback loopof feedback-directed generation algorithm is a positive feed-back loop and amplifies the bias that emerges in the candi-date value pool. This over-directs the generation and limitsthe diversity of generated tests. Thus, limiting the amountof feedback can improve diversity and effectiveness of gener-ated tests. Second, we propose a method named feedback-controlled random test generation, which aggressively con-trols the feedback in order to promote diversity of generatedtests. Experiments on eight different, real-world applicationlibraries indicate that our method increases branch cover-age by 78% to 204% over the original feedback-directed al-gorithm on large-scale utility libraries.

Categories and Subject DescriptorsD.2.5 [Software Engineering]: Testing and Debugging—Testing tools

General TermsAlgorithms, Reliability, Verification

KeywordsRandom testing, Test generation, Diversity

∗The author is currently affiliated with Google Inc., Japan,and can be reached at kyatoh@google.com.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ISSTA’15 , July 12–17, 2015, Baltimore, MD, USACopyright 2015 ACM 978-1-4503-3620-8/15/07 ...$15.00.

1. INTRODUCTIONFeedback-directed random testing [17] is a promising tech-

nique to automatically generate software tests. The tech-nique can create random method sequences using publicmethods from the classes of a system-under-test (SUT). Itis a general and test oracle independent technique to gen-erate software tests. Due to its generality and flexibility,many researchers have used feedback-directed random test-ing. Some researchers leveraged feedback-directed randomtesting as a part of their proposed methods [5, 25]. Othersused feedback-directed random testing to prove their the-ories on random testing [11, 12]. There is an interestingstudy that mined SUT specifications by analyzing the dy-namic behavior of SUT observed during feedback-directedrandom testing [18]. In addition, feedback-directed randomtesting has already been adopted by industries and under-gone intensive use [19].Despite its importance, characteristics of feedback-directed

random testing have seldom been studied. To the best ofour knowledge, some studies have proposed extensions tofeedback-directed random testing [14, 27], but they failedto analyze the nature of feedback-directed random testing.Specifically, the idea of feedback guidance had never beenchallenged. In this paper we investigate characteristics offeedback-directed random testing by using a model SUT andpropose a new technique that exploits the obtained knowl-edge that excessive feedback over-directs generation, ampli-fies bias, and limits the diversity of generated tests.We address two research questions in this paper.

RQ1: Why does the test effectiveness stop increasing atdifferent points depending on random seeds?

RQ2: Can our proposed technique lessen the dependencyon random seeds and improve the overall performanceof test generation?

The resulting test effectiveness of feedback-directed randomtesting should differ because of its randomness. However,the observed difference is much larger than expected. Forexample, the interquartile range marks 10% in our prelim-inary experiment on the model SUT. This spoils the credi-bility of feedback-directed random testing.There are three contributions in this paper.

• We hypothesize that feedback guidance over-directs thegeneration and limits the diversity of generated testsand show that both average score and variance of testeffectiveness improve by limiting the amount of feed-back.

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from Permissions@acm.org.Copyright is held by the owner/author(s). Publication rights licensed to ACM.

ISSTA’15, July 13–17, 2015, Baltimore, MD, USAACM. 978-1-4503-3620-8/15/07http://dx.doi.org/10.1145/2771783.2771805

Consist

ent *Complete *Well D

ocumented*Easyt

euse* *

Evaluated

*ISSTA*Ar

tifact *

Experimental Methodology and Setup

μSCALPEL

Implantation Point

OEOrgan Test Suite

Host Beneficiary

Implantation Point

64 bit Ubuntu 14.10 16 GB RAM 8 threads

Donor Host All Passed Regression Regression++ AcceptanceIdct Pidgin 16 20 17 16

Mytar Pidgin 16 20 18 20Web Pidgin 0 20 0 18Cflow Pidgin 15 20 15 16Tux Pidgin 15 20 17 16Idct Cflow 16 17 16 16

Mytar Cflow 17 17 17 20Web Cflow 0 0 0 17Cflow Cflow 20 20 20 20Tux Cflow 14 15 14 16Idct SoX 15 18 17 16

Mytar SoX 17 17 17 20Web SoX 0 0 0 17Cflow SoX 14 16 15 14Tux SoX 13 13 13 14

TOTAL 188/300 233/300 196/300 256/300

Empirical Study Feedback-Controlled Random TestGeneration

Consist

ocumented*Easyt

euse* *

Evaluated

*ISSTA*Ar

tifact *

in 12 out of 15 experiments we successfully autotransplanted

new functionality

Execution Time (minutes)Donor HostIdct Pidgin 5 7 97

Mytar Pidgin 3 1 65Web Pidgin 8 5 160Cflow Pidgin 58 16 1151Tux Pidgin 29 10 574Idct Cflow 3 5 59

Mytar Cflow 3 1 53Web Cflow 5 2 102Cflow Cflow 44 9 872Tux Cflow 31 11 623Idct SoX 12 17 233

Mytar SoX 3 1 60Web SoX 7 3 132Cflow SoX 89 53 74Tux SoX 34 13 94

Empirical Study

Average

334 (min)

Std. Dev. Total

72 (hours)10 (Average)

Consist

ocumented*Easyt

euse* *

Evaluated

*ISSTA*Ar

tifact *

Case Study

Transplant Time & Test SuitesTime (hours) Regression Regression++ Acceptance

H.264 26 100% 100% 100%

Consist

ocumented*Easyt

euse* *

Evaluated

*ISSTA*Ar

tifact *

within 26 hours performed a taskthat took developers

an avg of 20 days of elapsed time

Automated Software Transplantation

Manual Work:

Organ Entry

Implantation Point

Alexandru Marginean — Automated Software Transplantation

μTrans

Stage 1: Static Analysis

Host Beneficiary

Stage 2: Genetic

Programming

Stage 3: Organ

Implantation

Validation

Regression Tests

Augmented Regression

Host Beneficiary

Donor Acceptance

Acceptance Tests

Manual Validation

RQ1.b RQ2

* http://crest.cs.ucl.ac.uk/autotransplantation/MuScalpel.html

GI Applications

Bug fixing

* http://dijkstra.cs.virginia.edu/genprog/

* http://people.csail.mit.edu/fanl/

Kali, SPR, ClearView

(from MIT)

and other …Claire Le Goues, Stephanie Forrest, Westley Weimer:

Current challenges in automatic software repair. Software Quality Journal 21(3): 421-443 (2013)

GI Applications

Bug fixing

Improving energy consumption

Porting old code to new hardware

Grafting new functionality into an existing system

Specialising software for a particular problem class

What if fitness is expensive to compute ?

GI4GI: Improving Genetic Improvement Fitness FunctionsMark Harman & Justyna Petke(Genetic Improvement Workshop 2015)

GI4GI: Energy Optimisation Example

many factors affecting energy consumption, including:

screen behaviour

memory access

device communications

CPU utilisation

a hardware-dependent linear energy model for GI:

Post-compiler software optimization for reducing energy (ASPLOS’14) Schulte et al.

Use GI to evolve a fitness function f for energy consumption.

Use f to improve energy consumption of software.

CREST Justyna Petke

GI Growth

Growing Area1st International Genetic Improvement Workshopat GECCO 2015, Madrid, Spainwww.geneticimprovementofsoftware.com

GI Growth

Special Issueon GI

Special Session on GI *http://www.wcci2016.org/

Conclusions

we can optimise these

Summary

Search Based Optimisation

Software Engineering

S B S E

Genetic Improvement

CREST Justyna Petke

Research Opportunities

CREST Justyna Petke

Contact me if you want to visit CREST:

j.petke at ucl.ac.uk

Centre for Research on Evolution, Search and TestingUniversity College London

CREST Justyna Petke

20 mins walk

NationalGallery

Nelson’s Column

Eros RoyalCourts of Justice

St. Paul’s

Tate ModernGlobe

Theatre

Covent Garden Market

WestminsterAbbey

House of Parliament

London Eye

BritishMuseum

Madame Tussaud’sSherlock Holmes

Museum

Marble Arch

National History Museum

CREST Justyna Petke

COWsCREST Open Workshop

Roughly one per month

Discussion based

Recorded and archivedhttp://crest.cs.ucl.ac.uk/cow/

CREST Justyna Petke

http://crest.cs.ucl.ac.uk/cow/

CREST Justyna Petke

#Total Registrations 1512 #Unique Attendees 667 #Unique Institutions 244 #Countries 43 #Talks 421

(Last updated on November 4, 2015)

CREST Justyna Petke

CREST Open Workshop (COW)

CREST Justyna Petke

Genetic Improvement25-26 January 2016

45th COW

CREST Justyna Petke

Dynamic Adaptive Search Based Software

Engineering

EPSRCGrant

Stirling

Birmingham

Summary

Search Based Optimisation

Software Engineering

S B S E

Genetic Improvement

COWsVisitor SchemeOpen positions

Pictures used with thanks from these sources

Pickering's Harem: [Public domain], via Wikimedia Commons

IBM 026 Card Punch: By Ben Franske (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0-2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

BBC_Micro: [Public domain], via Wikimedia Commons

Programmer: undesarchiv, B 145 Bild-F031434-0006 / Gathmann, Jens / CC-BY-SA [CC-BY-SA-3.0-de (http://creativecommons.org/licenses/by-sa/3.0/de/deed.en)], via Wikimedia Commons

IBM PC: By Boffy B (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0-2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

IMac: By Matthieu Riegler, Wikimedia Commons [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons

Ada Lovelace: By Alfred Edward Chalon [Public domain], via Wikimedia Commons

genetic improvement - phdopen.mimuw.edu.plphdopen.mimuw.edu.pl/zima15/petke-slides/gi.pdf ·...

Documents

ş İşletmen k -...

Čudesna povest manastira svete petke Đunis.pdf

Το Μέλλον Ξεκινά Τώρα -...

pt1 klasifikasi gi.pdf

glas istre - online izdanje - fet.unipu.hr - gi.pdf ·...

kako je arheološki park u budinjaku zamirisao po...

w.mbyy geoe - mecklenburg county beekeepers … · 1 w.m...

ed l iedelweissde e ss fi i lfinancialacaad...

uva-dare (digital academic repository) structure/function...

1 gold time - the procrastinators redemption partner webinar...

ΜΑΡΓΑΡΙΤΑ...

helyi tanterv©gi.pdf · műveletek elvégzése fejben és...

landdffiillll eccoovverrss:: wwaatteerr baa llaannccee,, …...

pifi 3 3.3 gi.pdf · 2011. 7. 1. · guía para actualizar...

integrated multimodal interaction using normal...

rzemioso, nauka, sztuka - wydział transportu...

fractal first-order partial differential equations ·...

Первенство России...

gi - ...:::club nissan...

perspectivas desde el mundo real - grupo sol...