Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Eigentlich ist mir die Frage peinlich, aber es kann sonst niemand helfen ... :)

Moderator: Moderatoren

Antworten
Benutzeravatar
Eugeny Lutsenko
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 108
Registriert: Fr, 15. Mai 2020 16:16
Wohnort: Russland, der südliche Föderale Bezirk, die Stadt Krasnodar
Hat sich bedankt: 12 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Eugeny Lutsenko »

Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

1. Gibt es eine Möglichkeit, mit dbf-Dateien zu arbeiten, die mindestens 4GB groß sind (wie in CLIPPER), ohne SQL, ADS und dergleichen zu verwenden? Aber besser mit viel größeren Datenbanken.

2. Es ist sehr wichtig, mindestens 1-2 Größenordnungen, um den Zugriff auf Datenbanken zu beschleunigen.

3. Gibt es eine Möglichkeit, alle CPU-Kerne für Berechnungen zu verwenden, ohne die Software zu überarbeiten?

4. Gibt es eine Möglichkeit, die gesamte GPU für Berechnungen zu verwenden, ohne die Software besonders zu überarbeiten?

5. Drastisch, um das Problem der Mangel an RAM bei der Erstellung von Arrays von sehr großer Dimension zu lösen.

Diese Einschränkungen sind sehr bedrückend. Du fängst sogar an, nach alternativen zu suchen, zum Beispiel C#.
Zuletzt geändert von Eugeny Lutsenko am Sa, 16. Mai 2020 19:58, insgesamt 1-mal geändert.
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: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Jan »

3) Nein. Außer Du erzeugst mehrere exe, die jeweils auf eigenen Kernen laufen. Den zu verwendenden Kern kann man ja setzen. Aber das wäre natürlich eine Software-Überarbeitung.

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: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von brandelh »

zu 1. NEIN, die DBF ist in allen meinen Tests auf den maximalen Wert der LONG begrenzt ... 2,1 GB oder so. Die FOXDBE kann aber mit sehr großen Memo Dateien umgehen. Ob das Sinn mach ist eine andere Frage.
zu 2. JA, mit einer SSD ist vieles flott, was bisher lahm war.
zu 3. es gibt einen Schalter, der die Kerne freigibt, aber danach wird die EXE sehr viel langsamer, da alle Threads gegenseitig aufeinander warten. Das ist der Grund, warum eine Xbase++ EXE immer auf einen Kern begrenzt wird.
zu 4. Immer wenn man neue Hardware verwenden will, muss man entweder selbst neue Bibliotheken verwenden, oder der Hersteller muss das tun. Bisher ist da nix geschehen, ich denke es wird da auch nix passieren.
zu 5. Man kann Arrays mit Parameter größer machen, aber das Einlesen der Daten wird mit der Zeit immer langsamer. Meine Tests mit Datei kopieren haben ergeben, dass es sinnvoller ist 4 KByte Blocks einzulesen, zu verarbeiten und so intern Speicher zu sparen. Eine 32 Bit EXE hängt an der 4 GB Begrenzung, wenn man z.B. 500 MB Strings lädt und manipuliert, muss er ja Zwischenergebnisse zwischenspeichern, da kann es schon eng werden.
Bei Arrays gehen normal aber auch die Resourcen der Zeiger aus.

Für so extreme Arbeiten sind andere Sprachen wie C/C++ besser geeignet, wenn man weiß wie man sie benutzt (ich weiß es nicht).
Gruß
Hubert
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: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von ramses »

Hallo Eugeny
Eugeny Lutsenko hat geschrieben: Sa, 16. Mai 2020 19:30 Diese Einschränkungen sind sehr bedrückend. Du fängst sogar an, nach alternativen zu suchen, zum Beispiel C#.
Das sind Sie tatsächlich, sehr sehr bedrückend. Die Einschränkungen sind der Preis den man bezahlen muss um den Komfort der dBaseII/III und Clipper 87 Sprache heute noch nutzen zu können. Und dies ohne eine neue Spache und deren Probleme wie z.B. Speicherverwaltung unter C zu lernen.

Ich habe eine grosse Code-Basis und Programme die aus den Anfängen von Clipper stammen. Diese wurden laufend erweitert und überarbeitet und laufen unter XBase++ noch immer.

So bin ich in der Sprache eingesperrt. Wie vermutlich auch noch einige andere auch.

Einige Zeit liessen sich die Einschränkungen durch schnellere Prozessoren, Disk's usw. auffangen. Dies ist nun auch zu Ende.

Müsste ich heute bei Null beginnen würde ich ausschliesslich Web-Apps im Single Page Design bauen.
Das Frontend in HTML5, Bootstrap, JS/Jquery usw. und das Backend (Web-Server) mit C unter FreeBSD.

Einige Programme habe ich auf Web-Apps (Single-Page-Design) mit xb2net (XBase++) als Backend umgebaut das hat sehr sehr viel Geschwindigkeitsvorteile gebracht.
Der ganze Maskenaufbau und grafische Aufgaben wird vom Browser erledigt der mehrere Kerne GPU usw. nutzt.
Besonders beim Bildschirmaufbau und grafischen Darstellungen war diese Umstellung markant.

Andere Kunden habe ich verloren weil xbase als Grundlage nicht mehr gewünscht war.
Auch die Umstellung auf PostgreSQL (nativ) mit direkter Verwendung der LIBPQ.DLL (ich nutze die PGDBE gar nicht) hat einige Vorteile gebracht und Einschränkungen beseitigt besonders im Umgang mit grossen Datenbeständen.

Ich versuche mit xbase++ und meinen Programmen / Codebasis bis zur Rente in einigen Jahren weiterzuarbeiten.
Für vieles ist xbase++ mit modernen Servern und Web-Apps auch heute noch genügend schnell.

Gerade die Single-Page-Design Web-Apps kommen bei den Kunden sehr gut an. Sie sind benötigen auf den User Geräten keine Installation sind wartungsfrei und laufen Ort und Geräteunabhängig.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Eugeny Lutsenko
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 108
Registriert: Fr, 15. Mai 2020 16:16
Wohnort: Russland, der südliche Föderale Bezirk, die Stadt Krasnodar
Hat sich bedankt: 12 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Eugeny Lutsenko »

Hi, Ramses!

Meine Hauptentwicklung-das Eidos-System, wurde auf CLIPPER geschrieben. Ich habe es seit den späten 80er Jahren entwickelt und zu dieser Zeit hatte CLIPPER keine Alternative als Entwicklungssprache. Bis 2012 wurde deutlich, dass man in eine andere Sprache wechseln muss. Ich habe Xbase++ gewählt, weil ich eine große Anzahl von Quelltexten auf CLIPPER angesammelt habe. Ich habe versucht, Delphi for php und Java zu verwenden, um die Entwicklung fortzusetzen. Aber ich habe diese Idee schnell zugunsten von Xbase++aufgegeben. Ich erkannte, dass die Kosten für Arbeit und Zeit für die Entwicklung neuer Sprachen nicht erlauben, mir das Projekt für die Zeit, für die ich es tun muss, zu realisieren. Meine Entscheidung erwies sich als gerechtfertigt. Ich habe sehr schnell eine neue Version des Eidos-Systems auf Xbase implementiert. Seine Funktionalität und die Fähigkeit, mich zu entwickeln, ist sehr zufrieden. Ich entwickle es ständig, auch gestern und heute führte die Entwicklung und das Debuggen neuer Modi. Ich Wende das System im Lernprozess und für die wissenschaftliche Forschung an. Manchmal stoße ich jedoch auf einige Einschränkungen, die sich aus den Einschränkungen der Xbase-Sprache selbst ergeben. Ich kann Sie nicht überwinden, indem ich innerhalb dieser Sprache bleibe. Also habe ich angefangen, fremde Module zu verwenden, die in anderen Sprachen geschrieben wurden, in denen es keine solchen Einschränkungen gibt. Die Logik deutet darauf hin, dass das Eidos-System im Laufe der Zeit vollständig in einer dieser anderen Sprachen (C#) implementiert wird. Dies wäre eine plattformübergreifende nicht-lokale Implementierung, die sowohl die CPU-Kerne als auch die GPU für die Berechnung effizient nutzt. Alle oben genannten und andere Einschränkungen Der Xbase-Sprache werden in der neuen Version überwunden werden.
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: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von ramses »

Hallo Eugeny

Du bestätigst meine Gedanken und Entscheidungen. Ich bin in fast allen Punkten zu den selben Resultaten gekommen.
Ich verwende auch einige in C und ASM geschriebene Module welche die Rechnen intensiven Berechnungen / Bildauswertungen und auch das Drucken (List&Label) ausführen. ASM-Module habe ich zu Clipper Zeiten viele selbst erstellt.

Ich schreibe Programme zur Prozess/Maschinen-Steuerung, Materialoptimierung, Anlagen und sonstige überwachung / Visualisierungen und allg. Verwaltungsaufgaben.

Ich habe mir auch mehr Kerne gewünscht. Inzwischen fanden wir eine gute Lösung die Leistung zu verbessern. Mit einem Load-Balancer ist es möglich den Web-Server in xbase++ auf mehreren Kernen des Servers einzusetzten und so die Performance massiv zu verbessern.

Jedoch bin ich mir sicher dass ich die Programme nie in eine andere Sprache portiert werde. Das würde zuviel Zeit benötigen.
Bei meinem aktuell grössten Kunden gilt die Regel dass keine Personen im Rentenalter hier über 65 Jahre angestellt/arbeiten dürfen.

Also werden die Programme vermutlich in ferner Zukunft von anderen Firmen mit anderen Tools neu entwickelt.

Momentan ist wegen den Corona Lockdown und den Folgen sowieso noch einiges völlig unklar .......
Produktionsverlagerung Richtung Osten zur Gewinnmaximierung nach den Lockdownverlusten ist auch ein heisses Thema ....
Valar Morghulis

Gruss Carlo
Benutzeravatar
Eugeny Lutsenko
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 108
Registriert: Fr, 15. Mai 2020 16:16
Wohnort: Russland, der südliche Föderale Bezirk, die Stadt Krasnodar
Hat sich bedankt: 12 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Eugeny Lutsenko »

ramses hat geschrieben: So, 17. Mai 2020 14:12Das würde zuviel Zeit benötigen.
Bei meinem aktuell grössten Kunden gilt die Regel dass keine Personen im Rentenalter hier über 65 Jahre angestellt/arbeiten dürfen.
Wir haben keine solche Einschränkung. Mein Chef ist bald 80 Jahre alt. Ich bin 65 Jahre alt:
https://kubsau.ru/education/chairs/comp-system/staff/. Wir haben 3 Doktoren - Professoren und 2 Doktoranden-Assistenzprofessoren, die älter sind als ich
Zuletzt geändert von Eugeny Lutsenko am Mo, 18. Mai 2020 7:23, insgesamt 1-mal geändert.
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: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von ramses »

Hallo Eugeny
Eugeny Lutsenko hat geschrieben: So, 17. Mai 2020 18:00 Wir haben keine solche Einschränkung.
Leider haben viele Firmen und Organisationen Ihre eigenen und unterschiedliche Ideen was das Alter der Freien und Festen Mitarbeiter und Angestellten oder auch bei den Lieferanten für wichtige Positionen/Material angeht ..... Ich könnte dir da einige Geschichten erzählen!

Andere Länder andere Sitten.

Ich fahre schon lange ab und zu LKW Ladungen durch Europa. Das ist etwas darauf haben viele der jungen Fahrer gar keine Lust mehr vorallem nach Hamburg England oder Schweden. Mir machts Spass und ich könnte es auch zum Vollzeit Job ausbauen.
Daher ist es mir eigentlich auch egal wenn ich keine EDV Aufträge / Arbeit mehr bekomme und auch ein Grund keine neue Comutersprache mehr zu erlernen. Ich könnte auch jetzt schon mit 63 in Frührente gehen aber das mag ich ganz und gar nicht.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Eugeny Lutsenko
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 108
Registriert: Fr, 15. Mai 2020 16:16
Wohnort: Russland, der südliche Föderale Bezirk, die Stadt Krasnodar
Hat sich bedankt: 12 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Eugeny Lutsenko »

N meiner Abteilung gibt es 3 Doktoren-Professoren und 2 Doktoranden - Assistenzprofessoren älter als ich. Ich bin auch nicht in Eile in den Ruhestand. Ich arbeite die ganze Zeit und ich mag es
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 851
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 192 Mal
Kontaktdaten:

Re: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Marcus Herz »

Hallo
Ich hatte bei einem Projekt mit Optimierungen in der Zeitachse auch das Problem des schnellen Rechnens. Habe diese Module in C geschrieben, waren meist Matrizen Operationen. Hatte mir zuletzt die C Datentypen, bei Matrizen Rechnungen eben meist long[] oder float[] Vektoren, als C binär String in die DBF geschrieben. So musste ich keine Datenkonversion durchführen, einfach den c Pointer als long[] umdeklariert. War zum Schluss rasend schnell.
Sowohl die Berechnungen, als auch die Xbase Anwendung für die Benutzeroberfläche.
Hatte es noch mit Xbase Arrays versucht, aber hier gibt es eben keine deklarierten Datentypen, ist wahrscheinlich deswegen bei komplexen Berechnungen doch langsamer.
Grüße Marcus
Gruß Marcus

Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von Herbert »

Würde mich reizen, so was in Windev zu testen. Melde dich mal per PN.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von mikehoffmann »

Hallo Eugeny,

auch ich bin mit Xbase++ an einigen Stellen angekommen, an denen es seit Jahren nicht weitergeht:

- DBF-Dateigrößenproblem (wie Du)
- Bindung an die 32Bit-Welt (keine 64Bit-Variante von Xbase++ in Sicht)
- Keine Destructoren in den Objekten
- Keine Arrayfunktionalität als virtuelle Objekt-Member implementierbar
- Keine eigenen Datentypen mit Überladen von Operationen möglich
- Keine Unicode-Unterstützung
- Indexsequentieller Zugriff auf Daten (dbf/ntx) wird vom Betriebssystem gerade noch toleriert, aber von dessen Benutzung wird massiv abgeraten. In ein paar Jahren wird hier das Ende der Fahnenstange erreicht sein.
- Keine Unterstützung des Structured Windows Exception Handlings

Aber das ist kein Grund für mich, Trübsal zu blasen.

Schon als die Clipper-Zeit zu Ende ging, hatte ich überlegt, einen eigenen Compiler zu schreiben. Damals war ich dafür noch nicht reif genug, glaube ich, oder Assembler doch zu abschreckend. Aber ich war nah dran, als mir schließlich Xbase++ über den Weg lief. Die Idee des eigenen Compilers ist aber nie gestorben. Die Bekanntschaft mit C++ und all seinen Möglichkeiten hat in meiner Vorstellung aus dem Compiler einen Transpiler gemacht, der die C++ Features nutzt und damit sogar prozessor-, architektur- (16/32/64 bit/.Net, ...) und betriebssystemunabhängig wird.

Vor zwei Jahren habe ich im Urlaub begonnen, diesen Transpiler zu schreiben. Das Kind hat den Namen "Breeze" bekommen. Im ersten Schritt sollte Breeze Xbase++ Programme analysieren können und ein paar Erweiterungen der Sprache ermöglichen. Genau so weit habe ich den Transpiler damals programmiert und ihn über alle meine Programme laufen lassen, um ihn zu testen. Er hat dabei die Aufgabe des Preprozessors erfüllt. Der Preprozessor ist die komplexeste Komponente des Xbase++ Compilers. Hat man den Punkt erst mal erledigt, ist der Rest Schönwettersegeln. Der zunächst von Breeze erzeugte Code war Xbase++ Code, der aber den Xpp-Preprozessor nicht mehr benötigte. Nix besonderes möchte man meinen. Aber damit war klar, dass ich die Sprache und bestehenden Code 100% im Griff habe. An der Stelle wurde die Entwicklung von Breeze eingefroren. Und mein Urlaub war zu Ende.

Die Corona-Pause, meine Notebook-Migration nach Windows 10 und nicht zuletzt mein Kollege haben mich darauf aufmerksam gemacht, dass es nun eine umfangreiche kostenlose Version von Microsoft Visual Studio 2019 gibt (Community Edition). Das Ding habe ich als bezahlte Version in der Vergangenheit schon immer für meine Dialoge und meine C Library-Funktionen genutzt. Nun kann es jeder kostenlos auf seinem Rechner installieren, inklusive schniekem Dialog-Editor und C++ Compiler. Echt dufte.

Meine Arbeit mit C++ in den letzten beiden Jahren haben für die Erfahrung gesorgt, mit der ich mich nun um die Breeze Code-Erzeugung in C++ kümmern kann. Also habe ich zunächst die Code-Erzeugung für alle Kontroll-Konstrukte und einige mathematischen Operationen für die einfachen Datentypen (C/N/L/U) implementiert. Den erzeugten Code kann man durch den C++ Compiler übersetzen lassen und ganz normal linken. Ist in Visual Studio ein Knopfdruck. Funktioniert wunderbar und die Ausführungsgeschwindigkeit ist (unoptimiert) mit der von Xbase++ vergleichbar.

Jetzt wird es spannend. Man hat nun alle Optimierungsmöglichkeiten des C++ Compilers parat, z.B. verschiedene Runtime-Systeme für Singletasking und Multitasking. Code-Optimierung natürlich auch. Und das Beste: Ein kleiner Schalter erlaubt es einem, 64-Bit-Code zu erzeugen. Speicher ohne Ende. Allerdings läuft der Code langsamer, was nicht verwunderlich ist, wenn man mal drüber nachdenkt. Aber der Gedanke, alle Tabellen im virtuellen Speicher zu haben und wie auf Arrays darauf zuzugreifen, zaubert einem ein Grinsen ins Gesicht. Bei SAP heißt das Hana. Bei mir würde das Hammer heißen.

Damit wird es auch möglich, Clipper/Xbase/Breeze Code auf Arduinos, Himbeerkreiszahlen oder anderen Maschinchen laufen zu lassen, für die es einen C++ Compiler gibt.

Auch wenn C++ die erste Zielsprache von Breeze darstellt, es spricht nichts dagegen, C#, Basic, Assembler, Windev, ... Code erzeugen zu lassen. Es ist sogar recht einfach. Man muss halt jeweils ein Runtime-System für die Zielsprache konstruieren. Das könnte aber wieder auf dem nativen Breeze Runtime System in C++ basieren.

Eine Kombination von Breeze und inline C++ Code im selben Source wird damit auch kinderleicht, weil Breeze literalen C++ Code einfach bis zum C++ Compiler durchwinken kann. Damit hat man die C++ Datentypen auch quasi geschenkt zur Verfügung. Wer schon ein bisschen C++ gemacht hat, ahnt die Möglichkeiten, die sich dadurch ergeben.

Im Moment pausiert das Projekt Breeze wieder seit fünf Wochen, weil die stille Corona-Zeit vorüber ist. Aber ich bin wohlgemut, auch für meine Programmiernachfolger, dass all unser bestehender Code auch in 20 oder 40 Jahren noch nutzbar sein wird.

Meine Zukunftsaussichten sind also alles andere als trübe und ich bekomme richtig Speichelfluss bei dem Gedanken, was ich in meinem Leben noch alles programmieren und dabei erleben werde. Wenn da nur nicht so viel anderes auf meiner Bucket List stünde. Aber bald habe ich ja wieder Urlaub und mir bleiben hoffentlich noch ein paar Jahre.

Viele Grüße
Michael
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: Xbase++ Engpässe, gibt es eine Möglichkeit, Sie zu umgehen?

Beitrag von AUGE_OHR »

hi,

ich nutzte harbour statt "Breeze" was im Prinzip das selbe macht.

existiert seit 30 Jahren und die "Wrapper" für LIBs sind schon vorhanden.
Vorteil : es arbeiten weltweit Leute an der selben Sache
gruss by OHR
Jimmy
Antworten