Compiler am Limit

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut

Compiler am Limit

Beitragvon Mathias » 26. Jul 2018, 20:28 Compiler am Limit

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 4342
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Thandor » 27. Jul 2018, 10:53 Re: Compiler am Limit

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.
Thandor
 
Beiträge: 118
Registriert: 30. Jan 2010, 18:17
Wohnort: Berlin
OS, Lazarus, FPC: Windows 10 64Bit/ lazarus 1.6 mit FPC 3.0.0 (32Bit) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Timm Thaler » 27. Jul 2018, 13:07 Re: Compiler am Limit

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.
Timm Thaler
 
Beiträge: 730
Registriert: 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
Nach oben

Beitragvon Erwin » 27. Jul 2018, 13:16 Re: Compiler am Limit

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?
Win 7 / Lazarus 1.6 / FP 3.0.0 / x86_64-win64-win32/win64
Erwin
 
Beiträge: 216
Registriert: 16. Sep 2009, 13:15
OS, Lazarus, FPC: Xubuntu 16.04 / x86_64_linux-gtk 2 / L 1.6+dfsg-1 / FPC 3.0.0 | 
Nach oben

Beitragvon Mathias » 27. Jul 2018, 13:24 Re: Compiler am Limit

Was ich noch vergessen zu sagen habe, ich habe es mit einem 64Bit Compiler probiert.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 4342
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Erwin » 27. Jul 2018, 13:44 Re: Compiler am Limit

Meins sollte ebenfalls eine 64-bit-Version sein.
Win 7 / Lazarus 1.6 / FP 3.0.0 / x86_64-win64-win32/win64
Erwin
 
Beiträge: 216
Registriert: 16. Sep 2009, 13:15
OS, Lazarus, FPC: Xubuntu 16.04 / x86_64_linux-gtk 2 / L 1.6+dfsg-1 / FPC 3.0.0 | 
Nach oben

Beitragvon Warf » 27. Jul 2018, 14:56 Re: Compiler am Limit

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
Warf
 
Beiträge: 985
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

Beitragvon Mathias » 27. Jul 2018, 15:46 Re: Compiler am Limit

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 4342
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Erwin » 27. Jul 2018, 16:43 Re: Compiler am Limit

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.
Win 7 / Lazarus 1.6 / FP 3.0.0 / x86_64-win64-win32/win64
Erwin
 
Beiträge: 216
Registriert: 16. Sep 2009, 13:15
OS, Lazarus, FPC: Xubuntu 16.04 / x86_64_linux-gtk 2 / L 1.6+dfsg-1 / FPC 3.0.0 | 
Nach oben

Beitragvon Erwin » 27. Jul 2018, 16:51 Re: Compiler am Limit

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.
Win 7 / Lazarus 1.6 / FP 3.0.0 / x86_64-win64-win32/win64
Erwin
 
Beiträge: 216
Registriert: 16. Sep 2009, 13:15
OS, Lazarus, FPC: Xubuntu 16.04 / x86_64_linux-gtk 2 / L 1.6+dfsg-1 / FPC 3.0.0 | 
Nach oben

Beitragvon Mathias » 27. Jul 2018, 17:04 Re: Compiler am Limit

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 4342
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Warf » 27. Jul 2018, 17:15 Re: Compiler am Limit

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
Warf
 
Beiträge: 985
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

Beitragvon Mathias » 27. Jul 2018, 17:19 Re: Compiler am Limit

- 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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 4342
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Mathias » 27. Jul 2018, 17:20 Re: Compiler am Limit

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 4342
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Warf » 27. Jul 2018, 17:22 Re: Compiler am Limit

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 27. Jul 2018, 17:27, insgesamt 1-mal geändert.
Warf
 
Beiträge: 985
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

» Weitere Beiträge siehe nächste Seite »
Nächste

Zurück zu Freepascal



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste

porpoises-institution
accuracy-worried