Compiler am Limit

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Mathias
Beiträge: 6164
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Compiler am Limit

Beitrag von Mathias »

Ich habe gerade den Compiler ans Limit gebracht.

Code: Alles auswählen

const
  ic1 = 400000000000;
  ic0 = 1000000000;
var
  Size: array[0..ic1 - 1] of Single;
 
  Data: record
    Size: array[0..ic0 - 1] of Single;
    Color: array[0..ic0 - 1] of array[0..2] of Single;
  end;


Die erste Deklaration Size frisst er ohne Probleme.
Aber bei der zweiten Data, kommt folgende Fehlermeldung:

Code: Alles auswählen

unit1.pas(42,3) Error: Data element too large


Wieso motzt der Compiler bei der Daklaration Size nicht, obwohl die 100x mehr Speicher braucht als Data ?

Ich weis, dies sind Fantasiewerte, aber trozdem etwas merkwürdig. :roll:

So nebenbei wen ich nur Size stehen lasse, dann motz der Linker.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Thandor
Beiträge: 153
Registriert: Sa 30. Jan 2010, 18:17
OS, Lazarus, FPC: Windows 10 64Bit/ lazarus 3.0 mit FPC 3.2.2 (32Bit + 64bit)
CPU-Target: 64Bit
Wohnort: Berlin

Re: Compiler am Limit

Beitrag von Thandor »

Wenn Du eine Kiste hast und dort etwas reinlegst, was 3/4 der Kiste in anspruch nimmt und dann Legosteine reinfüllen möchtest, die, von der Anzahl her, mehr als 1/4 der Kiste in anspruch nehmen würden, dann ist deine Kiste voll, obwohl die Legosteine kleiner sind als das erste Teil.

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: Compiler am Limit

Beitrag von Timm Thaler »

Könnte sein, dass er das size-Array noch nicht anlegt, sondern erstmal zu Kenntnis nimmt. Die Arrays im record versucht er aber anzulegen, weil die ja voneinander abhängig sind. Und immerhin sind das auch 16 GB.

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Compiler am Limit

Beitrag von Erwin »

Dessen Meldungen hängen dann aber scheinbar von den Einstellungen ab. Aber im Kern stimme ich da Timm Thaler zu. Zumindest erklärt dies einiges.

Weil bei mir mir treten allein schon beim Const ic1 Fehlermeldungen auf, mit dehnen ich aber nichts wirklich anfangen kann. Also bei der Zeile von Size.
So bald ich aber paar Nullen (mindestens 3) weg mache, geht es.
Also scheinbar wird bei normaler Zuweisung tatsächlich die Größe ignoriert wird, während beim Record dies dann überprüft wird?

ic0 ist auch zu groß. Da musste ich dann auch eine 0 weg machen. Mir deren Größe ging aber nur einfaches Array. Data hingegen ging nicht. Vermute aber mal, dass beim Record eben alles zusammen zählt? Also statt die Array einzeln für sich Platz benötigen, sich die beiden Array den Platz teilen müssen. Aber da dies nach einfacher Rechnung 4 mal so groß ist, somit in meinen Test dann genau so groß wie ic1 ... vermutlich kommt für dessen Aufteilung eines Records etc. noch mal weiter Platzbedarf dazu, der dann insgesamt knapp(?) zu groß ist?
Lazarus 2.2.0 / FP 3.2.4

Mathias
Beiträge: 6164
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Compiler am Limit

Beitrag von Mathias »

Was ich noch vergessen zu sagen habe, ich habe es mit einem 64Bit Compiler probiert.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Compiler am Limit

Beitrag von Erwin »

Meins sollte ebenfalls eine 64-bit-Version sein.
Lazarus 2.2.0 / FP 3.2.4

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Compiler am Limit

Beitrag von Warf »

Timm Thaler hat geschrieben:Und immerhin sind das auch 16 GB.


Nur so nebenbei, Windows 7 Home premium 64 Bit kann nur 16 GB virtuellen Addressraum verwalten. Das heißt wer sich in diesen Größenordnungen aufhält hat meist schon verloren.

Zu dem Problem, grundsätzlich ist das verhalten beim record zu erwarten. Das liegt daran das das Data Segment (der teil der Memory in der die Read/Write globalen Variablen liegen) vom Betriebsystem limitiert wird. Ähnlich zu der Stacksize kann man das aber auch ändern. Unter Linux z.B. ulimit -d unlimited. Das gilt aber nur für Prozesse, und sollte den FPC nicht aufhalten. Daher denke ich das der FPC selbst einen check drin hat.

Die frage ist also, warum das für den Array nicht gemacht wird. Wie erwartet ist das datasegment zu groß, mit:

Code: Alles auswählen

 
      const
  ic1 = 400000000000;
var
  Size: array[0..ic1 - 1] of Single;
 
begin
  WriteLn(IntPtr(@Size[0]));
end

Kann das programm unter Windows 10 64 bit nicht ausgeführt werden. Das heißt der Fehler ist das der fpc die größenchecks es nicht erkennt für arrays. Ich schätze da hast du einen echten Bug gefunden

Mathias
Beiträge: 6164
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Compiler am Limit

Beitrag von Mathias »

Nur so nebenbei, Windows 7 Home premium 64 Bit kann nur 16 GB virtuellen Addressraum verwalten.

Ist dies nicht ein bisschen wenig ?
Ein alter 80386 hat schon 16TByte virtueller Adressraum.
Oder hat das M$ künstlich reduziert ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Compiler am Limit

Beitrag von Erwin »

Mathias hat geschrieben:
Nur so nebenbei, Windows 7 Home premium 64 Bit kann nur 16 GB virtuellen Addressraum verwalten.

Ist dies nicht ein bisschen wenig ?
Ein alter 80386 hat schon 16TByte virtueller Adressraum.
Oder hat das M$ künstlich reduziert ?

16TByte? Mit 80386? Das sind doch die alten, vor den Pentium herausgekommen super stabilen Rechner, so weit ich mich erinnere? Das damals waren doch die schönen 8-Bit Zeiten?
Habe mich kurz auf Wikipedia schlau gemacht, weil mich das auch ein wenig interessiert hat:
Der soll 1985 rausgekommen sein (bis 2007).
32-Bit soll er gewesen sein. Wahnsinn. Wieso hat man mir das bis Heute keiner gesagt? 32-Bit Hardware zu Zeiten, wo die Programme 8-Bit waren?!
64TiB logischer Adressraum.
Also wenn logischer gleich virtuell ist, dann dürfte es hinkommen.

Und ja, MS tut oft gerne Künstlich reduzieren, so weit ich es gehört und gar mitbekommen habe. Home-Version. Vermute mal, das hat was damit zu tun. Weiß nicht mehr, wie die Version nach Home heißt, aber vermute mal, dass diese dann eben auch im Speicherbereich mehr kann, also nicht mehr Beschränkt ist.
Lazarus 2.2.0 / FP 3.2.4

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Compiler am Limit

Beitrag von Erwin »

Ich habe auf Wikipedia nachgesehen. Laut deren Artikel zu Windows 7:

Windows 7
- Starter: Nur 32-Bit Version, Arbeitsspeicher auf 2 GB beschränkt.
- Home Basic: 32-Bit bis 4 GB, 64-Bit bis 8 GB Arbeitsspeicher.
- Home Premium: auf 16 GB Arbeitsspeicher beschränkt.
- Professional: 192 GB Arbeitsspeicher.
Lazarus 2.2.0 / FP 3.2.4

Mathias
Beiträge: 6164
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Compiler am Limit

Beitrag von Mathias »

Der soll 1985 rausgekommen sein (bis 2007).
32-Bit soll er gewesen sein. Wahnsinn. Wieso hat man mir das bis Heute keiner gesagt? 32-Bit Hardware zu Zeiten, wo die Programme 8-Bit waren?!

8Bit höchsten auf Heim-Computern. Der PC hatte schon immer 16Bit, auch der 8086er.
Aber es stimmt, ein 386er hatte schon sehr viel Power, aber von M$ wurde dies erst einigermassen mit Win95 genutze, ops M$ brauchte 10 Jahre für ein einigermassen zeitgemässes OS zu entwickeln. Aber Games habe dies Leistung schon sehr früh ausgenutzt, diese sind zum Teil die Beschränkung von MS-DOS umgangen. M$ konnte erst mit Win-NT 32Bit-CPUs ausreizen.
Wie es mit UNIX aussah, kann ich nicht sagen.
Ein Wunder, es es ein 64Bit OS von M$ gibt. :mrgreen:

Schon der 80286 konnte theoretisch 4GByte virtuellen Speicher verwalten und dies mit 16Bit. :shock:
Vorausgesetzt, für jedes Segment wurden 64KByte reserviert, was in der Praxis nie der Fall ist.
64'000 Segment à 64KByte gibt 4GByte.
Dies natürlich nur im Protected-Mode.
Nur gab es kein vernünftiges OS, welches dies ausnutze. Win3.1 konnte nur den physikalischen Speicher des 80286 nutzen, und dieser war bei 16MByte fertig, etwas ging noch für BIOS und VRAM weg. Dies ist sogar auf einem modernen i7 noch der Fall.

Linux war schon immer ein Schritt voraus, was die Ausnutzung der Systeminternen Hardware anbelangte.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Compiler am Limit

Beitrag von Warf »

Erwin hat geschrieben:Und ja, MS tut oft gerne Künstlich reduzieren, so weit ich es gehört und gar mitbekommen habe. Home-Version. Vermute mal, das hat was damit zu tun. Weiß nicht mehr, wie die Version nach Home heißt, aber vermute mal, dass diese dann eben auch im Speicherbereich mehr kann, also nicht mehr Beschränkt ist.


Wenn du von anfang an ein Hardlimit für den Ram hast, kannst du einfach viel effizientere Allokationstabellen bauen. Z.B. das höchste was Windows unterstützt ist aktuell (Windows 10) 512GB. Da man in einem Realistischen Scenario normalerweise nicht mehr braucht, hat Microsoft sich für diese Beschränkung entschieden, nicht weil sie nicht mehr könnten, sondern einfach weil sich der mehr aufwand, und der effizienzverlust nicht lohnen würde für die 3 nutzer die tatsächlich mehr als 512 GB ram haben

Mathias
Beiträge: 6164
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Compiler am Limit

Beitrag von Mathias »

- Starter: Nur 32-Bit Version, Arbeitsspeicher auf 2 GB beschränkt.
Das ist physikalisch vorgegeben, da es bei 32Bit mit 4GByte Schluss ist. Etwas ging noch für den Erweiterungskarten weg, zB. Grafikkarte. Irgendwie konnte man aber für Win 3GByte verwenden.

- Home Basic: 32-Bit bis 4 GB, 64-Bit bis 8 GB Arbeitsspeicher.
Wie will da Win 32Bit 4GByte verwenden, wen da noch etwas für die Grafik weg geht. :roll:

- Professional: 192 GB Arbeitsspeicher.
Sogar diese Version ist beschränkt. :cry:

Auch bei Win31/Win95, ging nicht viel mehr als 64MByte, bei mehr Speicher wurden diese OS instabil, wieso auch immer.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Mathias
Beiträge: 6164
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Compiler am Limit

Beitrag von Mathias »

Wenn du von anfang an ein Hardlimit für den Ram hast, kannst du einfach viel effizientere Allokationstabellen bauen. Z.B. das höchste was Windows unterstützt ist aktuell (Windows 10) 512GB.
Und wieso hat Linux diese Beschränkungen nicht ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Compiler am Limit

Beitrag von Warf »

Mathias hat geschrieben:8Bit höchsten auf Heim-Computern. Der PC hatte schon immer 16Bit, auch der 8086er.
Aber es stimmt, ein 386er hatte schon sehr viel Power, aber von M$ wurde dies erst einigermassen mit Win95 genutze, ops M$ brauchte 10 Jahre für ein einigermassen zeitgemässes OS zu entwickeln. Aber Games habe dies Leistung schon sehr früh ausgenutzt, diese sind zum Teil die Beschränkung von MS-DOS umgangen. M$ konnte erst mit Win-NT 32Bit-CPUs ausreizen.
Wie es mit UNIX aussah, kann ich nicht sagen.
Ein Wunder, es es ein 64Bit OS von M$ gibt. :mrgreen:

Schon der 80286 konnte theoretisch 4GByte virtuellen Speicher verwalten und dies mit 16Bit. :shock:
Vorausgesetzt, für jedes Segment wurden 64KByte reserviert, was in der Praxis nie der Fall ist.
64'000 Segment à 64KByte gibt 4GByte.
Dies natürlich nur im Protected-Mode.
Nur gab es kein vernünftiges OS, welches dies ausnutze. Win3.1 konnte nur den physikalischen Speicher des 80286 nutzen, und dieser war bei 16MByte fertig, etwas ging noch für BIOS und VRAM weg. Dies ist sogar auf einem modernen i7 noch der Fall.

Linux war schon immer ein Schritt voraus, was die Ausnutzung der Systeminternen Hardware anbelangte.


Man muss aber auch dazu sagen das damals Linux von einem laien praktisch nicht installierbar war. Ich kann mich noch gut daran erinnern wie ich mein erstes Linux installiert habe und das weder USB noch Ethernet noch Wifi treiber hatte, und ich um diese treiber zu installieren die festplatte über einen zweiten sata anschluss in einen anderen rechner stecken, und dann die dateien rüberkopieren. (Eigentlich war das sogar mein zweiter versuch, mein erster versuch etwas vorher ist bereits schon am grafiktreiber gescheitert)
Zuletzt geändert von Warf am Fr 27. Jul 2018, 18:27, insgesamt 1-mal geändert.

Antworten