Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding pipeline applications #9

Draft
wants to merge 324 commits into
base: main
Choose a base branch
from
Draft

Conversation

fairlight1337
Copy link
Contributor

Pipelines consist of multiple directed evolution steps that select candidate programs based on specific criteria. The goal of a pipeline is to achieve a certain, usually complex, behavior. To reach this behavior, programs need to be tailored to evolve different characteristics and traits until they achieve the intended final behavior.

This change fixes minor issues with the VM execution code to make evolution viable, and introduces pipelines example applications.

@fairlight1337 fairlight1337 added the enhancement New feature or request label Feb 28, 2023
@fairlight1337 fairlight1337 self-assigned this Feb 28, 2023
Now it just needs some actual content/functionality
Protected input/output access with mutexes and ensured program candidate
move (instead of copy) where appropriate.
The candidate buffers in the pipeline connection objects were not
protected by mutexes. Since they are used in a multithreading context,
segmentation faults were possible. This change adds the mutex
protection. Also, it changes the previous vector implementation to a
deque one since the buffers are used as real FIFO pipes actually.

Apart from this, inside the Pipeline class, raw pointers were used for
connections in some internal places. This poses a memory leak and access
violation risk, so this was changed to use shared pointers as well.

Tests were updated accordingly.
The metrics functions allow to report current performance statistics for
pipelines and individual pipes (execution count, received inputs, and
sent outputs). The reporting functions have been implemented in the
Pipeline and PipelineManager classes. Proper reporting to the web
frontend is still to be done.

Also, the handling of Pipeline class instances was changed from regular
stack objects to shared pointers to be better able to handle mutex
instances inside them. This also streamlines the overall use of shared
pointers in the software stack.
The metrics calculation likely needs an overhaul, but the signal is
piped through from Pipeline to frontend.

What's wrong at the moment:
* ISO 8601 timestamp formulation is off. The time format looks wrong.
* Number weighting is wrong. The execution counts and processed
candidates are not correct yet and need to be divided by the time
elapsed since reporting.
The issue with the time scaling still persists, but the time string
formulation is good now.
The correct metrics are now reported through the API from backend to
frontend. All numbers are now per second rates for execution count,
inputs received, and outputs sent.
The metrics report was inaccurate (values were divided/averaged too many
times). This fixes it, the metrics are now reported consistently good.
The frontend now properly displays metrics for all hovered pipes.
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 41 Code Smells

49.8% 49.8% Coverage
1.5% 1.5% Duplication

The Maze evaluator does not yet produce candidates. Its evaluation
function needs to be refined further. The initial integration of setting
perception and food level, and getting moves out, is done though.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant