 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> I would think there's relatively little need to be slow in a program
>> like this, where it's all manipulation of fundamental structures.
>
> I think the GPU would be faster at this sort of program than the CPU :-)
http://www.nzone.com/object/nzone_cascades_videos.html
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Wow... are you running Vista, by any chance..? On my WinXP machine, I
> was getting about 20fps..
I'm running it via Mono, on Linux.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> http://www.nzone.com/object/nzone_cascades_videos.html
I'm *still* irritated that you can't run Cascades without Vista...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Mike Raiford wrote:
>> Wow... are you running Vista, by any chance..? On my WinXP machine, I
>> was getting about 20fps..
>
> I'm running it via Mono, on Linux.
>
Did you paste the code, or did you run the executable?
Mono has come a long way, then, last time I messed with it, there was no
support for Windows Forms.
I guess that lends credence to Andrew said about mono being slower than
even Haskell.
Though, I wonder where the bottleneck could be... Does Mono use JIT, or
is it simply interpreting the bytecode?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I guess that lends credence to Andrew said about mono being slower than
> even Haskell.
Just in case anybody thought I was pulling facts out of thin air:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=csharp&box=1
It seems that Mono has improved since last time I checked. (Or Haskell
as got worse.) It still remains at least 10% slower in 8 of the
benchmarks (verses 3 where it's faster) and uses more RAM in 8 of the
benchmarks (verses 3 where it uses less).
It's a similar story here:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2=csharp&box=1
This uses "Mono JIT compiler 1.9.1"; the first one is "Mono C# compiler
version 2.2.0.0".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> I guess that lends credence to Andrew said about mono being slower than
> even Haskell.
Regarding "slower than even Haskell":
http://tinyurl.com/dj3wm3
At the top of the tree sits C++. Directly below that is C. Directly
below that is ATS. And the very next thing on the list is... Haskell.
It's faster than Java, it's faster than Smalltalk, it's faster than
Lisp, it's faster than Erlang, it's faster than Mono, it's faster than
Fortran, it's faster than Clean or OCaml... in fact, it's faster than
everything in the entir shootout apart from C, C++ and ATS.
Of course, the beauty of the shootout is that if you twiddle the knobs
and dails enough, you can make *any* language "win". So I wouldn't put
too much faith into the exact numbers produced. But the fact that
Haskell ends up anywhere near the top of the list means it can't
possibly be *that* damned slow.
So it's possible to write fast code in Haskell. As Warp keeps pointing
out, the trick is working out how to make your code go fast; it turns
out to be a bit unpredictable...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Nicolas Alvarez wrote:
> > Mike Raiford wrote:
> >> Wow... are you running Vista, by any chance..? On my WinXP machine, I
> >> was getting about 20fps..
> >
> > I'm running it via Mono, on Linux.
> >
>
> Did you paste the code, or did you run the executable?
>
> Mono has come a long way, then, last time I messed with it, there was no
> support for Windows Forms.
>
> I guess that lends credence to Andrew said about mono being slower than
> even Haskell.
>
> Though, I wonder where the bottleneck could be... Does Mono use JIT, or
> is it simply interpreting the bytecode?
It's JIT, if it was interpreting bytecodes it should be as slow as python.
Howver, System.Drawing must be doing it by translating into respective X or GL
calls or, worse, into GDK calls which in turn get into X or GL calls. I'm sure
the mono guys aren't that dumb and are writing directly for GL though. Still,
perhaps the native Windows drawing routines are much faster.
I got my 4 cores crunching at it and it seems to go at a good clip as far as
lava-like things move...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> http://www.nzone.com/object/nzone_cascades_videos.html
>
> I'm *still* irritated that you can't run Cascades without Vista...
Hehe, good luck trying to implement marching cubes on the GPU under XP :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Did you paste the code, or did you run the executable?
I ran the executable. I have no idea how you go about compiling C# code.
> Though, I wonder where the bottleneck could be... Does Mono use JIT, or
> is it simply interpreting the bytecode?
I even tried AOT (compiling it to a native program), and it wasn't any
faster. But I now tried it again and ran top, it looks like the X server is
the bottleneck! Are you doing pixel-by-pixel changes without double
buffering or something? (causing an X command on every pixel drawn)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Mike Raiford wrote:
> > Did you paste the code, or did you run the executable?
>
> I ran the executable. I have no idea how you go about compiling C# code.
You'd save the text to a .cs file and run the mcs compiler from mono project.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
