Learning + Programming + Speed

[kyonides]

Why Programming Languages Are Slow?

The link above would lead you to a commentary on why some languages like Ruby or Python are considered slow by seasoned programmers or those that pretty much never used them. Kopylov's opinion seemed to be reasonable and appeared to be based on his experience on those languages plus Java, Javascript and C like languages.

If you start reading the comments previous readers left, you soon realized that people could not stop criticizing him for his general approach to the speed and syntax topics. Most of them would blame him for laying stress on the importance of syntax when its impact is low at the end of the day.

Well, syntax does matter anyway. Code won't run if the syntax (akin to human language grammar) is wrong or is missing something like a parenthesis. Usually languages do deal with this issue... once. I mean, they are expected to find any such issues at the very beginning.

If we were talking about C or C++, I could say that the compiler will immediately complain about it but the binary executable aka the program or app won't. So the compiler becomes your proofreader and by the time you publish your application, it should NOT include such errors at all. (Yet, the compiler has several other tasks to perform as well.)

Just in case you were thinking about Ruby or  Python, they initially relied on reading every single line of code you entered in your files. Yeah, that is the perfect way to make it run SLOWLY. At some point both languages went after either just in time compilation or simply producing bytecode. Java has been employing bytecode for quite some time.

Glossary

Source Code: Your code. Period.
Byte Code: Code read by a Virtual Machine or VM.
Binary Code or Machine Code: Used by OS libraries or even the CPU only. Memory and variable / pointer references do matter here.

The closer the code is to machine code, the lower its level will be.

That's why C and C++ and the like are considered low level languages, they rely on binary code.

Source Code
Can only be handled by people or language interpreters.
Slow.
Compatible with certain languages.
Simple TXT files with proper language file extensions.

Byte Code
Can only be handled by a VM.
Kind of Slow.
Compatible with several processor architectures.
Usually Cross Platform.

Binary Code
Can only be handled by an OS libraries or be directly fed to the processors like CPU's or GPU's.
Fast.
Compatible with specific processor architectures.
Cross Platform only if using very similar OS's, yet, Linux binaries won't run natively on Windows and vice versa.

The only fastest language I could think off would be Assembler that produces machine code, a set of millions of simplistic processor instructions.
Guess why people later preferred to develop languages like C and later C++ and many others.

 Does it mean that languages are stuck right there?
 Not necessarily.  and  have been improving their speed and overall performance as much as possible in the last decade. Of course, it would be hard to convince anybody that they will become as fast as C++ one day.  

What did make a difference there?
 Well, on one hand I could say they made several changes like redefining the way they collect garbage or zombie objects lurking around. On the other hand, they have improved memory allocation and reallocation. Besides they could have reduced the number of basic checks in their low level implementations (in C to be specific). At least  has changed their interpreter from basic MRI to other implementations like YARV or added JIT or MJIT. They also cared about memoization. IIRC, memoizing some method call improves the speed by keeping a quick access register of where they are located and what arguments are being passed to them. Sometimes it's been a great addition to  while Rails might have not enjoyed its benefits at all.

 What about syntax? Does it matter then?
 Of course it does! Yet, the less you care about it, the slower the language might become.
In languages like C and C++ you gotta specify a lot of details like return value of a function, argument types, variable types, the specific moment a given variable should be declared or is it local or global?
C might not allow certain type coercions while C++ might allow you to do that if you provide it with some basic information on that value at some point. C++ has several default coercions included. It can even convert pointers into specific types.
 Ruby won't allow you to coerce a number of any kind into a string. You need to call to_s method or define a string interpolation and then call sprintf to modify it.

Since none of the languages exposed here read actual source code anymore, the interpreter or executable does not focus on syntax at all (after it has finished loading your code).

Even so that does not mean other  errors common in low level languages won't show up like dumping cores or segfaults (segmentation faults).

You could say you might have encountered some  illegal or irresponsible calls that look for non existing information or temporary data that has been erased from memory or you were looking for data that does not belong to the memory space you had previously reserved via stuff like malloc or your language memory manager or your current thread. Or you didn't tell it to  keep it alive long enough to let you work with it.

Usually you could prevent that from ever happening if you take care of its error handling, i.e. don't let them set a value above 255 or no negative value should be allowed or don't ever let them divide anything by zero!  

Now talking about the maker's way of living, don't nest several loops in a row if possible.
Actually, you could not avoid it if you are planning to display some tileset on screen using engines like Gosu or Roole, but if you only need to check a certain method or value stored in a variable found in some list or Array, you better look for an alternative way to fetch it without more than a single (for each) loop.

As a final word on this, I gotta say that glue code or spaghetti code won't help you here. The cleaner and more simple your code is, the better it should perform... usually.  

 There could still be many other issues that could show up later on, but that's something that would deserve starting a new thread or posting a new reply some other day.

Disclaimer

I'm not saying here that I know everything about programming nor that I've covered every single aspect of it. You still can contribute to this thread by leaving your comments here if deemed necessary.