4 Thread die auf einer CPU laufen sind langsamer als 4 x CPU ... klar muss die Software dazu fähig sein.steffen.pirsig hat geschrieben: ↑Mi, 31. Jul 2019 20:09 Für die Akten: Ein Thread auf einer CPU skaliert unter exakt zwei Randbedingungen:
Ich kenne die Diskussionen mit den harbour Leuten warum es bei Xbase++ mit Thread (seit v1.5x ?) "anderes" ist ...
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 ...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.
---
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.