6 ms·

C was faster. It's that simple. Computers were extremely tiny in those days.

pjmlp 5y ago
Fast where? Borland compilers were basically the same, and if one cared about speed, the only way to achieve it was hand written Assembly.
- the-dude 5y ago
  I don't know if the Pascal code ran slower, but the Borland compilers were plenty fast.
  - davidhbolton 5y ago
    Turbo Pascal was a very fast compiler, written in assembler. I'm a Delphi developer, and have spent about 24 of the past 36 years programming in Pascal. The Delphi XE7 compiler (now about 8 years old) can on a one year old Lenovo laptop with 16 GB RAM compile 1.35 million LOC (in 80 different files) in 11 seconds. The 64-bit compile takes roughly twice as long. One of the design features of Pascal was a one pass compile which explains the speed. Note also that the Delphi/Turbo Pascal compilers are smart and discard all unused code.
- neverartful 5y ago
  Speaking of speed, Turbo Pascal's compile speed was lightning fast.
einr 5y ago
Pascal was super popular for applications development on the original 68k Macs, Amigas and Atari ST's. I don't know if these machines fall into your "extremely tiny" envelope but we're talking 68000 @ 7 MHz with usually 512K or maybe 1M of RAM. A little later, Turbo Pascal ran like greased lightning on a 386 or 486 box. There was really nothing else like it, which is partly why it enjoyed such immense popularity.
- ncmncm 5y ago
  Macs were never programmed in Pascal, but in a variant dialect called Object Pascal. Turbo Pascal compiled fast. The generated code ran at more or less the same speed as output of random other compilers.
  - Tozen 5y ago
    The line between Pascal and Object Pascal is very small. Some people might be thinking of the relationship between C and C++, but it is a different situation with Pascal and Object Pascal. Object Pascal is an extension of Pascal. For instance, many of Apple's Object Pascal extensions were incorporated into Turbo Pascal. From Turbo Pascal version 5.5 and up, it is Borland's version of Object Pascal. You can use Objects and do OOP in Turbo Pascal.
cagey 5y ago
Along those lines... on MS-DOS/x86, memory model support in (Turbo) Pascal was less flexible than in Turbo C (1.0) during the first years when those toolchains were competing and gaining critical mass: TP 3.0 generated COM files (near code, near data, far heap-allocated data). TP 4.0 generated EXE files (far code, near data, far heap-allocated data). (the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)). A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition). Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm). Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die. [edit] Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).
- pjmlp 5y ago
  Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. And Turbo C 2.0 was quickly replaced by Turbo C++.
  - cagey 5y ago
    > Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform. (Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations. My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++). [1] https://en.wikipedia.org/wiki/Microsoft_Pascal https://en.wikipedia.org/wiki/Microsoft_Pascal
deleted 5y ago
[deleted]
guenthert 5y ago
There's no reason to believe that the language would be. Performance of the compiled code clearly depends on the quality of the compiler. Iirc, Turbo Pascal passed arguments to functions in registers when it could, C compilers back then didn't. Pascal's calling convention also used less space (hence it being an optimization option on some C compilers). On a 8 bit machine, that was important, less so on the 32 bit machines of the 90s. In the eighties C was considered slow. If you needed performance, you coded (the relevant part) in assembly (or machine code). C actually allows you (for the better or worse) to incorporate assembly code right within a C program, a desirable feature then. Turbo Pascal (on CP/M) only offered the same for machine code. While I was fond of Turbo Pascal in its days, C was just so much more flexible.

Fast where? Borland compilers were basically the same, and if one cared about speed, the only way to achieve it was hand written Assembly.

the-dude 5y ago
I don't know if the Pascal code ran slower, but the Borland compilers were plenty fast.
- davidhbolton 5y ago
  Turbo Pascal was a very fast compiler, written in assembler. I'm a Delphi developer, and have spent about 24 of the past 36 years programming in Pascal. The Delphi XE7 compiler (now about 8 years old) can on a one year old Lenovo laptop with 16 GB RAM compile 1.35 million LOC (in 80 different files) in 11 seconds. The 64-bit compile takes roughly twice as long. One of the design features of Pascal was a one pass compile which explains the speed. Note also that the Delphi/Turbo Pascal compilers are smart and discard all unused code.
neverartful 5y ago
Speaking of speed, Turbo Pascal's compile speed was lightning fast.

einr 5y ago

Pascal was super popular for applications development on the original 68k Macs, Amigas and Atari ST's. I don't know if these machines fall into your "extremely tiny" envelope but we're talking 68000 @ 7 MHz with usually 512K or maybe 1M of RAM. A little later, Turbo Pascal ran like greased lightning on a 386 or 486 box. There was really nothing else like it, which is partly why it enjoyed such immense popularity.

ncmncm 5y ago
Macs were never programmed in Pascal, but in a variant dialect called Object Pascal. Turbo Pascal compiled fast. The generated code ran at more or less the same speed as output of random other compilers.
- Tozen 5y ago
  The line between Pascal and Object Pascal is very small. Some people might be thinking of the relationship between C and C++, but it is a different situation with Pascal and Object Pascal. Object Pascal is an extension of Pascal. For instance, many of Apple's Object Pascal extensions were incorporated into Turbo Pascal. From Turbo Pascal version 5.5 and up, it is Borland's version of Object Pascal. You can use Objects and do OOP in Turbo Pascal.

cagey 5y ago

Along those lines... on MS-DOS/x86, memory model support in (Turbo) Pascal was less flexible than in Turbo C (1.0) during the first years when those toolchains were competing and gaining critical mass: TP 3.0 generated COM files (near code, near data, far heap-allocated data). TP 4.0 generated EXE files (far code, near data, far heap-allocated data). (the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)). A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition). Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm). Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die. [edit] Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).

pjmlp 5y ago
Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. And Turbo C 2.0 was quickly replaced by Turbo C++.
- cagey 5y ago
  > Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform. (Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations. My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++). [1] https://en.wikipedia.org/wiki/Microsoft_Pascal https://en.wikipedia.org/wiki/Microsoft_Pascal

deleted 5y ago

[deleted]

guenthert 5y ago

There's no reason to believe that the language would be. Performance of the compiled code clearly depends on the quality of the compiler. Iirc, Turbo Pascal passed arguments to functions in registers when it could, C compilers back then didn't. Pascal's calling convention also used less space (hence it being an optimization option on some C compilers). On a 8 bit machine, that was important, less so on the 32 bit machines of the 90s. In the eighties C was considered slow. If you needed performance, you coded (the relevant part) in assembly (or machine code). C actually allows you (for the better or worse) to incorporate assembly code right within a C program, a desirable feature then. Turbo Pascal (on CP/M) only offered the same for machine code. While I was fond of Turbo Pascal in its days, C was just so much more flexible.