Offline
Forum
Off Topic Programming Languages
Programming Languages
26 replies
Lee has written Quote
So BASIC should be about as fast as C/C++ and faster than Lua.
This is true, and for the most part, the speed differences between modern implementations of basic and c are virtually insignificant. (vb.net runs on the CLR virtual machine so it doesn't count, for the most part, blitz targets a set of C wrappers over the graphics calls so it is actually a bit slower than C/C++ equivalents, however not by much; but vanilla BASIC used in academic environments have comparable speeds to their C counter-part, as the machine code produced will nearly be identical as long as memory management isn't considered)
wait so ure saying basic can be as fast as c for math stuf? oh well who cares u might as well use sse optimized asm if u really need speed in loops or something
btw http://en.wikipedia.org/wiki/Malbolge
I like C/C++ because i have direct memory access.
I like lua because i just love tables.
Depends on the project what kind of programming language i use..
For GUI programs, i really hate the win32 api, so i use C# .net ( superior to java)
IWhoopedPythagoras has writtenI really like Python because development time is so short.
I like C/C++ because i have direct memory access.
I like lua because i just love tables.
Depends on the project what kind of programming language i use..
For GUI programs, i really hate the win32 api
I like C/C++ because i have direct memory access.
I like lua because i just love tables.
Depends on the project what kind of programming language i use..
For GUI programs, i really hate the win32 api
i'm making something with that right now. fun shit
bezmolvie has writtenAlso, Lee, although (almost) every language is compiled into machine code, some languages might compile redundancies and useless statements, which cannot be avoided because of the syntax of the language, if I'm not mistaken. The same happens with website builders.
This is an implementation problem however.
As an example:
Both GCC and the LLVM suite can compile C, Java, and a myriad of many other languages into independent forms of IR, which can then be used in conjunction with a linker to emit machine code. While the code produced is extremely similar in both cases, GCC tends to pursue branching optimization much more aggressively then Clang (stable build).
Likewise, both Basic and C (and usually many industrial grade/research languages that runs outside of a VM) can apply static analysis (looking at the concrete syntax tree during compilation) to figure out possible optimization routes.
I'll admit, certain forms of languages can have specific optimization tailored specifically for it so optimization during compilation down to that IR also exists; for example, register allocation for autos instead of using stack space in C for calls and variable declarations, array optimization in Basic, Java, and most other languages since there's no ambiguity between pointers to buffers and pointers to memory. And in special instances, when static analysis may not be terminating (ambiguity resolution in dynamic languages is an n^n operation for closed programs, and undefined for nonterminals), dynamic optimization is applied that uses a hotpath (a sentry of sorts stationed at every single branch that counts off how many times this specific path has been taken) to compile specific execution routes that are considered "hot". This is usually what is known in vernacular as "just in time", but for the most part, it is completely indistinguishable from actual compilation using static analysis. The only difference is that there may be a slight overhead at program start during the first run, however this is usually insignificant.
As an illustration, consider a simple stack language (Reverse Polish Notation to be exact). We have a lexer (code that looks at the input stream and breaks it up into tokens), a stack, and an execution context that looks at the immediate input and decides whether it should undertake one of the two operations:
1.) If the imm-input is a number, push it onto the stack
2.) If the imm-input is an operator, pop 2 from the stack, apply the operator as a left-associative binary operator, and push the result back on.
If we're in python, we have one of three ways to pursue this:
1.) We write a trivial program that parses code and executes it in python:
http://codepad.org/yoZjvKGM
2.) We can also compile this code and run the machine code during runtime
http://codepad.org/c0JO0SBv
3.) But, seeing as RPN is trivial to implement, and since we already have the compilation code for the RPN states into machine code, we can simply compile our code into a PE file (.exe) and execute it ourselves.
However, this simplifies the problem so much that the optimization problem is no longer relevant. For the most part, RPN is executed linearly. Consider a superhuman entity typing away at a terminal at a rate of 100 characters per second. Assume that each computer operation after compilation corresponds to 1 character of input, and assume that each one of these operations requires a significant amount of the processing power. Even then, to the end of time, the complexity of the code MUST be trivial as there will never be any way that a linear program can ever be non-deterministic. In fact, the compiler could very well optimize the entire thing into a single value, and then have the program output that every time it is run. Only when we introduce loops and recursion do we have to worry about time complexity. So for the most part, optimization of the determinable redundancy is usually a non-issue whereas loop optimization (including nesting and determination of the induction variable) are still open areas of research.