Re: Attributes in Activities/Legs

Description

Hallo Marcel,

Hierzu noch ein paar Dinge.

(1) Leg ist bereits Attributable. Vielleicht erklärt das auch die 7.5% vom Mem?

(2) Wir könnten m.E. von Hand implementieren:

class LegImpl ... {
Attributes attributes = null ;
...
@Override public getAttributes() {
if ( attributes==null ) {
attributes = new Attributes() ;
}
return attributes ;
}
}

Das machen wir vllt. nicht überall, aber wenigstens bei Objekten, die sehr oft instantiiert werden.

Wenn wir das bei "Leg" machen, sollte der mem footprint ja erstmal nach unten gehen. Und dann könnten wir es auch bei Act machen. . Ich finde auf jeden Fall, dass wir es gerade hier brauchen, weil diese Objekte ja keine ID haben.

Danke & viele Grüße

Kai

On 7. Oct 2019, at 09:18, Marcel Rieser <rieser@simunto.com<rieser@simunto.com>> wrote:

Hallo Kai

Danke für die Erläuterungen.

7.5% mem ist natürlich bitter. Finde das allerdings eigentlich etwas unerwartet; vom Design her sollte Attributable den Speicherplatz für 3 Referenzen verbrauchen (seine eigene, plus die zwei auf EMPTY_KEYS und EMPTY_VALUES).

Der ObjectHeader besteht aus 2 Referenzen, bei JVM mit mehr als 32GB sind es somit 4 ObjectPointers mit je 8 Bytes = 32 Bytes. 32 Bytes * 93 Mio. Objekte sind 2.8 GB RAM, verglichen mit insgesamt 36GB an Daten total innerhalb der JVM (noch ohne Garbage-Collection overhead. Insgesamt läuft die Simulation wohl mit -Xmx50g oder 60g, aber auch dann sind es noch immer ca 5% mem). Das Problem ist effektiv die (im Vergleich zu Personen oder Plänen) riesige Anzahl an PlanElementen. Bei grösseren Szenarien mit mehr Agenten wird es tendenziell noch mehr, weil sich diese Anzahl mitskaliert, aber z.B. das Netzwerk und die Facilities gleich gross bleiben.

Der use case hier ist, dass wir freight deliveries (shipments/services) zuordnen wollen. Und der code funktioniert so, dass pro freight Tour ein normaler Agent mit plan elements erzeugt wird, und jeder "service" in eine "Aktivität”.
Wenn aber jetzt eine Person mitbekommen will, ob ihre Lieferung angekommen ist, dann geht das nicht, weil man das nicht zusammen bekommt.

Okay, das wäre also, als ob der PT nicht mit eigenen Agenten unterwegs wäre, sondern im Voraus schaut, wer wann mitfahren möchte, und dann einfach einen “normalen” Agentenplan erzeugt und bei jeder Haltestelle eine normale Aktivität hat und dort in die Attribute reinschreibt, wer (planmässig) ein- und aussteigt.

Entsprechend wäre die Alternative für Freight, einen eigenen Driver-Agenten zu erzeugen, welcher dann bei den entsprechend service-
Activities eigene “DeliveryEvents” erzeugt, wo drin steht, welches Parcel an welche Person zugestellt wurde. Oder ein normaler Agent, aber zusätzlich ein EventHandler der die ActivityStartEvents überprüft und bei Bedarf die Freight-DeliveryEvents basierend auf dem für den Agenten hinterlegten Liefer-Plan erzeugt.

Eigentlich haben wir ja die Events extra so gebaut, dass sie einfach erweiterbar sind und man einfach eigene Arten von Events erzeugen kann. Wenn man nun aber Attributes an die Events dran hängt, dann wirkt das auf mich wie nochmals eine Art zusätzliche Erweiterbarkeit. Oder etwas überspitzt formuliert: Wieso haben wir dann überhaupt noch unterschiedliche Events, und nicht einfach ein Typ von Event, der einfach beliebige Attribute in ein Attributes-Objekt aufnehmen kann?

Viele Grüsse,
Marcel

--------------------------------
Marcel Rieser
Simunto GmbH • www.simunto.com<http://www.simunto.com/> • +41 44 508 5698
Riedgrabenweg 49 • 8050 Zurich • Switzerland

On 6 Oct 2019, at 20:01, Nagel, Kai, Prof. Dr. <nagel@vsp.tu-berlin.de<nagel@vsp.tu-berlin.de>> wrote:

(Gregor siehe "stage activities".)

Hallo Marcel,

Der use case hier ist, dass wir freight deliveries (shipments/services) zuordnen wollen. Und der code funktioniert so, dass pro freight Tour ein normaler Agent mit plan elements erzeugt wird, und jeder "service" in eine "Aktivität".

Wenn aber jetzt eine Person mitbekommen will, ob ihre Lieferung angekommen ist, dann geht das nicht, weil man das nicht zusammen bekommt. Man kann nur schauen, ob es Lieferungen auf dem Link gegeben hat, bekommt aber keine Info, die über das hinaus geht, was eine Activity über sich selbst weiß.

Den Aktivitäten IDs zu geben wäre offenbar eine Alternative, dann könnte man es durch einen lookup herausfinden. Wir wollten aber eigentlich Aktivitäten keine IDs geben. Das mit "attributable" ist eigentlich auch insgesamt eleganter, weil es ja tatsächlich nicht so blöd ist, jeder Activity die zusätzliche "freight information" direkt zuzuordnen.

7.5% mem ist natürlich bitter. Finde das allerdings eigentlich etwas unerwartet; vom Design her sollte Attributable den Speicherplatz für 3 Referenzen verbrauchen (seine eigene, plus die zwei auf EMPTY_KEYS und EMPTY_VALUES). Das ist 3x so viel wie "null", aber dennoch noch nicht uferlos. Machen wir vllt irgendwo anders etwas falsch?

Mit den stage activities ist meinem Verständnis eigentlich fertig. Aber Gregor wartet noch auf irgendeine Antwort von Thibaut, wo Thibaut aber evtl. der Meinung ist, dass er uns diese bereits geschickt hat (in Antwort auf eine vorherige Frage). Ich werde da irgendwann zusammen mit Gregor reinschauen, aber wenn Du es mit ihm klärst, würde mir das helfen.

Vielen Dank und viele Grüße

Kai

On 3. Oct 2019, at 09:44, Marcel Rieser <rieser@simunto.com<rieser@simunto.com>> wrote:

Hallo Kai

In Anlehnung an “MATSIM-976, pass "Attributable" through to events?”:

Was ist ein Use-Case, um Attributes an Activities und Legs dran zu hängen? In meinen Szenarien bin ich da bislang nie darüber gestolpert, weshalb mir da etwas das Verständnis dafür fehlt.

Hintergrund ist auch noch Folgendes: Ich hatte letzte Woche mal für die SBB analysiert, wo in einer Simulation der ganze Speicher verbraucht wird. Dabei fiel mir auf, dass in unserem 10% CH-Szenario mit ca. 1 Mio Agenten und 4 Pläne pro Agent wir insgesamt 93 Mio Activities und Legs haben, und jedes dieser 93 Mio PlanElemente hat ein unbenutztes Attributes-Objekt, was insgesamt 2.8 GB an RAM belegt, was immerhin etwa 7.5% des totalen Speicherverbrauchs der Simulation ausmacht.

Entsprechend bin ich etwas vorsichtig, noch an mehr Orten ein Attributes-Objekt dranzuhängen, insbesondere weil mir eben noch kein Use-Case bekannt ist – aber offensichtlich gibt es solche.

------

Ich habe mir noch überlegt, die Klasse Attributes in ein Interface umzuwandeln, dann könnte man versuchen, eine Art lazy-Implementation zu haben: Activities und Legs haben zuerst mal attributes=null, und getAttributes könnte etwa so aussehen:

public Attributes getAttributes() {
if (this.attributes != null) {
return this.attributes;
}
return new LazyAllocationAttributes(attributes -> this.attributes = attributes);
}

LazyAllocationAttributes würde alle getAttribute()-Anfragen mit null beantworten.
Sollte ein putAttribute() aufgerufen werden, würde es ein neues Attributes-Objekt erzeugen, dieses per übergebenem Lamda-Ausdruck im Attributable-Objekt setzen, und dann darauf das putAttribute-ausführen. Dadurch könnte man sicherstellen, dass das eigentliche Attributes-Objekt erst dann erzeugt wird, wenn auch wirklich etwas gespeichert werden soll. Und davor würde es (ausser dem null-ObjectPointer) kein Speicher belegen.

------

Noch zu den 93 Mio PlanElements: Viele davon sind interaction activities, die eigentlich ja alle Zeitdauer 0 haben und auch sonst weniger Angaben benötigen. Somit könnte man diese eigentlich auch durch Speicher-effizientere Implementationen ersetzen. Das geht dann schon stark in die Richtung von Thibaut’s WayPoints, und hängt vermutlich auch mit den “stage activities” (https://github.com/matsim-org/matsim/pull/653) zusammen. Ich weiss aber nicht, was da der genaue Stand ist. Falls ich da was helfen oder umsetzen kann, lasst es mich bitte wissen. Ich sollte im Oktober und November wieder etwas Zeit haben, um so etwas umzusetzen.

Viele Grüsse,
Marcel

--------------------------------
Marcel Rieser
Simunto GmbH • www.simunto.com<http://www.simunto.com/> • +41 44 508 5698
Riedgrabenweg 49 • 8050 Zurich • Switzerland

======================================================

Clone github.com/matsim-org/matsim-example-project<http://github.com/matsim-org/matsim-example-project> to get started.
Look at github.com/matsim-org/matsim-code-examples<http://github.com/matsim-org/matsim-code-examples> for code examples.
Also see matsim.org/downloads<http://matsim.org/downloads> | matsim.org/docs/tutorials<http://matsim.org/docs/tutorials> | matsim.org/open-scenario-data<http://matsim.org/open-scenario-data> | matsim.org/faq<http://matsim.org/faq> .


www.vsp.tu-berlin.de<http://www.vsp.tu-berlin.de/>
+49 30 314 23308 (phone) +49 30 314 26269 (fax)
postal: TU Berlin Sekr. SG 12, Salzufer 17-19, 10587 Berlin
physical: building SG 4.1, room 305

======================================================

Clone github.com/matsim-org/matsim-example-project<http://github.com/matsim-org/matsim-example-project> to get started.
Look at github.com/matsim-org/matsim-code-examples<http://github.com/matsim-org/matsim-code-examples> for code examples.
Also see matsim.org/downloads<http://matsim.org/downloads> | matsim.org/docs/tutorials<http://matsim.org/docs/tutorials> | matsim.org/open-scenario-data<http://matsim.org/open-scenario-data> | matsim.org/faq<http://matsim.org/faq> .


www.vsp.tu-berlin.de<http://www.vsp.tu-berlin.de>
+49 30 314 23308 (phone) +49 30 314 26269 (fax)
postal: TU Berlin Sekr. SG 12, Salzufer 17-19, 10587 Berlin
physical: building SG 4.1, room 305
[Created via e-mail received from: "Nagel, Kai, Prof. Dr." <nagel@vsp.tu-berlin.de>]

Environment

None

Activity

Show:
Marcel Rieser
October 10, 2019, 7:50 AM

Folgende Implementierung hat ein Problem:

class LegImpl ... {
Attributes attributes = null ;
...
@Override public getAttributes() {
if ( attributes==null ) {
attributes = new Attributes() ;
}
return attributes ;
}
}

Sobald z.B. der Writer aufgerufen wird, macht der ein Leg.getAttributes() um die vielleicht vorhandenen Attribute zu schreiben, und schon wurde das Objekt erzeugt. Deshalb auch mein Vorschlag mit dem LazyAttributes, welches erst dann ein Attributes-Objekt erzeugt und setzt, wenn das erste Attribut mittels putAttribute() gesetzt wird.

Kai Nagel
October 11, 2019, 8:16 AM
Edited

Ah shoot, right, thanks.

BTW: PlanElements have been Attributable since 2016. So besides Leg also Activity in fact is attributable.

Assignee

Gregor Leich

Reporter

Kai Nagel

Labels

None

Priority

Major
Configure