but my experience is that their "knowledge workers" are as a whole unfriendly and unknowledgable.
Maybe if I was a huge corporation I could get attention from them, but I'm not...
Instead we've learned how to make win95/NT work (more-or-less) right on our own. We're pretty good at it, but this can be a problem for a "real" corporation that buys a "supported" OS and expects a corresponding decrease in tech support they must provide internally.
The first computer I ever used was my Dad's ZX80, which is as old as I am (I was born in 1980).
It had something like 2k of RAM, and could be attached to a tape recorder to save programs.
I learned to code in BASIC on that thing. I wonder where it is?
I think my dad still has a book lying around titled "build your own Z80 computer." Hey, it's the chip in TI's mega-selling TI-8x line of calculators...
It's got some unusual properties -- relatively high tolerance for hard radiation for one. I read the following use in an AMSAT journal a few months back.
It turns out AMSAT (the lunatics who build themselves satellites out of parts they find at KMART:) has been using the same ancient 8bit microcontroller on their satellites for some time now, as most ucontrollers are not suitable to the radiation levels in space. But these days.5 MIPS just doesn't cut it, so they went around looking for a better chip -- and found StrongARM. Their next satellite will have a 133MHz ARM, plenty of CPU power to go around.
My understanding was that while the Banshee and V3 (same 2D hardware as Banshee) had more-or-less working Xservers, there was no Glide support for the boards.
Has this changed? Is there (even almost-working) support for V3 in Linux?
- Die size: this is an early K7 built on the.25u process, while the pIII is.18u, right?
- The k6-3 has L2 on chip, a significant speed boost for non-FP stuff. I imagine AMD will hurry up and add this to the next run of K7's.
- Don't draw any conclusions from white papers on FPU design. Benchmarks are benchmarks. I wouldn't trust anything written about those FPUs, there's just no way to tell what weird stuff will affect performance (e.g. PPro core is fast, but very easy to stall. Result --- some poorly-compiled programs get lousy performance)
in these tests, just CPU FP and INT performance. So it probably doesn't matter, and I'm not surprised they give round numbers for the HD. The only important thing was that the systems be as close as possible to identical.
Of course, I'd still like to verify this m'self. How about a K7, AMD?:)
I've got a Celeron 450a, which has 128K of full-speed L2 cache. It works very nicely. It's debatable which will give better performance, AMD's 128K of L1 and 512K L2 at FSB, or Intel's 32K of L1 and 256K of full-speed L2.
Didn't K6-3 have on-chip L2? If they did it there, they'll likely do it to K7. IIRC, that was the move that made AMD start benching faster than PIII (but not Xeon) for non-FP stuff. A K6-3 would still make a bloody nice webserver, and K7 can do SMP, right?
I'm impressed that (if the tests are true, no way of telling) AMD finally has a machine that appears to be able to keep up w/Intel in FP performance. 3DNow! aside (since it's only used in a few specific applications, and Intel has their own SSE), the old K6 core was pretty pathetic in the FP department, about 40% slower than an equivalently clocked PentiumMMX.
But if K7 can keep up... oooh... 200mHz FSB...
I guess we're all being stupid. If we want fast computers we should abandon this 20 year old mickey mouse architecture and go buy Alphas. Mmmm, Alphas.
The 3DLabs Permidia2 is a _cheap_ OpenGL board -- performs about like a Voodoo1, and has excellent GL under Win95/98/NT -- fully compliant and everything. A decent choice for a business or low end graphics workstation. I think you can get one for $40, maybe even $20.
3DLabs has a variety of much newer, more powerful boards you can learn about at their website. I'm sure some other people make GL boards -- Gloria comes to mind. All $$$$!
Under Linux you can use GL on your Voodoo1 ($30) or Voodoo2/Banshee ($80), supported thru Mesa (not as fast as it could be, since it's Mesa on top of Glide). Under Windoze, you can use 3Dfx's OpenGL ICD, which is really only a subset of GL implemented for Quake (and therefore not really any good for graphix work), and is also slo since it's going thru M$ function calls (yuck). Many other boards have GL ICD's for Windoze, and nVidia is supposed to be writing one for the TNT for Linux.
I really just did a timerefresh in several places on the first level. So it's not very precise. I think it is accurate to within 5fps or so, so it gives you an idea of about how fast the game runs.
I'd actually like to comment on the poor performance people have been reporting on even good machines with Voodoo1's (my friend got lousy fps on a pII-300 w/V1). The V2 can do a big chunk of lighting setup in hardware (it can calculate the gradient along poly edges, whereas on the V1 Glide must do this on the CPU). Since Q3 is heavily lit, this may make a key difference.
I note that SLIing doesn't really improve performance except at very high resolutions -- the V2 alone has more than enough fill to do 640x480 or 800x600 without the fill rate of the card being the bottleneck at all. In most cases the limitation is CPU time for setting up polys (lots of FP). So on a similar system w/o SLI you should get the same 640x480 results as me...
I also note that the AMD machine that's as good as a pII at everything else is going to pay a _big_ penalty running Q3:) Hey, be cool, k7's almost here:)
They're pretty cheap these days too, about $75 for the 8meg version (all you really need anyhow).
I don't know when Linux will support the Voodoo3, but I hope it's soon -- the 2000 only costs about $100, has an excellent 2D card built in, and is (in our benchmarks) exactly as fast as 2 Voodoo2's SLI'd, but it can do slightly higher resolutions (1280x1024 and 1600x1200).
so I would still derive from the more important one. But really only because I like the idea of keeping functionality in the interface object. That is to say, I like thinking of an application as a kind of Gtk window with the added functionality I want in there -- thus, all my code is in objects derived from Gtk base objects.
Unless there's a reason the above pseudocode wouldn't work?
Next question (heavily load w/regard to my next project): how usable is Gtk-- in win32? I don't relish having to use MFC.... brrrrr!
D'oh. Submit button next to preview button.
on
The Desktop Wars
·
· Score: 1
As I was saying -- this forces a coding style on the programmer, to some degree. But this leaves us a lot of flexibility. We could choose never to implement handlers for events as class members. Maybe this is even closer to the way Gtk-- works than I think? I still believe that at some level the programmer should derive a type from the library and add functionality...
I guess I'm not clear here -- why is it wasteful to derive a widget? This is what I mean by virtual function event handling. I would expect to do something like:
//widgetlib.h... somewhere in the bowels of the //widget libarary //please excuse munging of indentation by comment system...
class gtkbutton { ... virtual void handle(click *event)=0; ... }
//now mycode.cpp
class myButton : virtual gtkbutton { ... void handle(click *event) { printf("Why did you click me?\n"); } }
Granted, this may not always be a good idea -- while I like the idea of deriving classes from the widgetset and imbueing them with my own functionality, it's silly to have millions of little button classes. In this case, a more logical organization say at the form level is required -- and here a signalling system makes sense. We connect a function to each signal from a button in our form.
But I still want to derive a form from a base widget class of some kind. It might look something like this:
class appWindow : virtual widget { //conceivably appWindow would be better derived //from some kind of container class, itself derived //from widget? i dunno. gtkbutton *but1, *but2; void but1_click(click *event) { printf("you clicked but1!\n"); } appWindow(...) { but1 = new gtkbutton("foo",...); but2 = new gtkbutton("bar",...); but1.click.connect(but1_click); //but1 has a member click of type signal. we //connect the appropriate function to it. //but2 has nothing connected to its click //handler } }
This has some inherent disadvantages -- it does force a coding style on the
have been on good terms for some time now, according to Ian Peters, the GNOME Games maintainer. Apparently they're working towards interoperability of object models, which will allow components of one desktop to be used with components of the other, giving end users even more free choice.
I'll also note that the moderation system on/. has greatly increase S/N aroud here and reduced pointless flamewars. And increased prevalence of what Ian calls "score whores" -- people who always write long detailed comments (guilty as charged). It's an improvement, by any measure.
Now for a hard jab: I'm not at all impressed with Gtk--. You shouldn't have to do signal handling that way in C++, dammit. I know Gtk+ does things that way, but it's C, it has an excuse. I want nice civilised event handling via virtual functions. Someday I'll write it m'self, I guess.
The only John Williams music I ever liked was his Star Wars stuff, and this music is excellent.
But the recording sounds like SHI*T! Not just the hiss, but all these little pops and whistles and garbage. OUCH!
What on earth did they do to this poor little mp3? This sounds like it was really badly ripped or something like that, not the high-quality high-production-values stuff we expect from Lucas/Williams.
I'm going to guess Daryll will be done 1st -- the V3 is basically the same stuff as V2's (SLI'd), and Glide/Linux already supports that. If Glide works on the Banshee (and it does) then it's not such a big step to the V3.
The TNT people (BTW TNT2 is the exact same hardware as TNT, just overclocked, nVidia guarantees me that if it works on TNT it'll work on TNT2:) have to start from scratch. Ooof.
But hey, I've got a TNT and SLI'd V2's. I win either way:)
how good PGCC is on p6-core processors. In my experience, the key on p6 is not pairing, like it was on the Pentium, but avoiding partial stalls, which empty the pipeline and really fsck things up.
In our own tests, we found that VisualC++ 5.0's (otherwise an excellent compiler) ftol() stalled like crazy on pII's, eating 10% processor power in Fire and Darkness. How good is PGCC at avoiding similar problems.
Are there tools under linux (analogous to Intel's VTune) for analyzing this?
You guys bring tears to my eyes, matching a fully tuned $25k NT box with an untunes $3000 linux box.
If you want some more performance, I suggest moving to a dual system. My experience in SMP linux has only been with dual systems, and it's been very good. In addition, there are some very nice, cost effective dual motherboards out there. Tyan makes one with onboard aha2940 SCSI, Intel 10/100mbit ethernet, and sound too:). Hey, if it's good for/., it must be good enough for everyone else.
I wouldn't be surprised if with some tweaks to your box configuration you could make it as fast as the NT box without any hardware mods, perhaps by following some of the advice Eric links to...
----
I would still like to see some more conclusive stuff on Linux's highend SMP abilities (4 or more), bother on i386 and on Alpha and UltraSPARC. Alan Cox claimed there were some speedups to SMP late in 2.1.x (i think) that should have significantly improved hi end perf. Perhaps VAR would sponsor a test?
If Linux doesn't beat all on up to 16 or so processors, we should fix it...
I can get you an ETA 10 supercomputer (as fast as they came in 1989). Now that would make a great bar, big enough for a casino.
It's at Thomas Jefferson High School for Science and Technology. We won it years ago, but it hasn't worked since my freshman year (I graduated last year). It's a bit big (it's got its own room), so if you want it you'll have to move it yourself...
Slashdot Mirror
but my experience is that their "knowledge workers" are as a whole unfriendly and unknowledgable.
Maybe if I was a huge corporation I could get attention from them, but I'm not...
Instead we've learned how to make win95/NT work (more-or-less) right on our own. We're pretty good at it, but this can be a problem for a "real" corporation that buys a "supported" OS and expects a corresponding decrease in tech support they must provide internally.
Is there an M$ tuning repository? I was not aware of one...
The first computer I ever used was my Dad's ZX80, which is as old as I am (I was born in 1980).
It had something like 2k of RAM, and could be attached to a tape recorder to save programs.
I learned to code in BASIC on that thing. I wonder where it is?
I think my dad still has a book lying around titled "build your own Z80 computer." Hey, it's the chip in TI's mega-selling TI-8x line of calculators...
It's got some unusual properties -- relatively high tolerance for hard radiation for one. I read the following use in an AMSAT journal a few months back.
:) has been using the same ancient 8bit microcontroller on their satellites for some time now, as most ucontrollers are not suitable to the radiation levels in space. But these days .5 MIPS just doesn't cut it, so they went around looking for a better chip -- and found StrongARM. Their next satellite will have a 133MHz ARM, plenty of CPU power to go around.
:)
It turns out AMSAT (the lunatics who build themselves satellites out of parts they find at KMART
I wonder if they'll run Linux
My understanding was that while the Banshee and V3 (same 2D hardware as Banshee) had more-or-less working Xservers, there was no Glide support for the boards.
Has this changed? Is there (even almost-working) support for V3 in Linux?
But I disagree with some of your critiques:
.25u process, while the pIII is .18u, right?
- Die size: this is an early K7 built on the
- The k6-3 has L2 on chip, a significant speed boost for non-FP stuff. I imagine AMD will hurry up and add this to the next run of K7's.
- Don't draw any conclusions from white papers on FPU design. Benchmarks are benchmarks. I wouldn't trust anything written about those FPUs, there's just no way to tell what weird stuff will affect performance (e.g. PPro core is fast, but very easy to stall. Result --- some poorly-compiled programs get lousy performance)
in these tests, just CPU FP and INT performance. So it probably doesn't matter, and I'm not surprised they give round numbers for the HD. The only important thing was that the systems be as close as possible to identical.
:)
Of course, I'd still like to verify this m'self. How about a K7, AMD?
I've got a Celeron 450a, which has 128K of full-speed L2 cache. It works very nicely. It's debatable which will give better performance, AMD's 128K of L1 and 512K L2 at FSB, or Intel's 32K of L1 and 256K of full-speed L2.
... oooh ... 200mHz FSB ...
Didn't K6-3 have on-chip L2? If they did it there, they'll likely do it to K7. IIRC, that was the move that made AMD start benching faster than PIII (but not Xeon) for non-FP stuff. A K6-3 would still make a bloody nice webserver, and K7 can do SMP, right?
I'm impressed that (if the tests are true, no way of telling) AMD finally has a machine that appears to be able to keep up w/Intel in FP performance. 3DNow! aside (since it's only used in a few specific applications, and Intel has their own SSE), the old K6 core was pretty pathetic in the FP department, about 40% slower than an equivalently clocked PentiumMMX.
But if K7 can keep up
I guess we're all being stupid. If we want fast computers we should abandon this 20 year old mickey mouse architecture and go buy Alphas. Mmmm, Alphas.
Someone who doesn't use Linux for the cool desktops? Absurd!
:)
Everyone knows the reason our favorite HolyOS is there is to waste tons and tons of time configuring our desktops.
Hehe, if you took the console and fvwm out of Linux distro's, and forced everyone to use X and some fancy WM, no one would get any work done
The 3DLabs Permidia2 is a _cheap_ OpenGL board -- performs about like a Voodoo1, and has excellent GL under Win95/98/NT -- fully compliant and everything. A decent choice for a business or low end graphics workstation. I think you can get one for $40, maybe even $20.
3DLabs has a variety of much newer, more powerful boards you can learn about at their website. I'm sure some other people make GL boards -- Gloria comes to mind. All $$$$!
Under Linux you can use GL on your Voodoo1 ($30) or Voodoo2/Banshee ($80), supported thru Mesa (not as fast as it could be, since it's Mesa on top of Glide). Under Windoze, you can use 3Dfx's OpenGL ICD, which is really only a subset of GL implemented for Quake (and therefore not really any good for graphix work), and is also slo since it's going thru M$ function calls (yuck). Many other boards have GL ICD's for Windoze, and nVidia is supposed to be writing one for the TNT for Linux.
I really just did a timerefresh in several places on the first level. So it's not very precise. I think it is accurate to within 5fps or so, so it gives you an idea of about how fast the game runs.
:) Hey, be cool, k7's almost here :)
I'd actually like to comment on the poor performance people have been reporting on even good machines with Voodoo1's (my friend got lousy fps on a pII-300 w/V1). The V2 can do a big chunk of lighting setup in hardware (it can calculate the gradient along poly edges, whereas on the V1 Glide must do this on the CPU). Since Q3 is heavily lit, this may make a key difference.
I note that SLIing doesn't really improve performance except at very high resolutions -- the V2 alone has more than enough fill to do 640x480 or 800x600 without the fill rate of the card being the bottleneck at all. In most cases the limitation is CPU time for setting up polys (lots of FP). So on a similar system w/o SLI you should get the same 640x480 results as me...
I also note that the AMD machine that's as good as a pII at everything else is going to pay a _big_ penalty running Q3
I just ran Q3 and hard crashed the system :)
Back up now, and not planning on running it any more for a while...
Sorry to everyone who just got rudely kicked off.
They're pretty cheap these days too, about $75 for the 8meg version (all you really need anyhow).
I don't know when Linux will support the Voodoo3, but I hope it's soon -- the 2000 only costs about $100, has an excellent 2D card built in, and is (in our benchmarks) exactly as fast as 2 Voodoo2's SLI'd, but it can do slightly higher resolutions (1280x1024 and 1600x1200).
On my Celeron 450a w/SLI'd Voodoo2s:
73 fps at 640x480 (had to turn of sync to refresh first)
50 fps at 1024x768 (very respectable)
But the lighting is buggy -- some lights turn off and on as you move even though they're not being blocked by pillars.
I served up 8gigs the day the 2nd SW Trailer came out. Can we beat that?
templestowe.res.cmu.edu
but I would code this example slightly differently, still without deriving from Gtk_Adjustment.
... _ value));
.... brrrrr!
class myApp : Gtk_Window {
private:
Gtk_Adjustment *adj;
void set_value(...) {
}
public:
myApp(...) {
adj = new Gtk_Adjustment(...);
adj.value_changed.connect(slot(*myApp,&myApp::set
}
};
so I would still derive from the more important one. But really only because I like the idea of keeping functionality in the interface object. That is to say, I like thinking of an application as a kind of Gtk window with the added functionality I want in there -- thus, all my code is in objects derived from Gtk base objects.
Unless there's a reason the above pseudocode wouldn't work?
Next question (heavily load w/regard to my next project): how usable is Gtk-- in win32? I don't relish having to use MFC
As I was saying -- this forces a coding style on the programmer, to some degree. But this leaves us a lot of flexibility. We could choose never to implement handlers for events as class members. Maybe this is even closer to the way Gtk-- works than I think? I still believe that at some level the programmer should derive a type from the library and add functionality...
Boy, that code is unreadable w/o indentation...
I guess I'm not clear here -- why is it wasteful to derive a widget? This is what I mean by virtual function event handling. I would expect to do something like:
... somewhere in the bowels of the
...
...
...
//but1 has a member click of type signal. we
//connect the appropriate function to it.
//but2 has nothing connected to its click
//handler
//widgetlib.h
//widget libarary
//please excuse munging of indentation by comment system...
class gtkbutton {
virtual void handle(click *event)=0;
}
//now mycode.cpp
class myButton : virtual gtkbutton {
void handle(click *event) {
printf("Why did you click me?\n");
}
}
Granted, this may not always be a good idea -- while I like the idea of deriving classes from the widgetset and imbueing them with my own functionality, it's silly to have millions of little button classes. In this case, a more logical organization say at the form level is required -- and here a signalling system makes sense. We connect a function to each signal from a button in our form.
But I still want to derive a form from a base widget class of some kind. It might look something like this:
class appWindow : virtual widget {
//conceivably appWindow would be better derived
//from some kind of container class, itself derived
//from widget? i dunno.
gtkbutton *but1, *but2;
void but1_click(click *event) {
printf("you clicked but1!\n");
}
appWindow(...) {
but1 = new gtkbutton("foo",...);
but2 = new gtkbutton("bar",...);
but1.click.connect(but1_click);
}
}
This has some inherent disadvantages -- it does force a coding style on the
have been on good terms for some time now, according to Ian Peters, the GNOME Games maintainer. Apparently they're working towards interoperability of object models, which will allow components of one desktop to be used with components of the other, giving end users even more free choice.
/. has greatly increase S/N aroud here and reduced pointless flamewars. And increased prevalence of what Ian calls "score whores" -- people who always write long detailed comments (guilty as charged). It's an improvement, by any measure.
I'll also note that the moderation system on
Now for a hard jab: I'm not at all impressed with Gtk--. You shouldn't have to do signal handling that way in C++, dammit. I know Gtk+ does things that way, but it's C, it has an excuse. I want nice civilised event handling via virtual functions. Someday I'll write it m'self, I guess.
Why should there be artifacts in the first place? I've been using mpg123 for years and never had any problems...
PS -- Tannin: better mail the alpha address again. But don't expect any alphas unless you're doing a review for someone (or plan to publish it)...
The only John Williams music I ever liked was his Star Wars stuff, and this music is excellent.
But the recording sounds like SHI*T! Not just the hiss, but all these little pops and whistles and garbage. OUCH!
What on earth did they do to this poor little mp3? This sounds like it was really badly ripped or something like that, not the high-quality high-production-values stuff we expect from Lucas/Williams.
I'm going to guess Daryll will be done 1st -- the V3 is basically the same stuff as V2's (SLI'd), and Glide/Linux already supports that. If Glide works on the Banshee (and it does) then it's not such a big step to the V3.
:) have to start from scratch. Ooof.
:)
The TNT people (BTW TNT2 is the exact same hardware as TNT, just overclocked, nVidia guarantees me that if it works on TNT it'll work on TNT2
But hey, I've got a TNT and SLI'd V2's. I win either way
how good PGCC is on p6-core processors. In my experience, the key on p6 is not pairing, like it was on the Pentium, but avoiding partial stalls, which empty the pipeline and really fsck things up.
In our own tests, we found that VisualC++ 5.0's (otherwise an excellent compiler) ftol() stalled like crazy on pII's, eating 10% processor power in Fire and Darkness. How good is PGCC at avoiding similar problems.
Are there tools under linux (analogous to Intel's VTune) for analyzing this?
You guys bring tears to my eyes, matching a fully tuned $25k NT box with an untunes $3000 linux box.
:). Hey, if it's good for /., it must be good enough for everyone else.
If you want some more performance, I suggest moving to a dual system. My experience in SMP linux has only been with dual systems, and it's been very good. In addition, there are some very nice, cost effective dual motherboards out there. Tyan makes one with onboard aha2940 SCSI, Intel 10/100mbit ethernet, and sound too
I wouldn't be surprised if with some tweaks to your box configuration you could make it as fast as the NT box without any hardware mods, perhaps by following some of the advice Eric links to...
----
I would still like to see some more conclusive stuff on Linux's highend SMP abilities (4 or more), bother on i386 and on Alpha and UltraSPARC. Alan Cox claimed there were some speedups to SMP late in 2.1.x (i think) that should have significantly improved hi end perf. Perhaps VAR would sponsor a test?
If Linux doesn't beat all on up to 16 or so processors, we should fix it...
I can get you an ETA 10 supercomputer (as fast as they came in 1989). Now that would make a great bar, big enough for a casino.
It's at Thomas Jefferson High School for Science and Technology. We won it years ago, but it hasn't worked since my freshman year (I graduated last year). It's a bit big (it's got its own room), so if you want it you'll have to move it yourself...