6 ms·

Tweet text for the Twitter haters: > I wrote a synthetic program generator that can target different languages so I can get measurements across a bunch of diff

Tweet text for the Twitter haters: > I wrote a synthetic program generator that can target different languages so I can get measurements across a bunch of different languages and compilers while varying the generator parameters. So far the champ among modern compilers is TCC and Delphi among historical compilers. > Even when running under a Windows 98 VM, Delphi 2 can compile large .pas files at 1.2 million lines per second. TCC comes in at 0.7 million lines per second. This is on a 2.5 GHz Skylake laptop. > All the modern Pascal compilers I could find did very poorly on the same benchmark workloads. Lazarus/FreePascal at 55 kloc/sec, Embarcadero Delphi at 15 kloc/sec. So 1.2 million lines/sec, running through a VM, on laptop hardware.

pwdisswordfish4 6y ago
Not surprising that TCC is slower; Pascal is much easier to parse then C.
- FullyFunctional 6y ago
  More to the point, Wirth _designed_ Pascal to be one-pass translatable. Anders Hejlsberg took advantage of this in his succession of Pascal compilers: BLS Pascal (= Nascom Pascal), Compas Pascal, and Turbo Pascal. (Delphi is an evolution of Turbo Pascal but I don't know if he was involved).
  - wenc 6y ago
    Anders Hejlsberg was the chief architect for Delphi at Borland, and at Microsoft he was lead architect for C# and Typescript.
    - pjmlp 6y ago
      And J++.
    - signaru 6y ago
      I always find it interesting how Danes are great at making programming languages. Anders perhaps being the most prolific among them.
      - DonHopkins 6y ago
        I'm curious which other Danes have made great programming languages too? Not that I doubt you, but Anders Hejlsberg is just so incredibly prolific and has developed so many great programming languages over such a long time, that it's easy to mistake him for a bunch of different Danish people at once! ;) It's hard to believe one person did all that! The world also has the great Danes to thank for the Hundeprutterutchebane. https://en.wikipedia.org/wiki/Hundeprutterutchebane https://en.wikipedia.org/wiki/Hundeprutterutchebane https://www.youtube.com/watch?v=oL8az1fV1Tw https://www.youtube.com/watch?v=oL8az1fV1Tw
        wenc 6y ago
        Danes have been disproportionately successful at creating high impact languages and tools. (Canadians too) Here’s a list. Anders Hejlsberg (came up with Turbo Pascal, lead architect for C#) Bjarne Stoustrup (came up with C++) David Heinemeier Hansson (created Ruby on Rails) Lars Bak (created V8 Javascript VM for Google Chrome) Peter Naur (Turing Award winner, contributed to ALGOL 60) Rasmus Lerdorf (created PHP, born in Greenland) https://www.friism.com/famous-danish-programmers/ https://www.friism.com/famous-danish-programmers/
        FullyFunctional 6y ago
        Dane here. I have a few more to the list (and surely many I forgot): - You mentioned Peter Naur, but I must point out that he's the 'N' in BNF - Per Brinch Hansen (concurrent Pascal, brought us monitors) - Ole Lehrmann (BETA) ... I think it's a network effect. Early practitioners in Denmark had a PL focus and fostered the next generation.
yumaikas 6y ago
I suspect those modern compilers are also optimizing more than Delphi 2 was, and are probably parsing a somehow larger language. Granted, it could be a case of a code base adapting to change poorly over time.
- magicalhippo 6y ago
  Due to certain language features that's been added, like generics, the binaries can also be a lot larger. So could very well be IO constraints. At work we currently use Delphi 10.3 (10.4 was recently released), and it compiles and links ~1Mloc in less than 10 seconds, on my older 4770k with a Samsung 850 SATA SSD.
- spatulon 6y ago
  I follow the tweet author (Per) and I know he's a big fan of building compilers in the style of Niklaus Wirth. I think the idea is that modern compilers generate very inefficient code first, and then have many expensive optimization passes, while Wirth advocated for simpler compilers that just generated reasonably efficient code in a single pass. > parsing a somehow larger language That would also explain it, but I think it's appropriate to acknowledge the effect it has on compile times when you add complexity to the language. A lot of folks avoid C++ features (or the language entirely) simply because they would inflate compilation times too much, and it clearly wasn't a priority for the language committee when those features were added.
ReactiveJelly 6y ago
I can't think why Windows 98 would slow it down. If the VM is using VM acceleration, it would be near full speed. The only reason 98 matters is that it's probably 32-bit not 64-bit. But if Delphi runs on Windows 98 then it probably is 32-bit too.
- oso2k 6y ago
  FAT32 is not a very fast filesystem. Things like caching are necessary to make it performant. Also, the IO subsystems in Win98 sometimes chose slow paths or interfaces.
  - laumars 6y ago
    Have you got any benchmarks to back up FAT32 being slow? FAT32 has no journaling, ACLs, transactions, CoW, nor any of the other advancements that many modern file systems do (remember we are talking FAT32 and not exFAT which modern systems use when falling back to a FAT32-like file system). Yes caching was required but that was as much to work around slow storage mediums (as was the norm back then) and in fact that capability is built into the OS rather than the file system and is used by all file systems. This is the same for Windows 9x, NT, and even Linux and UNIXes too (ZFS on Linux is the one exception I know of where caching happens within the file system driver). Sure, Win 98 might might a few IO optimisations, I think DMA might even be disabled by default, but it’s also a much lighter OS than modern contemporaries and that will make a hell of a difference too. Remember 98 was designed to run on hardware less powerful than a 10 year old smart phone and the entire OS has a install footprint of around 300MB. There’s going to be less background processes (and particularly on a VM install specifically for Delphi 2 benchmarks). The only draw back is you wouldn’t have SMP; but that doesn’t always help with software compilers because they are traditionally single threaded processes.
    - oso2k 6y ago
      FAT32 isn't often included these days in Linux FS benchmarks [0] but some older benchmarks [1] also show noticeable performance differences, especially when the workload is more meaningful than copy files. Lack of features does not imply efficient design. Caching was optional with Windows 98 and sometimes was turned off by default, depending on how the drive was formatted (partition type) and the IO driver (BIOS, LBA, OEM) loaded. The referenced Linux benchmarks probably limit the variability here since I think Linux tends to follow the same code paths, independent of the partition types. BTW, Windows benchmarks tend to follow same pattern of FAT32 being slower than newer filesystems. [2][3][4] [0] https://www.phoronix.com/scan.php?page=article&item=linux_usb_fs&num=2 https://www.phoronix.com/scan.php?page=article&item=linux_us... [1] https://web.archive.org/web/20010627181258/http://bulma.lug.net/body.phtml?nIdNoticia=626 https://web.archive.org/web/20010627181258/http://bulma.lug.... [2] https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_comparison.html https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_c... [3] https://www.sami-lehtinen.net/blog/exfat-fat32-ntfs-real-life-performance-test https://www.sami-lehtinen.net/blog/exfat-fat32-ntfs-real-lif... [4] https://www.tomshardware.com/reviews/ssd-file-system-ntfs,3166-5.html https://www.tomshardware.com/reviews/ssd-file-system-ntfs,31...

pwdisswordfish4 6y ago

Not surprising that TCC is slower; Pascal is much easier to parse then C.

FullyFunctional 6y ago
More to the point, Wirth _designed_ Pascal to be one-pass translatable. Anders Hejlsberg took advantage of this in his succession of Pascal compilers: BLS Pascal (= Nascom Pascal), Compas Pascal, and Turbo Pascal. (Delphi is an evolution of Turbo Pascal but I don't know if he was involved).
- wenc 6y ago
  Anders Hejlsberg was the chief architect for Delphi at Borland, and at Microsoft he was lead architect for C# and Typescript.
  - pjmlp 6y ago
    And J++.
  - signaru 6y ago
    I always find it interesting how Danes are great at making programming languages. Anders perhaps being the most prolific among them.
    - DonHopkins 6y ago
      I'm curious which other Danes have made great programming languages too? Not that I doubt you, but Anders Hejlsberg is just so incredibly prolific and has developed so many great programming languages over such a long time, that it's easy to mistake him for a bunch of different Danish people at once! ;) It's hard to believe one person did all that! The world also has the great Danes to thank for the Hundeprutterutchebane. https://en.wikipedia.org/wiki/Hundeprutterutchebane https://en.wikipedia.org/wiki/Hundeprutterutchebane https://www.youtube.com/watch?v=oL8az1fV1Tw https://www.youtube.com/watch?v=oL8az1fV1Tw
      - wenc 6y ago
        Danes have been disproportionately successful at creating high impact languages and tools. (Canadians too) Here’s a list. Anders Hejlsberg (came up with Turbo Pascal, lead architect for C#) Bjarne Stoustrup (came up with C++) David Heinemeier Hansson (created Ruby on Rails) Lars Bak (created V8 Javascript VM for Google Chrome) Peter Naur (Turing Award winner, contributed to ALGOL 60) Rasmus Lerdorf (created PHP, born in Greenland) https://www.friism.com/famous-danish-programmers/ https://www.friism.com/famous-danish-programmers/
        FullyFunctional 6y ago
        Dane here. I have a few more to the list (and surely many I forgot): - You mentioned Peter Naur, but I must point out that he's the 'N' in BNF - Per Brinch Hansen (concurrent Pascal, brought us monitors) - Ole Lehrmann (BETA) ... I think it's a network effect. Early practitioners in Denmark had a PL focus and fostered the next generation.

yumaikas 6y ago

I suspect those modern compilers are also optimizing more than Delphi 2 was, and are probably parsing a somehow larger language. Granted, it could be a case of a code base adapting to change poorly over time.

magicalhippo 6y ago
Due to certain language features that's been added, like generics, the binaries can also be a lot larger. So could very well be IO constraints. At work we currently use Delphi 10.3 (10.4 was recently released), and it compiles and links ~1Mloc in less than 10 seconds, on my older 4770k with a Samsung 850 SATA SSD.
spatulon 6y ago
I follow the tweet author (Per) and I know he's a big fan of building compilers in the style of Niklaus Wirth. I think the idea is that modern compilers generate very inefficient code first, and then have many expensive optimization passes, while Wirth advocated for simpler compilers that just generated reasonably efficient code in a single pass. > parsing a somehow larger language That would also explain it, but I think it's appropriate to acknowledge the effect it has on compile times when you add complexity to the language. A lot of folks avoid C++ features (or the language entirely) simply because they would inflate compilation times too much, and it clearly wasn't a priority for the language committee when those features were added.

ReactiveJelly 6y ago

I can't think why Windows 98 would slow it down. If the VM is using VM acceleration, it would be near full speed. The only reason 98 matters is that it's probably 32-bit not 64-bit. But if Delphi runs on Windows 98 then it probably is 32-bit too.

oso2k 6y ago
FAT32 is not a very fast filesystem. Things like caching are necessary to make it performant. Also, the IO subsystems in Win98 sometimes chose slow paths or interfaces.
- laumars 6y ago
  Have you got any benchmarks to back up FAT32 being slow? FAT32 has no journaling, ACLs, transactions, CoW, nor any of the other advancements that many modern file systems do (remember we are talking FAT32 and not exFAT which modern systems use when falling back to a FAT32-like file system). Yes caching was required but that was as much to work around slow storage mediums (as was the norm back then) and in fact that capability is built into the OS rather than the file system and is used by all file systems. This is the same for Windows 9x, NT, and even Linux and UNIXes too (ZFS on Linux is the one exception I know of where caching happens within the file system driver). Sure, Win 98 might might a few IO optimisations, I think DMA might even be disabled by default, but it’s also a much lighter OS than modern contemporaries and that will make a hell of a difference too. Remember 98 was designed to run on hardware less powerful than a 10 year old smart phone and the entire OS has a install footprint of around 300MB. There’s going to be less background processes (and particularly on a VM install specifically for Delphi 2 benchmarks). The only draw back is you wouldn’t have SMP; but that doesn’t always help with software compilers because they are traditionally single threaded processes.
  - oso2k 6y ago
    FAT32 isn't often included these days in Linux FS benchmarks [0] but some older benchmarks [1] also show noticeable performance differences, especially when the workload is more meaningful than copy files. Lack of features does not imply efficient design. Caching was optional with Windows 98 and sometimes was turned off by default, depending on how the drive was formatted (partition type) and the IO driver (BIOS, LBA, OEM) loaded. The referenced Linux benchmarks probably limit the variability here since I think Linux tends to follow the same code paths, independent of the partition types. BTW, Windows benchmarks tend to follow same pattern of FAT32 being slower than newer filesystems. [2][3][4] [0] https://www.phoronix.com/scan.php?page=article&item=linux_usb_fs&num=2 https://www.phoronix.com/scan.php?page=article&item=linux_us... [1] https://web.archive.org/web/20010627181258/http://bulma.lug.net/body.phtml?nIdNoticia=626 https://web.archive.org/web/20010627181258/http://bulma.lug.... [2] https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_comparison.html https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_c... [3] https://www.sami-lehtinen.net/blog/exfat-fat32-ntfs-real-life-performance-test https://www.sami-lehtinen.net/blog/exfat-fat32-ntfs-real-lif... [4] https://www.tomshardware.com/reviews/ssd-file-system-ntfs,3166-5.html https://www.tomshardware.com/reviews/ssd-file-system-ntfs,31...