Yes, progressive meshes have a number of applications: compressing the mesh, progressively refining the mesh during download, sampling the mesh at given detail level (to be able to render it efficiently) etc.
And what about the other comp geom algorithms; Delaunay triangulation/Voronoi diagram, convex hulls, Minkowski sum, visibility graphs...
Just look at the find text dialog. It's just like a win98 dialog - only not quite. It looks even more like a wine/winelib window - the font is a bit different from its win98 counterpart. The window is certainly different from the others - the are just ordinary gnome windows.
Seems to me Borland is using winelib (like Corel does) in addition to QT...
Interesting followup on the x86 backend, but I don't think that it effects my original comments.
However you choose to rank MSVC, fact is, for x86 platforms, GCC typically scores much worse than most compilers. I do agree with most what you said. However, I wouldn't go ahead saying gcc always scores worse than by MSVC. It's more complicated than that.
As for MSVC being a good compiler or not, my comments did not address this; even though, MS typically does a very good job of optimizing.
You did say "MS's compiler historically optimizes rather well.". What I ment by "not being spectacular" was it's optimizations (loses to Intel compiler). I don't even want to begin with other C++/C compiling aspects.
Gcc i386 optimizations have gotten much better lately. They recently integrated a new i386 backend (I don't think that was used in these tests, though.) Pgcc still has some edge, though. MSVC is not that spectacular compiler, Intel's compiler is much faster for example.
Please understand something here: gcc is a C compiler. malloc is not part of the C language but a part of the C standard library. Thus, gcc does nothing for the malloc call -- that's the job of the standard library implementation. In this case that happens to be the cygwin libc -- not the native win32 libc, but a non-optimal porting library. Under linux, with native glibc, the results might be different.
Java does separate the programmer from the platform, C very much doesn't. There are libraries that do that (partly.)
(Miksi *tussa suomalainen mies puhuisi suomalaiselle naiselle englantia baarissa? Tarkoititko "suksi vittuun, isotissinen nainen - puhumme pehmosta!"? HTH, hand.)
Cygwin very likely suffers from from large overhead and suboptimality in malloc stuff. I'm not sure how it is implemented, but likely it adds an extra layer between malloc() and win32 malloc(). MSVC, OTOH, is supposed have optimized malloc pools etc.
Cygwin is intended for portability (and does tremendous job IMHO) -- the performance is not the first concern. Glad to see gcc doing so well where the cygwin library is not involved, though.
I've been running XF4 for some time now. I have a Geforce, and I've used both NVIDIA's and XF's own driver. The XF driver performance was much better than in XF3.3.6, but NVIDIA's driver is even faster than that. Also, NVIDIA's opengl support is quite solid (provided it's closed source and all, but at least it works.) So yes I'm satisfied.
The only thing that does not work (tried nvidia and xf drivers) is dpms. I used to be able to do 'xset dpms force off' to shut down my monitor, but with XF4, this no longer does anything. Anybody know if it's supposed to be supported?
This is SGI's OpenGL extension. Several companies have been working hard at this, mainly Precision Insight. Companies that obviously benefit from this have been supporting them, like ATI, 3dfx, Matrox, and SGI. These sound like good players to me. My only question is why nVidia did not support the project. It's unfortunate nVidia would not support the project...
The author seems to be mixing PI's DRI work for XF4.0 (which includes GLX implementation) and SGI's GLX (OpenGL on X). NVidia's drivers implement GLX as well (not surprisingly because their OpenGL implementation is partly made by SGI.)
Yeah, well, but they didn't use the right compiler for Athlon either. Hint: egcs-1.1.2 is not particularry well optimized for Athlon either. Pgcc is a lot better. See the the thread here for some numbers.
At Actomicro. It was there friday, but now they seem to have pulled it down due to nVidia's legal harrashment. It'll be up again tomorrow, when nVidia officially launches Geforce2. The nv15 feature list is up at Actumicro's page anyway, pretty interesting, that.
Easy way to get it run under VMWare?
on
BeOS For Linux!
·
· Score: 1
So it's a disk image and a boot loader that executes it straight from Linux?
Can you get it running with vmware? Would it be as easy as configuring the disk image as an vmware virtual disk? I'd try that my self, but the download seems to be/.'ed (big surprise..)
While I can't disagree with Stroustrup on that C++ might never have estabilished itself without the C compability, I getting more and more convinced that a good and clean language just can't have such historical burden to carry. Also, to be a clean language, C++ has too much awkwardness in its "advanced" features as well. I completely agree with the comment that the poor standard of C++ programmers is not due to poor education but to the complexity of the language. Programming in C++, too much effort goes into pondering the C++ syntax issues and compiler implementation problems.
Don't get me wrong: C++ surely gets the job done, but I think it could be better and cleaner - mostly by removing some C compability and rethinking some other issues. Of course, this break the downward compability, and I'm pretty sure it'll never be done.
One recommendation: try reading Stroustrup's D&E and Ian Joyner's Critique of C++ in parallel.
I can't tell where you pulled that 1.3x-figure (pulled from sleeve or asked wife I s'pose), but if you have good software, 2 or more different threads and ideal application (compiling stuff, rendering animations or encoding mp3 for example) it's more like 1.8-1.95x (depending on io-rate). My friend bought an Athlon 550 and I went for BP6+2x466 oc'd to 2x545. Neither of us have regretted. I can rip and encode 3 cd's to mp3 in about half an hour (using Grip, see Freshmeat) and compile a 2.2.14 kernel (lots of stuff enabled) under 2 minutes. With athlon and a bit less hefty configuration, 2.2.14 takes about 2.50. So, all in all, it depends what you plan to do with your box.
> What a businessman! The highest possible profit > came close to janitor wages. I sure can see > why people listen to him about how to run a > business.
Last time I checked he did earn slightly more than an average janitor.
Well, Highpoint 366 support is included in the Andre Hedrick's IDE-patch for 2.2.x (available at ftp.*.kernel.org/pub/linux/kernel/people/hedrick). I'm using it with my BP6, and it works well.
I'm not sure, but I suppose the IDE-patch is is already included in 2.3.x.
Slashdot Mirror
I think you mean Hugues Hoppe.
Yes, progressive meshes have a number of applications: compressing the mesh, progressively refining the mesh during download, sampling the mesh at given detail level (to be able to render it efficiently) etc.
And what about the other comp geom algorithms; Delaunay triangulation/Voronoi diagram, convex hulls, Minkowski sum, visibility graphs...
The warnings are harmless. Update your binutils to get rid of them.
Just look at the find text dialog. It's just like a win98 dialog - only not quite. It looks even more like a wine/winelib window - the font is a bit different from its win98 counterpart. The window is certainly different from the others - the are just ordinary gnome windows.
Seems to me Borland is using winelib (like Corel does) in addition to QT...
2.95.mumble-mumble also lacks most of the (deemed unstable or too hackish) optimizations from pgcc.
AFAIK, 2.95 also does not have the new i386 backend yet. However, I've seen no benchmarks on that, so I really don't know how it does.
Interesting followup on the x86 backend, but I don't think that it effects my original comments.
However you choose to rank MSVC, fact is, for x86 platforms, GCC typically scores much worse than most compilers.
I do agree with most what you said. However, I wouldn't go ahead saying gcc always scores worse than by MSVC. It's more complicated than that.
As for MSVC being a good compiler or not, my comments did not address this; even though, MS typically does a very good job of optimizing.
You did say "MS's compiler historically optimizes rather well.". What I ment by "not being spectacular" was it's optimizations (loses to Intel compiler). I don't even want to begin with other C++/C compiling aspects.
For interesting results on the subject, see this Ars Technica article on HP's Dynamo optimizer.
Gcc i386 optimizations have gotten much better lately. They recently integrated a new i386 backend (I don't think that was used in these tests, though.) Pgcc still has some edge, though. MSVC is not that spectacular compiler, Intel's compiler is much faster for example.
Please understand something here: gcc is a C compiler. malloc is not part of the C language but a part of the C standard library. Thus, gcc does nothing for the malloc call -- that's the job of the standard library implementation. In this case that happens to be the cygwin libc -- not the native win32 libc, but a non-optimal porting library. Under linux, with native glibc, the results might be different.
Java does separate the programmer from the platform, C very much doesn't. There are libraries that do that (partly.)
(Miksi *tussa suomalainen mies puhuisi suomalaiselle naiselle englantia baarissa? Tarkoititko "suksi vittuun, isotissinen nainen - puhumme pehmosta!"? HTH, hand.)
Cygwin very likely suffers from from large overhead and suboptimality in malloc stuff. I'm not sure how it is implemented, but likely it adds an extra layer between malloc() and win32 malloc(). MSVC, OTOH, is supposed have optimized malloc pools etc.
Cygwin is intended for portability (and does tremendous job IMHO) -- the performance is not the first concern. Glad to see gcc doing so well where the cygwin library is not involved, though.
Not (at least with NVIDIA driver). Which card do you have?
I've been running XF4 for some time now. I have a Geforce, and I've used both NVIDIA's and XF's own driver. The XF driver performance was much better than in XF3.3.6, but NVIDIA's driver is even faster than that. Also, NVIDIA's opengl support is quite solid (provided it's closed source and all, but at least it works.) So yes I'm satisfied.
The only thing that does not work (tried nvidia and xf drivers) is dpms. I used to be able to do 'xset dpms force off' to shut down my monitor, but with XF4, this no longer does anything. Anybody know if it's supposed to be supported?
GLX
...
This is SGI's OpenGL extension. Several companies have been working hard at this, mainly Precision Insight. Companies that obviously benefit from this have been supporting them, like ATI, 3dfx, Matrox, and SGI. These sound like good players to me. My only question is why nVidia did not support the project. It's unfortunate nVidia would not support the project
The author seems to be mixing PI's DRI work for XF4.0 (which includes GLX implementation) and SGI's GLX (OpenGL on X). NVidia's drivers implement GLX as well (not surprisingly because their OpenGL implementation is partly made by SGI.)
> whose OpenGL 1.2 implementation is not complete/100% conformant
Care to elaborate?
Free X... How about XFree? Of course that was pretty hard to figure out... ;) See http://sourceware.cygnus.com/cygwin/xfree/ .
AFAIK MI/X is X11R5, not X11R6, so it won't get you far.
My zsh-powered linux seems to be more self-critical - it wants to set itself in fire, but being unable to do so, that asks for help:
zsh> So, Linux, how about that SMP support?
zsh: no matches found: support?
Yeah, well, but they didn't use the right compiler for Athlon either. Hint: egcs-1.1.2 is not particularry well optimized for Athlon either. Pgcc is a lot better. See the the thread here for some numbers.
At Actomicro. It was there friday, but now they seem to have pulled it down due to nVidia's legal harrashment. It'll be up again tomorrow, when nVidia officially launches Geforce2. The nv15 feature list is up at Actumicro's page anyway, pretty interesting, that.
So it's a disk image and a boot loader that executes it straight from Linux?
/.'ed (big surprise..)
Can you get it running with vmware? Would it be as easy as configuring the disk image as an vmware virtual disk? I'd try that my self, but the download seems to be
Don't get me wrong: C++ surely gets the job done, but I think it could be better and cleaner - mostly by removing some C compability and rethinking some other issues. Of course, this break the downward compability, and I'm pretty sure it'll never be done.
One recommendation: try reading Stroustrup's D&E and Ian Joyner's Critique of C++ in parallel.
Compiling the module(s) is usually enough for lm_sensors. Although, they do suggest patching kernel.
I can't tell where you pulled that 1.3x-figure (pulled from sleeve or asked wife I s'pose), but if you have good software, 2 or more different threads and ideal application (compiling stuff, rendering animations or encoding mp3 for example) it's more like 1.8-1.95x (depending on io-rate). My friend bought an Athlon 550 and I went for BP6+2x466 oc'd to 2x545. Neither of us have regretted. I can rip and encode 3 cd's to mp3 in about half an hour (using Grip, see Freshmeat) and compile a 2.2.14 kernel (lots of stuff enabled) under 2 minutes. With athlon and a bit less hefty configuration, 2.2.14 takes about 2.50. So, all in all, it depends what you plan to do with your box.
> What a businessman! The highest possible profit
> came close to janitor wages. I sure can see
> why people listen to him about how to run a
> business.
Last time I checked he did earn slightly more
than an average janitor.
Well, Highpoint 366 support is included in the Andre Hedrick's IDE-patch for 2.2.x (available at ftp.*.kernel.org/pub/linux/kernel/people/hedrick). I'm using it with my BP6, and it works well.
I'm not sure, but I suppose the IDE-patch is is already included in 2.3.x.
Well, heck, why haven't you tried this then?
g z
http://www.s2.org/~jpaana/nv/geforce-3.3-patch.
Work VERY well for me (not a single crash or malfunction) and there's a binary available too:
http://www.s2.org/~jpaana/nv
Now, of course, you want to try 3.9.17...