Python VS Java VS PHP

>>1
Java is fastest of course.

For python vs php it depends.  Both can be compiled for extra performance(though they still won't outperform java), some of the compilers don't support all language features.

You don't need performance

>>6
Java can also be compiled but most people don't do that since common wisdom is that existing compilers don't do much better than JIT.

>>4
If you can write something to be faster with some more effort, I do not see a reason why not do so.
Sometimes a language can be more fun to code in and faster at the same time, but this depends on what the individual programmer prefers.

Define "Python is interpreted" and "Java compiles to bytecode" and how that relates to the latter being faster (I'm not arguing it is faster).
I should have written that a bit differently. Interpreted in this case means that you have an interpreter either interpreting some parsed AST, or bytecode. Compiled means that it compiles to native code. (Bytecode compilation is compilation too, so I apologize for not being clear about what kind of compilation I meant in my original post). Both Java and Python compile to bytecode, the difference is that Java has a JIT which compiles to native code (but usually at runtime, which can mean some overhead initially), while Python doesn't (unless you're using a better implementation). PHP also compiles to bytcode internally, but the bytecode is interpreted.

and how that relates to the latter being faster
On average, interpreting bytecode is slower than JITting it, or compiling it to native code, or compiling the original source to native code. Exceptions to this rule exist, but they depend on what kind of code people are writing.

>>3
Languages may be prone to be slow or fast when implemented, but they don't have such properties - implementations do.

No. If a language mandates that it should be possible to write some_module.sum = new_and_improved_sum and it would take effect on every expression in that module that used the builtin function sum, then all and every implementation of this language would be slow as fuck.

If a language allows writing int.__add__ = new_and_improved_add and it is supposed to affect every integer in the program, then all and every implementation of this language would be slow as fuck. (Python2.x doesn't allow exactly this, but you get the meaning I hope)

If a language allows adding an arbitrary object that supports certain interface to a list of integers and requires all functions like sum to not choke on it, then all and every implementation of this language would be slow as fuck.

If a language allows doing all of the above from the multiple threads, then all and every implementation of this language would be slow as fuck concurrently.


People writing an evaluator can haggle a bit, of course. They can JIT-compile the code and recompile all dependent code when you change something. Which would be slow as fuck then, but hey, it's your fault now. And of course there would be a lot of time wasted on bookkeeping and no extension module calls, but OK. They can add a tracing JIT to deal with things like arrays of integers where your tight loop usually goes through the same functions again and again. That of course would involve a lot of time wasted on bookkeeping again: maintaining statistics to detect when we've entered such a loop, compiling it, checking that the types are still right on each iteration et cetera. And forget about most kinds of compiler optimization, there's no time to do it in runtime. They can go as far as creating specialized arrays of unboxed ints whenever it seems that this is what is needed and then check every time and convert it back if you add something that is not an int (in case you are wondering: LuaJIT does something similar to mitigate the lack of arrays as such in Lua).

I like that you mentioned the Unladen Swallow, it's quite typical in this respect: some bright guys are confronted with the slowness-as-fuck problem and think "We know, we will remove GIL (also use JIT, tracing JIT, tagged pointers and whatever else has been invented in the last 50 years of trying to solve the problem that have never had any reason to exist in the first place)", now they have as much problems as they want. If they are young and arrogant they'll think that aloud, if they are really bright then they would not be totally embarrassed several years later when they manage to make their implementation merely slow (provided that the programmer doesn't use any dynamic features, any complex features, and had not forgot to sacrifice a black cock to the Goat with Thousand Young no more than a week ago), because hey, that's still a tremendous improvement and also a pinnacle of technological achievement (achieved when solving the problem that should not have existed, but I repeat myself)!

So no, some languages do have an objective property of being slow, or, more precisely, not allowing for the possibility of fast implementation, or at least making such implementation significantly harder to create.

>>10
>>3 is still right. It's not the language that's slow, it's the implementation. Sure, the language can have properties that ensure that every implementation is SLOW AS FUCK, but the slowness is still a property of the implementations.

>>10
No. If a language mandates that it should be possible to write some_module.sum = new_and_improved_sum and it would take effect on every expression in that module that used the builtin function sum, then all and every implementation of this language would be slow as fuck.
Not at all. You can do this in C by making the "sum" a function pointer, point it at "builtin_sum", and then change it later if you wanted a different sum.
You can do it on an object level as well, by making a copy-on-write function table in the object's struct that initially points at the functions as defined initially, and when that object's function is modified, build a new function table for it, and update that one function pointer to point to the changed function.
For threads, you'd either have to put a mutex around anything that accessed the function table, or mandate that anyone programming with mutable function pointers and multithreading needs to ensure that any function calls or changes to the function table is protected.
Speed has nothing to do with mutability of data; your argument is entirely stupid.

IHBT

>>10
While there is a speed penalty to be allowed to do that, I don't see why this is that huge of a penalty, it just means that you can't make direct calls.

In assembly, that would be:

call rel_offset ; direct call
call [&rel_offset] ; indirect call
pointer_table:
rel_offset dd add

mov [&rel_offset], new_add

call [&rel_offset] ; calls new_add

The speed penalty for that isn't huge. It's actually very common to do this. API calls are usually done like this, the OS writes the API imports to a table (in windows, it's called the IAT, altough it doesn't have to be contigious), and they're called directly. People can even make these API calls go through many hoops, and it still doesn't affect performance much.

Common Lisp being a dynamic language does this for the majority of functions, unless you crank up the optimization settings to do direct calls, and implementations are still pretty damn fast.

SEPPLES does this too with the object vtable, and it's much worse there, you usually have to go through double indirection and the address can't even be cached and the call is done through a register instead of a known beforehand offset, and it's still not THAT slow.

I don't know much Python, but I think the problem lies in how objects are built.

Some languages, like Javascript store objects are dictionaries/hashtables by default. Doing something like that is a lot more costly than just one indirect offset. If Python is like that, I can imagine why it would be slow.

>>12
Not at all. You can do this in C by making the "sum" a function pointer, point it at "builtin_sum", and then change it later if you wanted a different sum.
Are you an idiot? Are you making an argument based on the assumption that if you can do something in C then it can't be slow? Yes, you are and you are, it seems!

Sure you can do it in C and it would be slow, prevent all kinds of optimizations and so on. If you did it for every single function. And also used not a fixed set of named pointers, but a hashtable indexed by name, then it would be rapidly approaching slow as fuck, forgive the pun.

Also you can do clever stuff with objects, replace GIL with mutexes etc. That's more or less what the Unladen Swallow dudes did: and imagine their amazement when they discovered that the interpreter itself -- the loop that fetches bytecode instructions and dispatches on them in a monstrous switch -- is not the only bottleneck or even the worst bottleneck, that if you just take the bytecode and compile the corresponding case blocks one after another you become like whopping 10% or 20% faster than slow as fuck, yay! Even if you actually compile the bytecode to C and then compile C with maximum optimizations! C can be slow as fuck!

Speed has nothing to do with mutability of data; your argument is entirely stupid.
You are entirely stupid. Fucking idiot.

>>13
Actually much of Python's slowness is from the fact that it's using a dictionary for everything. When you write sum([1, 2]), it searches in locals(), then globals(), then in __builtins__, for "sum". Then it has to look in sum's dict to figure out what it is, and how to call it.

>>14
Fuck off, you don't know jack shit about what you're talking about.

>>13
First of all it's almost all hashtables of course. Except for local variables and special methods like __add__ or __getattr__.

But the main reason is that it kinda adds up if you have to make an indirect function call (with all checks of course) to add two integers. Having to allocate the result on heap doesn't help either. And to check that it's really integers you are adding. I mean, it doesn't hurt too much when your sys calls or even method invocations go through several indirections, but when every single operation on anything at all does it, more than once, the shit becomes rather slow.

>>15
Correction: thankfully, it doesn't have to look in locals(), that at least is resolved statically.

def f():
   print x
   x = 10

>>18
Well, to be accurate, it has to identify whether it's a local, global, or builtin identifier. Of course it's not running locals() etc. all the time, but it does need to check what scope everything is in.

>>19
My point was that locals are resolved statically, at bytecode-compile time. Also, are accessed by index.

>>17
That's all very well, but it is not immediately obvious to me how that's different from ECMAScript, for which I believe recent engines do far better than Python.

It also seems the (a?) solution lies in making more things hidden, private and unmodifiable, which isn't very Pythonic.

PHP is easily the most efficient, secure, and easiest language to learn.

I recommend PHP any day. FUCK those other languages, when are you going to need to write a C program? Or a python program? Perl? What a fucking joke. PHP is the only way, baby.

>>22
I hope you enjoy your Personal Home Page.

>>23
I will, along with my job!

Java and Python were both waves of the future that never met the shore. Stick with my good friend C#.

>>25
C# was the ship that found the seabed.

C# is off tune.

>>1
Implying you're ever gonna need the fastest language to write a blog.

Also use FIOC

Doesn't really matter, productiveness counts, go Python!

code in assembly, faggot

>>22
Sadly this almost works on me.

>>31
It works on me, being employed is nice. :P

>>28
Implying
Please don't do that.

http://www.cheapairmaxs.com air max
http://www.cheapairmaxs.com air max shoes
http://www.cheapairmaxs.com/nike-air-max-2012-c-111.html nike air max 2012
http://www.cheapairmaxs.com/mens-air-max-2010-c-93.html mens nike air max 2010
http://www.cheapairmaxs.com/womens-air-max-2010-c-96.html womens nike air max 2010
http://www.cheapairmaxs.com/mens-air-max-2009-c-95.html mens nike air max 2009
http://www.cheapairmaxs.com/womens-air-max-2009-c-98.html womens nike air max 2009
http://www.cheapairmaxs.com/nike-air-max-2003-c-101.html nike air max 2003
http://www.cheapairmaxs.com/nike-air-max-97-c-94.html nike air max 97
http://www.cheapairmaxs.com/mens-air-max-95-c-102.html mens nike air max 95
http://www.cheapairmaxs.com/womens-air-max-95-c-103.html womens nike air max 95
http://www.cheapairmaxs.com/nike-air-max-93-c-106.html nike air max 93
http://www.cheapairmaxs.com/mens-air-max-91-c-104.html mens nike air max 91
http://www.cheapairmaxs.com/womens-air-max-91-c-105.html womens nike air max 91
http://www.cheapairmaxs.com/nike-air-max-89-c-121.html nike air max 89
http://www.cheapairmaxs.com/nike-air-max-88-c-112.html nike air max 88
http://www.cheapairmaxs.com/mens-air-max-87-c-108.html mens nike air max 87
http://www.cheapairmaxs.com/womens-air-max-87-c-109.html womens nike air max 87
http://www.cheapairmaxs.com/nike-air-max-180-c-123.html nike air max 180
http://www.cheapairmaxs.com/nike-air-max-360-c-124.html nike air max 360
http://www.cheapairmaxs.com/mens-air-max-ltd-c-122.html mens air max ltd
http://www.cheapairmaxs.com/womens-air-max-ltd-c-116.html womens air max ltd
http://www.cheapairmaxs.com/nike-air-max-bw-c-117.html nike air max bw
http://www.cheapairmaxs.com/air-max-premium-c-118.html air max premium
http://www.cheapairmaxs.com/air-max-skyline-c-114.html air max skyline
http://www.cheapairmaxs.com/air-max-zenyth-c-125.html air max zenyth
http://www.cheapairmaxs.com/nike-air-max-tn-c-115.html nike air max tn
http://www.cheapairmaxs.com/kids-air-max-90-c-119.html kids air max 90
http://www.cheapairmaxs.com/kids-air-max-bw-c-120.html kids air max bw

Don't change these.

Name:		Email:
Entire Thread Thread List