POV-Ray : Newsgroups : povray.off-topic : Questionable optimizations Server Time
5 Sep 2024 23:16:37 EDT (-0400)
  Questionable optimizations (Message 41 to 44 of 44)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: Questionable optimizations
Date: 22 Jul 2009 01:00:01
Message: <web.4a669bd12c54829f785322500@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> > For a project like the Linux kernel that is aimed at high portability,
>
> Well, no.  The Linux kernel wasn't started aimed at high portability. Just
> the opposite, really.

Yeah, but what is the *current* aim?


> > Another reason is speed, of course, but just like with Assembler it could be
> > argued that only the most heavily-used portions of a project should resort to C
> > for speed these days.
>
> Mmmm.... Debatable. :-)  It really depends on the rest of the system. If
> you're writing in some language fundamentally different from C, you might
> spend more time translating into C data structures than you do to run it.
> Nobody says "Wow, this SQL query is really slow. Let's rewrite it in C."

I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
do by just pumping the data into a C program and doing the filtering & sortng
manually (though generally you'd first have a look to see if you can somehow
improve performance by tweaking the DB, rephrasing the query, or the like).

And in general, serious languages tend to have *some* generic interface to
libraries written in C (though then again, some of these interfaces seem to be
pathological, as with Perl for instance; seen a colleague once struggling to
pass a NULL pointer or some such into a C API function).


Post a reply to this message

From: Darren New
Subject: Re: Questionable optimizations
Date: 22 Jul 2009 10:18:54
Message: <4a671fce@news.povray.org>
clipka wrote:
> Yeah, but what is the *current* aim?

 From *my* experience, the current aim is to dick around with it for fun so 
it takes several weeks of intense concentration and trial-and-error to get 
each new point release to even compile.

> I said, it *could* be argued. And BTW, *some* SQL queries are indeed easier to
> do by just pumping the data into a C program and doing the filtering & sortng
> manually (though generally you'd first have a look to see if you can somehow
> improve performance by tweaking the DB, rephrasing the query, or the like).

Exactly. My point was that nobody rewrites a chunk of SQL in C. They pull 
the data and manipulate it in C, which is rather different from cracking 
open the RDBMS and modifying it to add their query as a SQL primitive. :-)

> And in general, serious languages tend to have *some* generic interface to
> libraries written in C 

Sure, but that's because C is close to assembler. Anything with a reasonable 
calling convention can do that, assuming the CPU is designed to run C. Most 
of them also have some generic interface to Windows COM as well. I'm not 
sure what the point is. :-)

LISP machines, Smalltalk machines, and FORTH machines all lack generic 
interfaces to libraries written in C. :-)

> (though then again, some of these interfaces seem to be
> pathological, as with Perl for instance; seen a colleague once struggling to
> pass a NULL pointer or some such into a C API function).

Precisely my point. The farther from C your language gets, the less likely 
you can easily invoke C.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."


Post a reply to this message

From: Darren New
Subject: Re: Questionable optimizations
Date: 27 Jul 2009 21:46:11
Message: <4a6e5863@news.povray.org>
Here's a whole description of the whole chain of events that led up to it 
breaking.  I don't know if it got posted before, but it's pretty interesting.

http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."


Post a reply to this message

From: Warp
Subject: Re: Questionable optimizations
Date: 28 Jul 2009 08:18:44
Message: <4a6eeca4@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> Here's a whole description of the whole chain of events that led up to it 
> breaking.  I don't know if it got posted before, but it's pretty interesting.

> http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/

"But Herbert's patch added a line which dereferences the pointer prior
to the check. That, of course, is a bug."

  That's what I thought. You can't blame a compiler optimization for
"screwing up" buggy code, even though without the optimization the bug
would perhaps not have been symptomatic by pure chance.

-- 
                                                          - Warp


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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