I’m revisiting this topic because I still truly don’t understand it.
Why is a LANGUAGE always equated with the speed of the compiled result? If everything goes into the same machine language, why can’t someone create a compiler that makes fast - fastest - compiled code regardless of the language?
Think about it: I can write a loop in C and a loop in BASIC and it’s only semantics - the tokens - that differentiate them. Why WOULDN’T a compiler create the exact same machine code for each? They mean the exact same thing.
To hypothetisize: why couldn’t some whizkid make a compiler that created FASTER code than the common C compilers? Or at least identically as fast? Isn’t it all the same machine code?
I don’t see anything in the semantics of C that makes it any superior to be FASTER than BASIC. I’ve written C->BASIC translators and BASIC->C translators. The differences between languages are SEMANTIC, and any differences have to do with efficiency of INPUT, not efficiency of OUTPUT.
So why, constantly, is the language equated with performance?
This goes back since the beginning of programming. Back in the day, most BASIC applications used to be interpreted (much like scripts are), and not compiled to a lower-level machine code. That, and it was based on English syntax, which made it easy to use… which made it perfect for beginners. Because of this, it has kind of stayed in that corner and has had a hard time breaking out of it ever since, although great strides have been made with the Basic language to put it on par with other languages.
I think BASIC “compilers” have traditionally been template based translators. Besides, real speed comes from the optimization phase of the compiler, and BASIC compilers have not been optimizing compilers. Not even Xojo, which is a true compiler, is an optimizing compiler.
And even today, while the difference is not “compiled” vs “interpreted”, it is optimized vs not so much
(yeah … What Tim just said 
here is an example
BASIC : x=x+1
load reg1, valueof x
load reg2, valueof 1
add reg1,reg2
move to x
C : x++
load reg1, valueof X
increment reg1
move to x
Not exactly how it works, but good enough to illustrate
BASIC was 4 expensive operations
C was 2 expensive and one cheap operation
and in an optimizing compiler it would have taken X=X+1 and changed it to X++ and THEN compiled it
This is a really deep and nuanced topic that deserves more depth and nuance than it will ever get here. That said, some thoughts.
-
Writing code that does efficient pointer arithmetic is simple in C/C++. It’s a giant PITA in Xojo, because Xojo hides memory pointers as best it can to shield users from the typical beginner and expert problems associated with them. So writing an image processing function, for example, is easier and will end up running faster coded well in C vs. coded well in Xojo.
-
Xojo is tuned for use with a cross-platform framework. You get a lot of inefficiency from layers to make different things work the same.
-
Inefficiency is a trade-off. It’s not a bad thing except in the few cases where the other gains aren’t as important as the efficiency lost. So let’s say you can write a graphics operation in “C” that runs on 20% of the time it takes in Xojo, but that 1 month Xojo project takes 12 months in C. Perhaps your product doesn’t get to market.
But there’s a punchline to be found here, and that’s the Xojo plugin architecture. Write the code that doesn’t need to be highly optimized in Xojo. This is likely most of your interface, business logic, etc. If there are small spots that could be improved significantly and economically by coding them in C, make a plugin. Best of both worlds!
[quote=107253:@Dave S]and in an optimizing compiler it would have taken X=X+1 and changed it to X++ and THEN compiled it
[/quote]
Eh. That’s actually syntactic sugar, not an efficiency thing. But the concept is close enough.
[quote=107244:@Garth Hjelte]I’m revisiting this topic because I still truly don’t understand it.
Why is a LANGUAGE always equated with the speed of the compiled result? If everything goes into the same machine language, why can’t someone create a compiler that makes fast - fastest - compiled code regardless of the language?
Think about it: I can write a loop in C and a loop in BASIC and it’s only semantics - the tokens - that differentiate them.
[/quote]
Not true
Bounds checking does not exist in C by default.
Stack overflow and lots of other checks that exist in one language might not exist in another.
And this isn’t necessarily something YOU specify when you write
For i as integer =
etc
[quote=107244:@Garth Hjelte]Why WOULDN’T a compiler create the exact same machine code for each? They mean the exact same thing.
[/quote]
For the basic parts of the loop they might
But there’s things around the loop like bounds checks over flow checks & whatnot that you never write but happen
[quote=107244:@Garth Hjelte]To hypothetisize: why couldn’t some whizkid make a compiler that created FASTER code than the common C compilers? Or at least identically as fast? Isn’t it all the same machine code?
[/quote]
Probably because the folks who write compilers have entire teams that do this
And I doubt anyone knows an entire chip at the level the chip manufacturer does
Compilers do pretty darned well but Intels compilers seem to get just that little bit extra juice out of their chips
[quote=107244:@Garth Hjelte]I don’t see anything in the semantics of C that makes it any superior to be FASTER than BASIC. I’ve written C->BASIC translators and BASIC->C translators. The differences between languages are SEMANTIC, and any differences have to do with efficiency of INPUT, not efficiency of OUTPUT.
So why, constantly, is the language equated with performance?[/quote]
C is like the assembler of today
You get pretty close to the metal and NO safety nets
Xojo gives you safety nets
Well this is exactly what my BASIC to Swift translator does
X=X+1 becomes X++ , therefore the SWIFT COMPILER never sees “X=X+1” at all
X=y+1 stays X=y+1
[quote=107257:@Dave S]Well this is exactly what my BASIC to Swift translator does
X=X+1 becomes X++ , therefore the SWIFT COMPILER never sees “X=X+1” at all
X=y+1 stays X=y+1[/quote]
LLVM is definitely smart enough to write the exact same machine code for x=x+1 and x++
And it may even generate the same code for x=y+1 if it can reason that y refers to x and so x=y+1 is really x=x+1
And if that is the case, it simply means my translator can leave some of the optimzation to the SWIFT compiler (which happens to be LLVM)
If you’ve programmed in assembly code, having to deal with stack pointers and heaps, allocation of items, jump tables, etc. you would know why. In assembly we can do things faster than C, because we do just any bits of things that we need to accomplish a task, and that’s called a low level language, where you care to things looking to your hardware (CPU registers, memory, etc). C gets near, but takes care of many boring tasks for you, like allocating items in scopes and releasing them and giving you tools to do your memory allocations of large itenms, calling OS APIs, etc, doing some math, and having standard libraries for basic tasks OS oriented, etc that’s called mid-level languages. And there are high-level languages, where the close to the metal speed is a second class citizen in favor of functionality and easy of use. The language will try to take care of an incredible mass of boring things instead of you and tasks you don’t even noticed (like checking for error conditions that would crash a C program after destroying all the data in memory due to such bug). One line of a high-level language = various lines of C code = even more lines of Assembly code. You choose, complexity or speed?
I’d say so.
Just move the syntax to swift & let it do the work .
LLVM is VERY smart when it comes to what can / cannot be done and there’s a decent sized team writing all this.
Collectively they’ve probably got more PhD’s than all of us
[quote=107257:@Dave S]Well this is exactly what my BASIC to Swift translator does
X=X+1 becomes X++ , therefore the SWIFT COMPILER never sees “X=X+1” at all
X=y+1 stays X=y+1
[/quote]
Fine, but we weren’t talking about your translator specifically :-). As Norman suggested, you’re at a pretty high level there. Let the SWIFT COMPILER do the tricky stuff. It has a lot of clever people working on those optimizations for you.
Thanks for the information. I think we slightly went OT (that’s fine).
What I was drilling for is that I don’t understand truly why language = performance when it’s really compiler = performance. Isn’t it entirely possible someone could write a compiler that would parse BASIC code that would be every bit as fast and close to the metal as C? (In a general sense)
I get all this, and I understand I’m splitting hairs in a way, but it seems to me that C just happens to attract all the great compilers. BASIC seems to get compilers that aren’t necessarily fast, but not because of the language, but PERHAPS because of the so-called “philosophy” behind the language.
(I"m putting aside “interpreted” considerations and certain language advantages like pointers or inline code that C has over BASIC.)
I apologize for being super-literal but I think the distinction is important and it obscures clarity when performance is attributed to the LANGUAGE and not to the actual source which is the compiler. Perhaps the thought is that a compiler and a language are linked together so tightly they may as well the same thing, but I disagree. Aside from syntactic things, I find BASIC and C quite similar in concept, almost to the point where it seems (forgive my non-experience) one could internally convert BASIC->C in a build internally and transparently and then compile with a NASCAR C compiler.
Ultimately I’m being the Word Police but the final effect of decoupling the reason for performance gains (the compiler, not the language) gives BASIC better credibility. It’s the compiler given to the language, not the language itself.
For operations that are available in both language, yes, it is possible and has been done. One popular example would be C# vs. VB.NET. I’m not aware of any significant performance differences between the two when comparing the same operations with the same compiler options. Though I haven’t tested it, my understanding is that PowerBASIC, a Windows only IDE/compiler, offers performance comparable to other popular Windows C++ compilers.
I would cite XojoScript as another example. XojoScript uses LLVM now and, on some code at least, the performance gains bring it right in line with C++ compiled using Xcode. Not everything will be as fast once all of Xojo is on LLVM because Xojo offers more safety checks and doesn’t offer things like efficient pointer arithmetic. But I think at that point performance will be much closer overall.
For English Mothers Tongue people only
;-
[quote=107409:@Daniel Taylor]
I would cite XojoScript as another example. XojoScript uses LLVM now and, on some code at least, the performance gains bring it right in line with C++ compiled using Xcode. Not everything will be as fast once all of Xojo is on LLVM because Xojo offers more safety checks and doesn’t offer things like efficient pointer arithmetic. But I think at that point performance will be much closer overall.[/quote]
Wouldn’t it be possible for Xojo to do some efficient pointer arithmetic after the transition to llvm and hide the details/extra work from its users.
[quote=107372:@Garth Hjelte]Ultimately I’m being the Word Police but the final effect of decoupling the reason for performance gains (the compiler, not the language) gives BASIC better credibility. It’s the compiler given to the language, not the language itself.
[/quote]
Ehhhh… I’m reminded of a theme in my favorite software engineering text, circa 1993: “Software Engineering”. Sorry, I can’t recall the subtitle or authors, as all my book books are in storage. Anyway, “software quality” is a meaningless phrase. Software has “qualities” (plural). There are lots of them and they often trade off against each other. In this example, we’re talking about efficiency of typical compilers of a 2 particular languages. Yes, a competent C programmer can easily write more efficient code for a wide range of tasks than a competent Xojo programmer can write. But, a competent Xojo programmer can develop an app that runs on 3 desktop platforms 5x (or more) faster than a competent C programmer could do the same, even with the best cross-platform SDKs. In short, the inefficiencies inherent in higher level languages aren’t a result of laziness by people who write the compilers. They’re usually a combination of design choices to balance trade-offs differently than C, and the fact that there aren’t thousands of people getting Ph.D.s for minor optimizations of the C compiler on some particular hardware tweak.
The PureBasic compiler produces tiny, blisteringly fast executables but you do sometimes find yourself responsible for allocating/freeing memory, handling pointers, etc…