boxing/unboxing
Übersicht
BlitzMax, BlitzMax NG Beginners-Corner
BBPro2Betreff: boxing/unboxing |
 Mi, Nov 25, 2009 22:00Antworten mit Zitat 
|
|
|---|---|---|
|
hallo,
hab grad ein bißchen mit bmax rumgespielt und musste traurigerweise feststellen dass bmax offensichtlich nicht über primitve type (un)boxing verfügt, sprich: ich kann keine int, etc zu listen hinzufügen, da es keine Objekte, sondern primitive typen sind. in java und co wird dies sehr oft implizit vom compiler übernommen indem er primitve typen, die gerade als objekt behandelt werden müssen, in ein einfaches objekt konvertiert, welches einfach nur den wert des primitiven typen hat. also int 3 würde implizit z.b. zu einem objekt Integer mit einem feld value, welches den wert 3 annimmt. (-> boxing) außerdem wird das ganze später implizit wieder rückgängig gemacht, so dass man auch mit Integer-Objekten rechnen kann als wären es int. (-> unboxing) dies geht natürlich ein wenig auf kosten der laufzeit, aber zugunsten des komfortablen programmierens. ich habs dann einfach so gemacht dass ich genau dieses schema selbst implementiert habe.. das problem ist: komfortabel ist das nicht! ständig bla.value etc einzugeben ist durchaus nervig. gibt es alternativen in bmax oder geht es nur so wie ich es gemacht habe ? vielen dank! |
||
|
BladeRunnerModerator |
Mi, Nov 25, 2009 22:03 Antworten mit Zitat
|
|---|---|---|
| Du wirst es mit deinem Workaround tun müssen, da in der Tat die Zahlenwerte in Max Primitive sind,keine Objekte. anders sieht es mit Strings/Arrays etc aus. | ||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
BBPro2 |
Mi, Nov 25, 2009 22:12 Antworten mit Zitat
|
|
|---|---|---|
|
hmpf gibt es eine offizelle adresse oder forum indem man verbesserungsvorschläge für neuere versionen posten kann ?
boxing gehört imo zu den wichtigstens (ok übertrieben  ) dingen einer oop-sprache
ich mein dass ints keine objekte sind ist ja ok (das sind sie soweit ich weiß nirgends), aber dass man sie explizit boxen muss is doch arg ärgerlich, gerade bei größeren projekten. |
||
|
|
BladeRunnerModerator |
Mi, Nov 25, 2009 22:25 Antworten mit Zitat
|
|---|---|---|
| Klar: bb.com. Das ist immerhin die Seite des Entwicklers. | ||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
AvaGast |
Mi, Nov 25, 2009 22:40 Antworten mit Zitat |
|
|---|---|---|
| Ansonsten kannst Du es wie gesagt auch mit Strings und/oder Ein-Feld-Arrays lösen. Das kann je nach Aufgabe gegebenfalls etwas komfortabler sein, als mit Objekten. Ich mische das bei meinen Projekten auch immer je nach Bedarf. Wobei man das ansich ja eh nur für Listen und Maps benötigt. Und auch dort *denke ich* eher nur sehr selten und in Maps sicherlich noch öfter, als in Listen, die sich für gewöhnlich recht gut durch ein Array "ersetzen" lassen, wo diese Problematik dann nicht auftritt. | ||
BBPro2 |
Do, Nov 26, 2009 0:29 Antworten mit Zitat
|
|
|---|---|---|
|
naja arrays sind halt statisch, listen dynamisch.
da bei mir normalerweise quasi ALLES dynamisch ist brauche ich nahezu niemals arrays sondern immer nur listen. einfeld arrays und strings mag ich auch nicht unbedingt.. isn bißchen zu viel patchwork und "bug"-using außerdem ist die laufzeit nur noch schwer zu kontrollieren da ständig interne casts stattfinden die ich gar nicht so "merke" allerdings habe ich mich gerade entschlossen (und gewundert warum zum teufel ich nicht vorher drauf kam) mir meine eigene listen klasse zu schreiben, welche beim adden und getten automatisch boxing und unboxing betreibt vorteil ist dass ich mir dann sogar noch aussuchen darf auf welche listen art ich zurück greifen möchte single/double linked list, array list und was es nich noch so alles gibt... is natürlich erheblich perfomanter, wenn ich mir die art liste baue, die zu meinem projekt am besten passt
gibt es in bmax die möglichkeit der überladung ? also method add (i: int) (...) method add (f: float) etc. ? so könnte ich für jeden typ eine eigene boxing klasse schreiben und strings etc einfach direkt adden allerdings finde ich immernoch dass dies eignetlich die aufgabe des compilers sein sollte und werde einfach ma ne mail schreiben, vlt hab ich ja glück und man "hört" mich^^ |
||
|
DaysShadow |
Do, Nov 26, 2009 1:05 Antworten mit Zitat
|
|---|---|---|
|
Nur wegen der Überladung: Nein, leider nicht.
MfG DaysShadow |
||
| Blessed is the mind too small for doubt | ||
BBPro2 |
Do, Nov 26, 2009 1:09 Antworten mit Zitat
|
|
|---|---|---|
| ouch | ||
AvaGast |
Do, Nov 26, 2009 2:51 Antworten mit Zitat |
|
|---|---|---|
|
Zitat: naja arrays sind halt statisch, listen dynamisch.
da bei mir normalerweise quasi ALLES dynamisch ist brauche ich nahezu niemals arrays sondern immer nur listen. Wenn Du ne Ahnung hättest, wie ich mit meinen Arrays rumhantiere, würdest Du vom Glauben abfallen ... 
|
||
BBPro2 |
Do, Nov 26, 2009 3:14 Antworten mit Zitat
|
|
|---|---|---|
|
wie hantierst du denn mit ihnen rum ?
das einzige was mir zu emulierten dynamischen arrays einfällt ist halt die typische arrayList implementierung. und die ist grausam langsam wenn man oft und viele elemente entfernt/hinzufügt. und alles was nicht dynamisch ist ist wie gesagt für mich keine alternative. und ein array so groß machen dass es vermutlich nie größer werden muss weil man gleich von vornherein den ram vollhaut mit dim var[9999999] obv auch nicht
ich brauche ne gute mischung aus laufzeit und speicherverbrauch allerdings mit schwerpunkt auf gute laufzeit. von nem großen ram darf man mittlerweile bei den meisten endbenutzern ausgehen (also sagen wir ma so 512mb effektiven speicher sollte man schon voraussetzen können und bei bmax anwendungen wird das selten gesprengt werden denke ich) |
||
Dreamora |
Do, Nov 26, 2009 5:49 Antworten mit Zitat
|
|
|---|---|---|
|
Arrays sind extrem schnell wenn man begriffen hat wie man mit Arrays die wachsen und schrumpfen müssen während ihrer Nutzung korrekt umgeht.
Das schlimmste und mit abstand dümmste (gehört zum mit dümmsten was man überhaupt machen kann und das schon ohne das man sich in einer managed sprache befindet) das man machen kann ist die ganze zeit slicen. Das ist garantiert das es sterben wird. Wenn man sich allerding an totale Basics der Algorithmik hält, nämlich Arrays in ihrer Grösse verdoppeln wenn man mehr elemente braucht als man hat und sie zu schrumpfen wenn man weniger als x * Elemente (x < 0.5) benötigt, dann werden Arrays extrem schnell defakto. Auch sollten sie beim Grundinit eine realistische Grösse für ihre verwendung haben. Wegen deinem Init: 1. Wird dim in BM nimmer benutzt (BM = Strict / SuperStrict steht oben in der datei), das ist ein Blitz3D / Blitz+ ding 2. Wenn du soviele objekte hast und ständig grössere mengen erzeugst und wieder killst wirst du so oder so vom GarbageCollector freundliche grüsse bekommen wenn er abröchelt
|
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
BBPro2 |
Do, Nov 26, 2009 19:43 Antworten mit Zitat
|
|
|---|---|---|
|
naja also
1. sollte der compiler es verkraften, wenn ich objekte erstelle und wieder lösche
2. heißt es ja nicht dass ich sie tatsächlich lösche nur weil ich sie aus einem array entferne. 3. das mit dim weiß ich, hatte ich in der eile nur vergessen, da ich jahre lang blitzbasic benutzt habe und erst seit 2 tagen bmax benutze  , trotzdem danke für den hinweis
änder glaub ich aber nix, is nur syntax. sind weiterhin arrays. das mit dem verdoppeln etc is ja standard - das meinte ich mit normaler implementierung von ArrayListen schnell sind sie dennoch nicht imo amortisierte kosten sind vielleicht ok, aber lags wenn ich grad 64k elemente in eine neue liste haue die dann 128k groß ist nerven schon
bei tatsächlich dynamischen listen (und nicht amortisiert dynamischen quasi - kA wie ich das nennen soll^^) wie linked lists entsteht das problem nicht so lange ich keine gute laufzeit beim auslesen einzelner, mittiger elemente brauche, sind linked lists effizienter. und die brauche ich nicht - denn sonst verwende ich arrays
würde mich trotzdem interessieren, was ava meinte - mit der standardimplementierung kann ich aber eher nichts anfangen danke |
||
Dreamora |
Do, Nov 26, 2009 21:49 Antworten mit Zitat
|
|
|---|---|---|
|
So lange du keinen expliziten Zugriff brauchst sind Linked Listen am schnellsten, ja.
Aber deswegen kann man nicht prinzipiell Arrays verteufeln, darum gings mir eigentlich. Arrays sind immer wenn man nicht auf expliziten Zugriff verzichten kann (also eigentlich immer wenn man mehr als einen "Referenzen-Halter" benötigt) erheblich stärker als listen. Wegen dem 64k auf 128k: Wenn man keine Indices braucht, ist es klar unnötige Zeitverschwendung. Aber ansonsten: Da der jump einmal passiert nicht einmal pro Frame, sollte das eigentlich kein Problem sein im Normalfall. Auch dauert es ausserhalb der Debug version effektiv nicht wirklich lange. Im Debug Mode ist das ganze eine andere Geschichte wegen dem massiven Overhead von Debug auf Loops (liegt im tausender Prozentbereich) |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
Casiopaya |
Mo, Nov 30, 2009 23:24 Antworten mit Zitat
|
|---|---|---|
|
Dreamora hat Folgendes geschrieben: So lange du keinen expliziten Zugriff brauchst sind Linked Listen am schnellsten, ja.
Linked Lists sollen am schnellsten sein? Bei der Std. Array Verdoppelung/Halbierungs-Methode treten die Sprünge nur sehr selten auf (theor. O(log(n)) mit n = Zugriffsanzahl, egal ob hinzufügen oder entfernen, im Average-Case im Bereich 1 * log(n)). Das Zugreifen auf einen 1-dimensionalen Array-Index ist so mit das schnellste was man überhaupt machen kann, das Verfolgen von Referenzen dauert wesentlich länger (und benötigt zusätzliche Programmlogik). Als Alternativen könntest noch Hashtabellen verwenden (lohnt sich bei schnellem und rel. eindeutigem Hashwert, bei 'potentiell' sehr vielen Einträgen (einfügen und löschen O(log(n)), im Average-Case sehr nah an O(n)). Die Hashtabellen-Größe kann man auch dynamisch erweitern, braucht aber dann ziemlich lange, weil evtl. viele Einträge verschoben werden müssen. Auch noch: Arrays mit Delete-Flag. Lohnt sich bei extrem vielen Schreib und Lösch-Aktionen. Falls eine Freispeicherliste mitgeführt wird geht Löschen und Schreiben in O(n). Linked Lists würd ich mir echt überlegen, ich bin mir recht sicher, dass ich (und viele weitere hier) sofort eine performantere Array-Variante liefern können, wenn du die LinkedList zeigst. |
||
BBPro2 |
Mo, Nov 30, 2009 23:50 Antworten mit Zitat
|
|
|---|---|---|
|
du zitierst es aber du liest es nicht wies scheint...
"So lange du keinen expliziten Zugriff brauchst sind Linked Listen am schnellsten, ja. " genau das ist der punkt. unter dieser bedingung geht mit linked lists alles in O(1) (und zwar echt O(1), nicht amortisiert) wie willst du das toppen ??? sie verkümmern so zwar zu einer queue bzw stack je nach implementierung, aber genau das war ja die voraussetzung. |
||
Dreamora |
Di, Dez 01, 2009 1:32 Antworten mit Zitat
|
|
|---|---|---|
Da habe ich nichts dagegen gesagt wie du ja selbst zitierst 
Jedoch gibt es andere die dazu ähnliche Probleme haben und deswegen dein Posting finden, aber halt eben mehr brauchen und die sollen ja auch Hilfe finden können weswegen es wichtig war auf dein anti-array Posting zu reagieren um es in den richtigen Kontext zu bewegen, weil sonst ein total falsches Bild entsteht. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
|
Casiopaya |
Di, Dez 01, 2009 18:28 Antworten mit Zitat
|
|---|---|---|
|
BBPro2 hat Folgendes geschrieben: d
unter dieser bedingung geht mit linked lists alles in O(1) (und zwar echt O(1), nicht amortisiert) wie willst du das toppen ??? sie verkümmern so zwar zu einer queue bzw stack je nach implementierung, aber genau das war ja die voraussetzung. Jo, ich denk Dreamore hat das wichtigste schon gesagt, aber der Punkt ist: Ein Array-Zugriff geht auch in O(1). Und das 'c' ist in diesem Fall wesentlich kleiner, da du nur die Array-Referenz vom Compiler 'auflösen' und nicht "manuell" die Liste entlang laufen musst. (Wie gesagt, das Abgreifen eines 1D-Array Index ist nur das Addieren einer Zahl auf eine Speicheradresse). Wenn wir von Performance eines Array-Zugriffs reden wird das Verfolgen und Neusetzen eines Zeigers tatsächlich eine nicht unwesentliche Komponente der Gesamtlaufzeit. Probiers in ner Schleife aus. (Natürlich kann es nach wie vor sein, dass der Rest des Programm 1.000.000 Mal länger dauert als jeglicher Array-oder listenzugriff, dann ist es eh egal )
Btw: Dass in log(n) Malen eine Resize gemacht werden muss ändert nichts am O(1), denn dies gilt für jeden Zugriff einzeln. Ob dieses Resize irgendeine wesentliche Performance-Größe ist, hängt vom individuellen Fall ab. Zu dem kommt natürlich, dass Arrays von jedem modernen Compiler in den Cache vorgeladen werden (ich denke mal BMax tut das auch), damit wird der Zugriff nochmals um ein vielfaches schneller, gerade, wenn du wie durch eine Liste durch das Array läufst. |
||
BBPro2 |
Di, Dez 01, 2009 22:14 Antworten mit Zitat
|
|
|---|---|---|
|
hi
wenn man die linked list als stack benutzt läuft man nicht mauell die liste entlang denn wenn man das täte wäre es nicht O(1) sondern O(n) da wir vom stack ausgehen hat eine linked list O(1), ein array auch. (das macht das array ja nicht besser sondern gleichwertig in dem zusammenhang) wie arrays funktionieren weiß ich, auch wie ihr speicherzugriff funktioniert. ich rede hier ja nur vom spezialfall linked list als stack. in diesem fall sind linked lists den arrays zwar nicht im zugriff überlegen (weil arrays hier immer O(1) sind und somit nie verlieren können), aber in allen anderen methoden. element hinzufügen kostet bei ll konstant O(1), bei arrays amortisiert O(1), aber im worst case O(n) amortisiert bringt dir hier wenig - ll sind offensichtlich zu bevorzugen. element löschen ist bei ll O(1) - bei arrays O(n) ich sage nur dass wenn der schwerpunkt auf diesen methoden liegt (und das tut es beim stack ganz sicher) sind ll zu bevorzugen. mehr sag ich doch gar nicht^^ und das werdet ihr schwerlich widerlegen können oder? |
||
Dreamora |
Mi, Dez 02, 2009 3:37 Antworten mit Zitat
|
|
|---|---|---|
|
Theoretisch nicht.
Praktisch darf man allerdings einen punkt nicht vergessen und das ist der das du 5x soviel speicher verheizt mit der double linked list gegenüber dem array. Der array speichert nämlich nur etwas, die objekt referenz. die double linked list hat pro node die objekt referenz, 2 referencen zum nächsten / vorherigen objekt + die 8 byte overhead vom managed environment. Damit erzwingst du schon für relativ wenige objekte dass mehrstufige caches eingesetzt werden müssen und das es sehr häufig zu cache misses kommt denn die double linked list nodes sind im RAM nicht aufeinander folgend im unterschied zum array. heisst du kannst selbst im besten fall von einem c ausgehen was mehrere duzend mal höher ist als beim array, der wird nämlich nur 1 fail pro zig hundert elemente haben, nicht im worst case 1 fail pro element ( L2 / L3 cache miss heisst penalty von 300 - 1000 cyclen je nach cpu bis die daten im höchsten cache sind, einige weitere duzend bis hundert cyclen bis sie im L1 unten sind). Das heisst das du bei kleinen listen oder niedriger RAM fragmentierung (ich nenns jetzt einfach mal so, weil es am ehesten zutrifft vom problem der datencontinuität her) mit der dll besser weg kommst. Wenn wir aber von solchen "insane massen" an objekten ausgehen wie du sie oben für die deklaration angeführt hast, kanns extrem duster werden für dich, weil du speziell auf älteren CPU (vor allem amd) L1 und L2 cache grössen hast die dir grauenvoll das genick brechen werden und dir L1 und L2 cache misses einbringen, wie oben erwähnt. In solchen Fällen wird das c von c * O (..) bei weitem nicht mehr vernachlässigbar sein, weil ein c auf arrays einen direkten vergleich von c >> 1000 bei double linked lists in keinster weise mehr fürchten muss, da kommts mit den amortisierten kosten, die immer <= O (log(n) ) sind (da gibts keinen worst case O(n) für die amortisierten kosten und einzel op kosten interessieren niemand da man nicht nur 1 operation macht sondern offensichtlich hunderte von millionen bei der array grösse von der wir reden). Log(n) wird irgendwie gerne unterschätzt, aber man möchte nicht vergessen, dass wenn wir über 1.1 Mia elemente hinzufügen / entnehmen würden, das im log(n) nur einen unterschied von 30 ausmacht und wenn unsere condition für shrink für massive schwankungen ausgelegt ist, wirds im endeffekt sogar noch besser für uns weil wir unnütze shrink - raise folgen loswerden können. PS: Das hab ich jetzt einfach mal gepostet weil du scheinbar eine schon fast grausame freude an Informatik 1 von Computer Science zu haben scheinst, was schön ist für die Theorie wenn du theoretische Informatik studierst, in der Praxis jedoch grausig zurückschlagen kann wie du in info 3 / Betriebssysteme noch rausfinden wirst wenn ihr euch anschaut wie Caches, Pages, Misses der entsprechenden dinge und cpu pipelines funktionieren. Du arbeitest nicht mit ASM / ANSI C auf einer ARM / MIPS Platform die keinen wirklich datencache hat und wo darum alle fetches die gleichen kosten mit sich bringen, noch entwickeln wir auf single task betriebssystemen, es gibt von daher keine garantie das unser anwendungsspeicherraum kontinuierlich ist im physischen ram. Ich finde es allerdings gut, dass du dich mit den theoretischen Vorteilen der Datenstrukturen auseinanderzusetzen scheinst, da dir das bei verschiedenen Dingen durchaus helfen wird eine einigermassen sinnvolle Datenstruktur zu wählen für ein Problem. Für diesen Fall hier gehört die gewählte Datenstruktur der DLL durchaus zu den sinnvollen Datenstrukturen
Effizienter wäre wirklich nur ein Stack der auf einer single linked list basiert. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
BBPro2 |
Mi, Dez 02, 2009 3:57 Antworten mit Zitat
|
|
|---|---|---|
|
gut argumentiert, nehme ich an und freue mich ein wenig schlauer zu sein
als zuvor
in der tat interessiere ich mich sehr für die theoretische informatik (schreib am freitag ne klausur in ti )und praktisch fehlt mir noch einiges an wissen.
wir haben zwar ne andere vorlesungsstrutkur wies scheint, da wir kein teil 1 , 2, 3 etc haben aber was du meinst macht man bei uns (zumindest die grundlagen dazu) in der VL Systemarchitektur, welche ich erstmal nach hinten verschoben hatte. ein schlimmer fehler wie sich gerade herausstellen sollte
grober aufbau / funktion von caches war und ist mir zwar bekannt, hatte es in diesem fall allerdings grob fahrlässig vollkommen außer acht gelassen
danke für den langen beitrag. |
||
Übersicht
BlitzMax, BlitzMax NG Beginners-Corner
Powered by phpBB © 2001 - 2006, phpBB Group