TraceLens is a new user interface and data collector for OpenTelemetry-based systems.Although there are existing tools like Jaeger and Zipkin that offer some visualization capabilities, I wanted a solution that could provide a deeper level of insight.TraceLens is not designed for production environments, but as a debugging tool to help developers better understand the intricacies of their...
Serialization and the concept of the ActorRef. They both go hand in hand.
in Akka/NET, ActorRefs are contextual, they belong to a given ActorSystem.
This means that when they are serialized, the serializer needs to be able to know how to transfer and rebind this context on serialization and deserialization. To make it more complex, ActorRefs can be embedded in other messages. There are a few other primitives also that are contextual and serialized. This limits the options you have in terms of serializers. It also puts a massive tax on the framework in terms of maintenance.
ActorRefs are also "resolved" when deserialized, so the deserializing system has to figure out which actor is targeted. This lookup is slow due to parsing and scanning of actors and their children.
This makes network communication speed suffer _a lot_.
The configuration DSL HOCON is also tightly integrated with the entire infrastructure, making it hard to reason about what is going on and what parts of the config the current piece of code actually sees. Akka/NET also lacks good interception points, its hard to hook into actors and monitor them.
There are just too many moving parts for my own liking. I did blog about some of the problem areas in my POV about a year ago: https://rogerjohansson.blog/2016/03/13/random-things-learned...
So the issues are really both on a performance level and at a maintenance level.
The mindset in Akka.NET have been more "lets build everything ourselves from scratch to match the JVM" and in proto.actor "lets re-use proven tech and glue them together, with minimal code"
e.g. see this CLI tool for managing proto.actor systems live: https://asciinema.org/a/a1b18jiv703e6eog1o2b7domi
You will be able to send messages to actors, connect to remote nodes etc.
There are also very fine-grained interception points allowing us to plug in things like zipkin.io w/o altering how the user writes their code.
Akka.NET is production ready and has a huge community. has commercial support etc. There are however a fair number of design issues that I dislike personally which led me to start Proto.Actor
The .NET implementation of proto.actor is in alpha version right now. We are building and stabilizing the Go version first, which already is used in major production systems.
But that is still more than 8 times slower than GAM.
The reason for Akka.NET (and JVM Akka) having trouble in this area is that every message comes with a sender ActorRef that needs to be resolved. even if the target doesn't touch that ActorRef. The serialization mechanism there is also a lot more complicated.
https://github.com/rogeralsing/gam/issues?q=is%3Aissue+is%3A...
Are there any official standards to help with monitoring service/microservice interactions?I'm thinking as we have things like HATEOAS + HAL for design and representation of resources, shouldn't there also be something to help with tracking interactions?A naive approach to this might be to just add a few standardized log entries into something like ElasticSearch.I am not talking about...
That is a strange comment, ofc the Erlang VM is not the single best VM that will ever be created. Some day, someone will create a better one.
But I do agree, GA's have limited use.
That code uses real crossover and a large population in order to crack black boxed formulas.
Some clarifications from my part here, 4 years after the post was released:
1) No this does not qualify as a true GA/GP. by definition GP need to have an computational AST, EvoLisa has an declarative AST. There is also no cross over in play here. (see 3* for explatation on this)
2) Hill climbing or not? According to wikipedia, Hill climbing only changes _one_ value of the problem solving vector per generation. ""At each iteration, hill climbing will adjust a single element in X and determine whether the change improves the value of f(X)""
So it doesn't quite fit the hill climbing definition either, also the DNA/vector is of dynamic size in EvoLisa while Hill climbing AFAIK uses fixed size vectors (?)
3) Why wasn't a larger population used and why no cross over?
This is the part that most of you get wrong, increasing the population size and adding cross over will NOT benefit this specific problem.
The polygons are semi transparend and overlap, thus, adding/removing polygons will have a high impact on the fitness level, in pretty much every case in the wrong direction.
Let's use words as an example here:
organism1: "The Mona Lisa" organism2: "La Gioconda"
Both may have similar fitness level, but completely different sets of polygons (letters in this naive example)
combining those will very very rarely yeild an improvement.
e.g. child(result of org1 and org2) "Lae Mocondisa" that is complete nonsense and the fitness level falls back to pretty much random levels.
Thus, you can just as well use pure mutation instead of cross over here.
If the problem instead had been based on genes that paint individual parts, e.g. a gene for the face, a gene for the background, a gene for the body etc.
THEN it would have made sense to use crossover. In such case it would be possible to combine a good face gene with a good background gene and the fitness level would improve.
However, due to the nature of this specific problem where the polygons span the entire image, this is not effective.
And if crossover is not benefitial, then a larger population gets less interesting also since you cannot combine them.
Increasing the population will only make more separate individuals compete against eachother with no additative effect in any way.
see it like this.
If we have one sprinter running 100meters, if he might complete the run in about 10 sec.
If we add 1000 sprinters to the population, each of them might complete the run in about 10 sec each.
Thus, the problem is not solved any faster by adding more individuals here. Also, by increasing the population size, there will be much more data to evaluate for each generation, so even if we can bring down the number of generations needed to solve the problem, the actual real world time to complete it would increase due to evaluation logic.
Anyway, nice to see that people still find this somewhat interesting. It was pretty much a single evening hack back 4 years ago..
//Roger