[GRLUG] python app speed

Ben DeMott ben.demott at gmail.com
Thu Jul 16 16:11:53 EDT 2009


I agree with everything you said Michael - we should not get into some
arbitrary speed argument in the end IT DEPENDS.

When people spout Java, and .NET Propaganda I become frustrated - Very
frustrated.
Why?

Because Java and .NET are the WORSE offenders.

Also Propaganda about Garbage Collection - in essence there isn't such a
thing - there is a virtualization engine in the background that looks for
crap that you forgot to remove/unlink/dereference and best guesses... ( It's
wizardry and hackory, thats partly why there are upteenth versions of the
JVM )
If you need an engine (a program) running in the background to collect old
memory for your PROGRAM I have a philosophical problem with your program!

Python, Perl, and PHP are C interpreted languages.
(They BIND to C - and use the C data Stack)
If you wrote an interpreter in C to generate OpCodes / ByteCode you would
get a language similar in speed to C if the developer and the interpreter
were as close to 'perfect' as they could be ... This is because of the
layout and maturity of the C compiler, how it generates processor opcodes,
and how it references memory.
.NET and JAVA are not 'classic c type stack languages' - in order to
accomplish their goal they  both implement proprietary data stacks.
They all are compiled into intermediate code and executed by what is a
considered a "Virtual Engine" - There are VAST differences between what a
"virtual engine means in reality" but the real difference is the DATA stack
that the virtual engine creates.

.NET and JAVA both have to use a proprietary Data Stack in order to support
(in .NET) cross language CLR compilation and interaction, and in JAVA
specialized data types.

This is a HUGE and important difference.

If you code C++ in .NET you lose your C data stack and throw it out for what
Microsoft came up with in a few years.
I work for a programming company, and one of the iPhone developers here used
to work on the COM spec at Microsoft, he left when .NET was being designed
to replace COM and would be happy to go on an hour long rant - It's bad.

Java's own documentation says "Your program may get faster as it runs,
because of JAVA Engine optimizations during runtime."  This fact alone
should point out a key difference between an interpreted STATELESS DATA
STACK, and interpreted STATEFUL data stack. (scary)

Java and .Net are GREAT in theory - I love the idea. But just download and
run eclipse PDT for a few hours and put yourself in my shoes.  JAVA's data
management is awful, which is why Google threw out the Java VM when they
implemented their own VM for Android.

Java Language Good JVM BAD.
C# Good, .NET API GOOD, CLR BAD.

.NET is better but has it's own host of problems - most importantly being
wasteful with memory (and proprietary).
.NET claims to be better for business like higher taxes claim to be better
for the populace.

As computers continually get faster we will continue to have background VM
wizardry and memory pagination in order to get languages that implement
features that are so far disconnected from Processor OPCODES, Instruction
Sets, and the way memory is stored that SLOW and bad is the only possible
outcome.

There is a reason no modern commercial games run in .NET or JAVA - There is
also a reason Microsoft will Abandon XNA soon.
Oddly enough the only Game I know that has been successful and had
World-Class graphics is written in Python (WITH C BINDINGS!) - EVE ONLINE!

>From Microsofts own site:
"There's a synergy between DirectX and hardware, particularly when it comes
to graphics." - HMM I wonder if thats because its not running in a VM.

UGHH

I am so annoyed I am going to have to go into the third person

Ben is a programmer, he programs a lot, and Ben has to deal with people who
write awful .NET and Java applications because the bar is set so low to
write a functional program in Eclipse and Visual Studio that a trained
monkey can do it...

web.config makes me want to kill myself........... I am done!

:)

My apologies ahead of time for everyone...

On Thu, Jul 16, 2009 at 3:24 PM, Michael Mol <mikemol at gmail.com> wrote:

> On Thu, Jul 16, 2009 at 10:36 AM, Ben DeMott<ben.demott at gmail.com> wrote:
> > Should be typed.... Java and .Net are measurably slower than Python,
> > especially Java, and especially in real world applications.
>
> Um, as a guy who pays attention to different languages and their
> capabilities, may I recommend we avoid falling into an argument of
> which language has been measured to be faster than another?
>
> A number of factors will affect how an application written for one
> language will perform compared to that same application written for
> another, and most of these factors are in fact controllable and
> tunable by the sufficiently savvy developer.  Everything from being
> aware of low-level constructs to being aware of the behavior of GC to
> "syntactic sugar" that lets compilers and JIT optimizers do a better
> job at reducing a high level concept into an efficient sequence of
> low-level concepts.
>
> In short, tuning is key. If you write your code strictly from a
> program flow standpoint, and if you don't consider what's going on at
> the next level down, you're not going to get the performance you can,
> and you're not going to recognize when some weird construct or pattern
> of behavior in your code is causing the problems.
>
> --
> :wq
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>



On Thu, Jul 16, 2009 at 4:00 PM, Adam Tauno Williams <awilliam at whitemice.org
> wrote:

> >Garbage Collection.  In managed platforms like .NET and Java, it's very
> important to understand if you want to get any kind of performance out of a
> "large" application.
>
> It matters in 'unmanaged' environments like Objective-C and Python as well
> (and in PHP, Perl, etc...).    Most of these use reference counting to auto
> release old objects.   But reference counting can fail in interesting ways,
>  even assuming there are no bugs in the implementation.  Maybe these are
> 'quasi-managed' enviroments?
>
> And unmanged C, etc... has GC problems as well - where the GC is the
> programmer. :)
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20090716/31801c9e/attachment-0001.htm 


More information about the grlug mailing list