Upsize und ISAM-Emulation

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

steffen.pirsig hat geschrieben: Mi, 31. Jul 2019 20:09 Für die Akten: Ein Thread auf einer CPU skaliert unter exakt zwei Randbedingungen:
4 Thread die auf einer CPU laufen sind langsamer als 4 x CPU ... klar muss die Software dazu fähig sein.
Ich kenne die Diskussionen mit den harbour Leuten warum es bei Xbase++ mit Thread (seit v1.5x ?) "anderes" ist ...
steffen.pirsig hat geschrieben: Letzteres ist exakt der Fall wenn der DbfUpsizer auf das Ergebnis vom SQL Server (Client / Server Betrieb) wartet, solange kann ein anderer Thread SQL Statements erstellen und auch an den Server senden.
die 4 Thread bringen "etwas" an Geschwindigkeit aber nicht im Verhäldniss dazu wenn man 4 x Apps auf 4 x CPU oder 4 x PCs laufen lässt. klar muss die Software dafür sorgen das jeder seine "Häppchen" bekommt aber damit hat der PostgreSQL Server bei 4 Apps / PCs keine Probleme ...

---

bei den ganzen Thread geht es um Geschwindigkeit und zwar die vom Client also Xbase++
mit SQL als Back-End steht man nun mit seinem Xbase++ Client in Konkurrenz zu anderen Sprachen.

Geschwindigkeit durch Nutzung der CPU Kerne und RAM sind die beiden Dinge die Xbase++ primär fehlen wenn es um die Aufbereitung der Daten geht.

---

Frage . was passiert wenn ich auf eine Table > 4 GB zugreife und das Result-Set Adressen liefert > 4 GB :?:

das sind doch die aktuellen Beschränkungen denen wir JETZT unterliegen wo der Kunde eine Lösung erwartet.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Und es wird weitergefaselt. :roll:
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

@Tom :
hast du dir das SQLqwery von Roger per ODBC angesehen ... habe es mit dem PostgreSQL ODBC Treiber ausprobiert =D>
PG_ODBC.JPG
PG_ODBC.JPG (133.78 KiB) 13204 mal betrachtet
ähnlich wie bei SQLexpress++ ist es eine weitere (schnelle) Methoden JETZT wenn man nicht die (langsame) PgDBE einsetzten will.
als Express++ User sollte das doch wenig Problem bei der Umstellung geben, oder :?:
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von brandelh »

AUGE_OHR hat geschrieben: Do, 01. Aug 2019 2:10
steffen.pirsig hat geschrieben: Mi, 31. Jul 2019 20:09 Für die Akten: Ein Thread auf einer CPU skaliert unter exakt zwei Randbedingungen:
4 Thread die auf einer CPU laufen sind langsamer als 4 x CPU ... klar muss die Software dazu fähig sein.
Ich kenne die Diskussionen mit den harbour Leuten warum es bei Xbase++ mit Thread (seit v1.5x ?) "anderes" ist ...
steffen.pirsig hat geschrieben: Letzteres ist exakt der Fall wenn der DbfUpsizer auf das Ergebnis vom SQL Server (Client / Server Betrieb) wartet, solange kann ein anderer Thread SQL Statements erstellen und auch an den Server senden.
die 4 Thread bringen "etwas" an Geschwindigkeit aber nicht im Verhäldniss dazu wenn man 4 x Apps auf 4 x CPU oder 4 x PCs laufen lässt. klar muss die Software dafür sorgen das jeder seine "Häppchen" bekommt aber damit hat der PostgreSQL Server bei 4 Apps / PCs keine Probleme ...
Die Diskussion erinnert mich irgendwie an den Versuch mit 4 Porsche morgens 4 Brötchen schneller einkaufen zu wollen,
als mit einem "normalen" PKW ... alle warten auf die Verkäuferin 8)

Was ist das schnellste Teil im Rechner ?

RAM oder CPU ... da lege ich mich mal nicht fest.

und das langsamste ?

Netzwerk und Festplatte ...

egal ob 4 CPUs oder 1 CPU mit 4 Threads, etwas vom Netz oder der Festplatte anfordern, warten Sie auf die Antwort !
Wenn man schneller sein will, muss man die Wege verkürzen !

Vor Jahren habe ich mit MySQL und PostGreSQL mit SQLExpress Experimente mit großen Imports gemacht - die Artikel kann man hier suchen wenn man will.
MySQL(-Client) konnte 10 Import-Befehle auf einmal ausführen und war damit viel schneller als jeden einzeln über PostGreSQL zu senden - (kann mittlerweile anders sein).

ABER am Schnellsten (um Faktor 100) war es die 1 Million Datensätze in eine TXT-Datei zu bringen, die aussah wie eine Datensicherung des MySQL Servers (also DB anlegen, Daten einlesen etc.) ...

Und wie oft wird so ein "Upgrade" ausgeführt ?
Bei einmaligen Aktionen spielt die Zeit doch eher eine untergeordnete Rolle ... unsere Verwaltung war bei der letzen Softwareumstellung eine Woche im Stillstand.
War nicht schön, ging aber nicht schneller.
Gruß
Hubert
Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

Hubert,
brandelh hat geschrieben: Do, 01. Aug 2019 8:12 Was ist das schnellste Teil im Rechner ?

RAM oder CPU ... da lege ich mich mal nicht fest.
Zwischen RAM also DDR3/DDR4 Hauptspeicher und dem CPU cache L1 liegen ungefähr zwei 10er Potenzen also Faktor 100 an Geschwindigkeitsunterschied. Die CPU Register sind allg. 5 mal schneller als ein L1 cache, und der L2 cache hat Faktor 10 zu L1.

Für Jimmy: Da cache coherence (Datenkonsistenz zwischen CPU Kernen) durch L3 erledigt wird kann sich jeder vorstellen was es bedeutet wenn Threads sich Daten teilen müssen. Wenn also nur 10% der Daten eines Multithreaded Prozesses über L3 invalidiert werden (weil unterschiedliche Kerne die gleichen Daten benötigen und mindestens einer Schreibt) führt das bereits zu einem Performance Einbruch von ~50% unter der Annahme die Daten wären im L2. Ein Array ist aber ein linearer Speicher, die Wahrscheinlichkeit für einen L1 Hit ist damit signifikant höher - in der Konsequenz könnten die 10% Datenzugriffe damit um bis zu 100 mal langsamer werden.

Ich denke jedem sind damit die Konsequenzen von Datensharing zwischen Threads auf unterschiedlichen CPU Kernen verdeutlicht worden.

Zur info,
Steffen F. Pirsig
Alaska Software Inc.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

brandelh hat geschrieben: Do, 01. Aug 2019 8:12 Die Diskussion erinnert mich irgendwie an den Versuch mit 4 Porsche morgens 4 Brötchen schneller einkaufen zu wollen,
als mit einem "normalen" PKW ... alle warten auf die Verkäuferin 8)
wenn du mit der "Verkäuferin" den SQL Server meinst ... die ist "schneller" als du denkst weil die Multitasking-fähig ist :badgrin:
wenn überhaupt ist es die "Ampel" welche den Verkehr regelt die nicht grün wird wenn die mit dem Porsche ankommen :^o

ich verwenden 4 x PC die auf die Server zugreifen. alle 4 PC greifen auf die selbe DBF zu (ohne Index) und jeder bekommt 1/4 der Records. jeder PC liest nun Satzweise die Daten aus der DBF und sendet dann ein "INSERT INTO " Statement an den PostgreSQL Server.

Gegenprobe mit einem "schnelleren" PC und der selben Aufgabe mit einer CPU ... wer ist wohl "schneller" gewesen :?:

---

p.s. ich höre immer nur was NICHT geht ... Interessanter finde Information was man machen kann.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von brandelh »

Wenn der eine PC die Datei exclusive lesen darf ist er auf jeden Fall schneller (beim Lesen) als 4 PCs die über das Netzwerk auf eine shared Datei zugreifen.
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Interessanter finde Information was man machen kann.
Schreibt jemand, der mit einer zehn Jahre alten Compilerversion arbeitet - und kaum etwas von dem, worüber er hier (mit)schwätzt, einsetzen bzw. überprüfen kann.

Wenn (D)eine eigenartige Argumentation ins Leere geht, nimmst Du halt die nächste. Zumindest mir gehst Du damit im Moment gehörig auf den Wecker, Jim. Ist das irgendwie deutlich geworden? 8)
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Tom hat geschrieben: Do, 01. Aug 2019 10:51 Schreibt jemand, der mit einer zehn Jahre alten Compilerversion arbeitet -
verwendest du TC ?
du weisst sicherlich womit das geschrieben wurde und was für eine Version es ist ...

"alt" heisst nicht schlecht und "Stable" ist mir immer noch lieber als "ständige Beta" wo sich neue Probleme einschleichen.
Tom hat geschrieben: und kaum etwas von dem, worüber er hier (mit)schwätzt, einsetzen bzw. überprüfen kann.
wir reden hier über PostgreSQL und Upsize. der Rest von v2.x interssiert hier keinen.

Frage : hast du über den Xbase++ "Rand" geguckt und einen Gegen-Test gemacht zu PgDBE :?:

Ich kennen das Grundkonzept der ISAM Emu bei UpSize und habe es 2012 für PGU nach gebaut.
bei Einsatz der native Schnittstelle stelle sich dann schnell raus das PgDBE bei > 100.000 bis zu Faktor 10 langsamer ist.

also warum soll ich eine neuere Version verwenden die nicht schneller ist als die alte [-X
NICHTS von den Xbase++ v2.x Sachen macht eine v1.9x Apps schneller ... es wird nur "fetter" wie bei den "dicken" Autos

das einzige was mich an interessiert : Compiler & Linker.
Tom hat geschrieben: Wenn (D)eine eigenartige Argumentation ins Leere geht, nimmst Du halt die nächste.
AHA ... sagt du gleich das du es nicht verstehst.
Tom hat geschrieben: Zumindest mir gehst Du damit im Moment gehörig auf den Wecker, Jim. Ist das irgendwie deutlich geworden? 8)
dann mal deutlich : ist mir egal ob ich dir auf den Wecker gehe solang es Meinungsfreiheit gibt.
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

bei Einsatz der native Schnittstelle stelle sich dann schnell raus das PgDBE bei > 100.000 bis zu Faktor 10 langsamer ist.
Jimmy, das Performance Problem hat mir Steffen in einem Beitrag weiter oben erklährt wieso das so ist:
Zum allerletzen mal. Wenn du eine Performance-Degradierung beim Upsize hast, dann ist der Server falsch konfiguriert.
......
Ich geb jetzt auf, an alle anderen. Bitte verwendet PGTune oder Sekundärliteratur und konfiguriert den PostgreSQL Server entsprechend.
Meinem PG sind 96GB zur verwendung zugeteilt, wenn du auch Performance Probleme hast wird es sicher das selbe sein: falsche Konfigurtion.
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

brandelh hat geschrieben: Do, 01. Aug 2019 10:27 Wenn der eine PC die Datei exclusive lesen darf ist er auf jeden Fall schneller (beim Lesen) als 4 PCs die über das Netzwerk auf eine shared Datei zugreifen.
das wäre ungleiche Bedingungen [-X

---

mit einer Workstation schaffe ich ca. 2000 "INSERT" / Sec.
wenn ich nun 4 Workstationen betreibe schafft jede > 1000 "INSERT" / Sec

dabei zeigt CPU und Netzwerk < 50% an also längst nicht ausgelastet.

4 Workstationen sind also deutlich schneller als ein PC mit 4 Threads die auf einer CPU laufen.

die selbe Leistung hätte man mit 4 x Threads die jeweils einen CPU Kern nutzen.
wenn ich auf dem schnellen PC 4 x Xbase++ App laufen lasse die jeweils einem anderen CPU Kern nutzen komme ich auf ähnliche Wert wie die Workstationen.

lediglich im Server Netzwerk Monitor steigt die Last auf ca. 80% während die CPU Last gleich bleibt.
es ist also die Xbase++ App wo noch "Luft" ist

--

die Standard Konfiguration ist "Shared Memory = 1 GB"

bei max. 2 GB DBF ist die Konfiguration noch nicht mal optimal
für einen SQL Server mit 16 GB kann man die Standard Werte deutlich erhöhen
shared_buffers = 4GB
effective_cache_size = 8GB
bei max. 2 GB DBF würden alle Transaktionen einer DBF beim Import im "Cache" landen
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

ramses hat geschrieben: Do, 01. Aug 2019 23:22
Zum allerletzen mal. Wenn du eine Performance-Degradierung beim Upsize hast, dann ist der Server falsch konfiguriert.
......
Ich geb jetzt auf, an alle anderen. Bitte verwendet PGTune oder Sekundärliteratur und konfiguriert den PostgreSQL Server entsprechend.
Meinem PG sind 96GB zur verwendung zugeteilt, wenn du auch Performance Probleme hast wird es sicher das selbe sein: falsche Konfigurtion.
Ich habe KEINE Performance Problem sondern Steffen versucht es auf die Server Konfiguration zu schieben wenn man über die Geschwindigkeit des Upsize Tool spricht.

---

der Server ist für alle Client Apps der selbe ob gut oder schlecht konfiguriert.
der Vergleich von verschiedenen Client zeigt nun das es deutlich Unterschied in der Geschwindigkeit gibt.

---
man muss nur bereit sein über den Xbase++ "Rand" zu schauen was "andere" können ... aber davon wollen einige hier im Forum wohl nichts wissen ...
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

AUGE_OHR hat geschrieben: Do, 01. Aug 2019 23:03AHA ... sagt du gleich das du es nicht verstehst.
Jimmy,

ich hatte mir fest vorgenommen auf Deinen Schwachsinn nicht mehr zu reagieren. Aber da geht mir dann doch die Hutschnur hoch. Bist Du jetzt komplett abgehoben und borniert, das Du solch eine Behauptung ernsthaft in die Welt setzt?
AUGE_OHR hat geschrieben: Do, 01. Aug 2019 23:03
Tom hat geschrieben:Zumindest mir gehst Du damit im Moment gehörig auf den Wecker, Jim. Ist das irgendwie deutlich geworden? 8)
dann mal deutlich : ist mir egal ob ich dir auf den Wecker gehe solang es Meinungsfreiheit gibt.
Klar ist auch irres Zeug verbreiten durch die Meinungsfreiheit gedeckt. Aber die Meinungsfreiheit deckt auch das man darauf passend reagieren darf. Es soll aber Leute geben die vollkommen lernresistent sind und solche Kommentare niemals auf sich beziehen oder zum Anlaß nehmen, mal darüber nachzudenken warum jemand so reagieren könnte. Ja, damit meine ich jemanden bestimmten damit, und das sind weder Tom noch ich.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

@Jan : witzig das du dich zu Wort meldest ...
wie gewöhnlich nicht zum Thema oder hast du mit PostgreSQL schon eine App am laufen :?:

und was Tom angeht : er kann mir selbst antworten !

---

mir ist es egal ob Leute mich mögen oder mich Diskriminieren.
es geht um das Thema Xbase++ und PostgreSQL und nicht um meine Person.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

eine aktuelle Meinung von Roger zum Thema Upsize
https://bb.donnay-software.com/donnay/v ... =19&t=2623
I learned that UpSize is not required when adding tables to a PostGreSql database that is used by PGDBE.

The additional fields and procedures added by DbfUpSize are only there for ISAM emulation, and an upsized table still performs badly in ISAM mode. Record numbers, Record count, etc. are not always reliable. If I were to create a new project using PostGreSql I think that PGDBE would be a fine database engine if only SQL was used.
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Jimmy,

ich melde mich nicht fachlich zu Wort. Ich betone das ausdrücklich, weil Du das nicht zu bemerken scheinst. Ich melde mich zu Wort weil Dein Umgang mit anderen Forenteilnehmern sehr zu Wünschen übrig läßt.

Das ist also nicht "wie gewöhnlich", denn wenn ich auf fachliche Fragen antworte tue ich das auch fachlich.

Mir zu unterstellen das ich Dich diskriminieren würde ist schon mehr als hanebüchen. An was machst Du diese angebliche Diskriminierung fest? Wer mich kennt weiß, das ich mich extrem bemühe, niemanden für irgend was zu diskriminieren. Nicht diskriminieren ist aber nicht gleichbedeutend mit die eigene Meinung zu sagen.

Und klar kann Tom Dir selber antworten. Aber Du hast in einem öffentlichen Forum Deine irrwitzigen Unterstellungen gepostet. Und Dich auf Meinungsfreiheit berufen. Gestehst Du mir jetzt nicht die von Dir reklamierte Meinungsfreiheit zu wenn ich Dir sage, das Deine Unterstellungen anderen Forenteilnehmern gegenüber sowas von an den Haaren herbeigezogen sind? Ich steh total auf Leute dich für sich selber Rechte in Anspruch nehmen, die sie anderen dann wiederum absprechen [ironie off].

Und in dem Punkt stimme ich Dir vollkommen zu: Es geht um Xbase++ und PostgreSQL. Nicht um Personen. Aber leider trägst Du diese persönlichen Angriffe in diese Diskussion ein. Indem Du andere Meinungen als Deine zum fachlichen Thema nicht gelten läßt und denen, die eine andere Meinung vertreten, jegliche Kompetenz absprichst - sowohl fachliche als auch persönliche. Ich würde es sehr begrüßen wenn wir wieder zum fachlichen Teil zurück kehren könnten. Das hängt aber einzig und alleine an Dir. Man kann natürlich unterschiedlicher Meinung sein. Kann das aber zivilisiert austragen, ohne persönliche Angriffe. Warum Du Dir ausgerechnet Tom als Opfer Deiner persönlichen Anschuldigungen ausgesucht hast ist mir schleierhaft. Er und ich sind in für uns beide grundlegenden Themen extrem unterschiedlicher Meinung. Das hindert uns aber nicht daran ordentlich miteinander umzugehen. Wenn man nur will geht das sehr gut. Versuch es doch einfach mal, es lohnt sich. Sag ich Dir aus eigener Erfahrung.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Jimmy,

ließt Du eigentlich auch mal das, was Du da zitierst? Roger schreibt explizit
If I were to create a new project using PostGreSql I think that PGDBE would be a fine database engine if only SQL was used.
Die ISAM-Emulation ist aber in erster Linie eben NICHT für neue Projekte gedacht. Sondern als Migrationspfad für bestehende.

Rogers Zitat ist also keinesfalls eine Unterstützung für Deine Meinung.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von brandelh »

Wenn 4 PCs mehr inserts schaffen, als 4 PC mit 4 Threads, würde ich mal auf die Netzwerkkarte tippen, viel langsamer als eine CPU.
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Jim, ich mag Dich. Und ich glaube nicht, dass hier irgendwer irgendwen diskriminiert, aus welchen Gründen auch immer.

Aber Du bist auf dem falschen Dampfer. Und Du bist auch noch ganz allein auf diesem Dampfer. Und da sind Eisberge draußen, ganz viele. Also, komm runter, aufs Festland oder einen richtigeren Dampfer.

(Diese Nachricht ist zertifiziert ironiefrei.)
Herzlich,
Tom
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von andreas »

Ich habe einiges gelesen, an Vorträgen gehört und selbst Tests unter C# mit Parallelausführung auf mehreren CPUs (keine Threads) ausprobiert.
Die Job-Verteilung auf mehrere CPUs kostet viel Zeit! Das ist von vielen Experten bewiesen!
Deswegen raten diese, vor der Anwendung der Parallelausführung auf mehreren CPUs jeden einzelnen Fall zu bewerten!
Ich habe Beispiele in C# nachgebaut, die das gleiche mit unterschiedlicher Menge der Operationen/Daten ausführen.
Die Ergebnisse: die Ausführung auf mehrere CPUs löhnt sich nur bei sehr großen Operations-/Datenmenge aber auch nicht immer!
Bei kleinen Mengen ist die Parallelität viel langsamer! Und ob es bei den Größeren Mengen und kleinen ms-Unterschieden es sich lohnt, ist auch die Frage, die jeder für sich selbst und je Projekt beantworten muss.

Im folgenden Bild habe ich Screenshot von dem C#-Programm angehängt. Die Schleifen machen nur mathematische Operationen. Bei dem Beispiel mit den Namen werden diese auf Bildschirm ausgegeben. Die Ergebnisse müssten für alle Programmiersprachen gelten! Die Verteilung der Aufgaben auf Threads würde hier bestimmt noch das ganze etwas beschleunigen, würde aber von der eigener Programmierung und richtiger Aufgabenverteilung abhängen!
Parallelausfuehrung.png
Parallelausfuehrung.png (19.48 KiB) 13002 mal betrachtet
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Andreas,

Verständnisfrage: Das bezieht sich darauf, das ein Prozess auf mehrere Kerne aufgeteilt werden soll? Wenn ja: Dann wäre es eventuell von Vorteil, zwei vollkommen unabhängig an verschiedenen Aufgaben arbeitende Threads auf zwei Kerne aufteilen zu können?

Prinzipiell ist es ja so, das man in Xbase++ den Kern auswählen kann. Wobei man soweit ich weiß nicht vorher feststellen kann ob das auch der am wenigsten belastete ist. Bei dem es also Sinn machen würde, den auszuwählen. Oder kann man sowas per API auslesen? Im Taskmanager sieht man die Belastung der einzelnen Kerne ja auch.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Hallo, Jan.

Es gibt Pseudo-Registry-Einträge, über die man die aktuelle Belastung der Kerne ermitteln kann, aber das sind nur Snapshots, weshalb das nicht wirklich eine hilfreiche Information darstellt. Prozesse, die auf Dauer viel CPU-Last erzeugen, sind eher die Ausnahme. Alle Gelehrten werden Dir erzählen, dass es am sinnvollsten ist, Kerne nach dem Zufallsprinzip auszuwählen. Gerade bei Terminal Servern hat es sogar Vorteile, dass Xbase++-Anwendungen strikt auf einem Kern laufen - man kann Lastverteilungssysteme implementieren und zumindest bezogen auf die eigene Anwendung gut für Balance sorgen, denn oft gibt es weniger Kerne als gleichzeitige Nutzer.

Bei einer klassischen vertikalen Xbase++-Anwendung könnte es sinnvoll sein, beispielsweise Auswertungen auf einen anderen Kern zu schieben, wenn man währenddessen weiterarbeiten will. Aber auch das will irgendwie synchronisiert werden. Man kann eine Instanz unserer Hauptanwendung parallel als Service-App starten, die nur auf solche Anforderungen wartet und sie dann auf einem anderen Kern als die Hauptanwendung ausführt. Unsere Messungen haben aber ergeben, dass das kaum Gewinn einbringt. Die Bottlenecks sind anderswo.
Herzlich,
Tom
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von andreas »

Jan hat geschrieben: Mo, 05. Aug 2019 10:59 Verständnisfrage: Das bezieht sich darauf, das ein Prozess auf mehrere Kerne aufgeteilt werden soll?
Ja, da ist so. C# hat die Möglichkeit eine Schleife automatisch parallel aufzuteilen und auszuführen, was ich auch im Test gemacht habe. Die Schleifen wurden im Beispiel nach einander ausgeführt, um die Zeiten zu ermitteln.

Im folgenden Bild habe ich noch zus. Test mit Threads eingebaut, wobei alle mit unterschiedlichen Operationsmengen ohne eingebaute Parallelisierung gleichzeitig ausgeführt wurden. Hier kann man erstens sehen, dass die Parallelisierung jedes mal andere Zeiten braucht. Bei den Threads gibt es zum Teil kaum Unterschiede, ob nur ein Prozess oder mehrere gleichzeitig ablaufen.
Parallelausfuehrung1.png
Parallelausfuehrung1.png (20.16 KiB) 12960 mal betrachtet
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von andreas »

So, wie Jan schon gesagt hat, wäre es bestimmt hilfreich, bei Threaderzeugung eine CPU bzw. Kern festlegen zu können. Damit könnte man die Lastaufteilung selbst steuern.
Ob es überhaupt möglich ist, Thread-Funktionalität damit zu erweitern, kann nur Alaska sagen.

Ich hoffe, dass Steffen diese Beiträge ließt und uns entsprechende Antwort geben könnte.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Es SCHEINT so als ob man die Auslastung der Kerne per WMI auslesen kann. Hab mich da aber noch nicht tief reinlesen können.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Antworten