 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The URL says it all.
http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.html
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.html
That's the problem with trying to "benchmark" different languages against
each other: Is your implementation of the task in a given language optimal,
or at the very least, fair?
It's easy to make a completely sub-par implementation of an algorithm
in a language and then make a much better implementation in another and
then conclude that the latter language is "faster" than the former.
In most languages you simply have to know how things should be done
for them to be efficient. You have to know the bottlenecks. Just because
some feature seems the "most logical" one doesn't necessarily mean it's
the proper feature for that task.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> That's the problem with trying to "benchmark" different languages against
Yah. I just posted it because it was Haskell, and ray-tracing. :-)
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.html
>
> That's the problem with trying to "benchmark" different languages against
> each other: Is your implementation of the task in a given language optimal,
> or at the very least, fair?
>
> It's easy to make a completely sub-par implementation of an algorithm
> in a language and then make a much better implementation in another and
> then conclude that the latter language is "faster" than the former.
In a way, this is why the Great Language Shootout is somewhat better.
You have *lots* of people writing and improving the code, not just one.
As you say, if one particular person sits down and writes the same
program in two langauges, and one is vastly slower than the other, it
probably just means they don't know that languages very well.
By allowing *anyone* to submit benchmarks, you ensure that there's a
reasonable chance that all the code submitted will eventually converge
on reasonably optimal.
OTOH, even the Shootout probably isn't especially scientific. But then,
trying to define which language is "better" is a fairly vague concept
anyway...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> The URL says it all.
>
> http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.html
No it doesn't - it doesn't say vs what! :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Interesting comment:
"I wouldn't mind a 2X drop in speed if it means the code is shorter
and easier to read."
I wonder how many program users also wouldn't mind?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Interesting comment:
>
> "I wouldn't mind a 2X drop in speed if it means the code is shorter
> and easier to read."
>
> I wonder how many program users also wouldn't mind?
Big smoking "sigh".
Skype has been running here for around a week, and it used 1 hour of CPU
time. Just being idle showing its tray icon, I haven't made any call.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>> Interesting comment:
>>
>> "I wouldn't mind a 2X drop in speed if it means the code is shorter
>> and easier to read."
>>
>> I wonder how many program users also wouldn't mind?
>
> Big smoking "sigh".
>
> Skype has been running here for around a week, and it used 1 hour of CPU
> time. Just being idle showing its tray icon, I haven't made any call.
It might conceivably need to send heartbeat messages over the network or
something to maintain presence information. There are 168 hours in a
week, so it still represents only 0.59% CPU time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Nicolas Alvarez wrote:
>> Big smoking "sigh".
>>
>> Skype has been running here for around a week, and it used 1 hour of
>> CPU time. Just being idle showing its tray icon, I haven't made any call.
>
> It might conceivably need to send heartbeat messages over the network or
> something to maintain presence information. There are 168 hours in a
> week, so it still represents only 0.59% CPU time...
I think it's too much CPU usage to just send heartbeat messages.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>> Nicolas Alvarez wrote:
>>> Big smoking "sigh".
>>>
>>> Skype has been running here for around a week, and it used 1 hour of
>>> CPU time. Just being idle showing its tray icon, I haven't made any
>>> call.
>>
>> It might conceivably need to send heartbeat messages over the network
>> or something to maintain presence information. There are 168 hours in
>> a week, so it still represents only 0.59% CPU time...
>
> I think it's too much CPU usage to just send heartbeat messages.
Possibly send hearbeat messages to confirm it's still running. Possibly
receive (and verify) heartbeat messages to confirm the network is still
OK. Perhaps check if any updates are available. (Who knows, maybe it
even installed one?)
If you don't like it, there's a fairly simple solution... ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
