POV-Ray : Newsgroups : povray.off-topic : Programming langauges Server Time
5 Sep 2024 15:28:46 EDT (-0400)
  Programming langauges (Message 45 to 54 of 114)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Warp
Subject: Re: Programming langauges
Date: 25 Oct 2009 13:35:52
Message: <4ae48c78@news.povray.org>
SharkD <mik### [at] gmailcom> wrote:
> On 10/25/2009 7:51 AM, Warp wrote:
> > Orchid XP v8<voi### [at] devnull>  wrote:
> >> I've never seen TSQL, but if it's anything like SQL...
> >
> >    How about making some googling? TSQL is SQL + some extensions.

> "Doing" not "making".

  You "make love", you don't "do love". ;)

-- 
                                                          - Warp


Post a reply to this message

From: clipka
Subject: Re: Programming langauges
Date: 25 Oct 2009 13:48:57
Message: <4ae48f89@news.povray.org>
SharkD schrieb:
> There's one thing I've always been confused about. Are all compiled 
> languages equal in terms of performance?

No.

However, it often depends a lot on the compiler and libraries, rather 
than the language itself.

Performance may also vary with the task at hand; a language aimed at 
scientific computations, for instance, may include highly optimized 
libraries for matrix math, but suck at string handling.


Post a reply to this message

From: Orchid XP v8
Subject: Re: Programming langauges
Date: 25 Oct 2009 14:59:32
Message: <4ae4a014$1@news.povray.org>
clipka wrote:

> Performance may also vary with the task at hand; a language aimed at 
> scientific computations, for instance, may include highly optimized 
> libraries for matrix math, but suck at string handling.

Conversely, I'm told Perl's regex handling is supposed to be quite fast...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

From: SharkD
Subject: Re: Programming langauges
Date: 25 Oct 2009 15:08:17
Message: <4ae4a221$1@news.povray.org>
On 10/25/2009 1:48 PM, clipka wrote:
> However, it often depends a lot on the compiler and libraries, rather
> than the language itself.

Er, yeah! I forgot about POV's 10% performance drop as a result of 
switching from the Visual Studio compiler.

Mike


Post a reply to this message

From: clipka
Subject: Re: Programming langauges
Date: 25 Oct 2009 15:11:45
Message: <4ae4a2f1@news.povray.org>
Orchid XP v8 schrieb:
> clipka wrote:
> 
>> Performance may also vary with the task at hand; a language aimed at 
>> scientific computations, for instance, may include highly optimized 
>> libraries for matrix math, but suck at string handling.
> 
> Conversely, I'm told Perl's regex handling is supposed to be quite fast...

For instance, yes. And I don't expect it to have highly-optimized matrix 
math libraries.


Post a reply to this message

From: clipka
Subject: Re: Programming langauges
Date: 25 Oct 2009 15:15:07
Message: <4ae4a3bb$1@news.povray.org>
SharkD schrieb:
> On 10/25/2009 1:48 PM, clipka wrote:
>> However, it often depends a lot on the compiler and libraries, rather
>> than the language itself.
> 
> Er, yeah! I forgot about POV's 10% performance drop as a result of 
> switching from the Visual Studio compiler.

A similar performance difference can be observed with POV-Ray on AMD64 
Linux between binaries compiled with the Gnu and Intel compiler suites 
(at least "out of the box"), with Intel in the winning seat.


Post a reply to this message

From: Darren New
Subject: Re: Programming langauges
Date: 25 Oct 2009 16:17:29
Message: <4ae4b259$1@news.povray.org>
Warp wrote:
> SharkD <mik### [at] gmailcom> wrote:
>> On 10/25/2009 7:51 AM, Warp wrote:
>>> Orchid XP v8<voi### [at] devnull>  wrote:
>>>> I've never seen TSQL, but if it's anything like SQL...
>>>    How about making some googling? TSQL is SQL + some extensions.
> 
>> "Doing" not "making".
> 
>   You "make love", you don't "do love". ;)

But if you make love to google, you're probably doing it wrong.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".


Post a reply to this message

From: Darren New
Subject: Re: Programming langauges
Date: 25 Oct 2009 16:20:07
Message: <4ae4b2f7$1@news.povray.org>
SharkD wrote:
> like C++ being a superior performer to Java, but Java of course is a 
> runtime language so it's not a fair comparison.

Plus, Java is compiled, and indeed, some JVMs will recompile the code 
multiple times during its execution to get it to go faster. Some non-VM 
languages also let you feed in profile information to the compiler to get it 
to recompile better.  Some hardware has instructions specifically to support 
some languages. Pretty much everyone has floating point hardware these days, 
but it used to be quite common to have support for printing, formatting 
numbers, moving blocks of variables, and the other sorts of stuff the COBOL 
did a lot of that wasn't fast enough in the old hardware.

So, no. They're not all the same in performance, and they aren't even all 
the same in terms of capabilities.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".


Post a reply to this message

From: Darren New
Subject: Re: Programming langauges
Date: 25 Oct 2009 16:20:46
Message: <4ae4b31e$1@news.povray.org>
Orchid XP v8 wrote:
> Conversely, I'm told Perl's regex handling is supposed to be quite fast...

I'd guess .NET is faster, if only because it compiles the regex into machine 
code, rather than interpret it.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".


Post a reply to this message

From: Orchid XP v8
Subject: Re: Programming langauges
Date: 25 Oct 2009 16:33:01
Message: <4ae4b5fd$1@news.povray.org>
>>>>    How about making some googling?
>>
>>> "Doing" not "making".
>>
>>   You "make love", you don't "do love". ;)
> 
> But if you make love to google, you're probably doing it wrong.

*facepalm*

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.