He never once considers (as far as I could tell in my admittedly hasty reading) speed issues for more advanced languages. There are plenty of fancy languages out there, but C/C++ is still the choice for power without sacraficing speed.
That said, I think more powerful constructs are very important, and I've seen several of them implemented in C++, with very positive effects.
Persistance can make managing of not only game objects (i.e. saved games become trivial) but resources very simple, since a resource file (standard formats like TGA or DXF, or your own internal formats) are just simple methods of persisting data. If your data all lives on disk in its "dead" state, it's very easy to organize and bring up what you want out of a database. It's possible to build very intelligent tools, too -- for example, developing the art and changing the game constants on top of a database that detects when you change something and loads it into the running game. Again, I've seen this system implemented in C++.
Along those lines, tools will become increasingly important as games get more complex. If you're going to run a massively-multiplayer RPG on the internet (à la Ultima Online, Everquest, etc) you need to have a crew of people there continously creating new art, models, and code, and they need to have an efficient way of doing it. Metadata about the objects in your game can let older chunks of code learn about and manipulate these objects as they are added. You can also do a lot of this in C++; the framework may be painful but once implemented there's no reason for it to be hard to use.
....
This is all well and good, but I still see a fundamental disconnect between language designers and practical programmers. Language designers are seeking elegant representations for cases that are complex in current practical languages (i.e. the mythical everpresent C/C++), but they aren't usually building "real" programs (the kind of programs you use every day) in them. There are other languages that are very practical, such as Python, or practical in theory, such as Java, but they're not particularly appropriate for games -- they're ungodly slow.
Perhaps it is time for a new language that balances hopefully a cleaner organization than C++ (perhaps dropping or at least heavily restructuring some of the more hopeless features like crazy dynamic casts and this chimaerical exception handling) but maintains the speed inherent in the language. It seems to me that game programmers are largely using a fairly safe subset of C++ anyhow; the representation changes in the language should make it easier to do the things we can now do with difficulty in C++, not make the impossible difficult. After all, that seems to be what Stroustrup was doing when he first wrote the first versions of C++ back in the early 80s.
....
You don't have to agree (except that Java sucks) and I'm not dissing PERL (but it will still never be a game language). Just my $0.02
Because it's something we always need to remember.
It's nice to know Linux is fast (and it's no shame to get beaten out by Novell; they have a lot of experience in the area).
But for 99% of the server tasks people have in this area -- the interoffice server, sharing files and providing print and mail services, you could buy a meatier machine if you needed it. The real issue is reliability and ease of management. You need the thing up, period, because the whole office stops if it's down. And you probably prefer if you didn't have to have a tech for your department just to babysit that one machine. Ideally, your central tech support for all departments (or your part time tech support guy, if you're small) should be able to keep it running with minimal effort. We are, after all, looking for core services here, not cutting edge stuff.
IDG gave Linux the props it's due: Linux will beat out NetWare when it comes to building funky custom solutions. NetWare is very good at what it does. But you have to pay for every server module you want, and they're of course not open and flexible like the Linux ones are. NetWare would make it much harder for you to have that central office machine also be the web development machine for the office -- i.e. not only serve the files, but allow you to update them. And I don't know anything at all about adding database functionality to NetWare to drive a fancier website -- all very easy in Linux, and all there as soon as you want it.
This is one of the most balanced reviews I've seen. I may not agree with their choice of winner, but I can't criticize IDG's fundmental strategy of "choose the best NOS for your capabilities and your needs".
Of course SCO is worthless; and Solaris must be considered for its impressive scalability. Linux is fine for most scalability tasks, with the exception it seems of multiple NICs (which is a weird case anyhow. Rarely does a server need more than a single 100mbit link, and a quad-Xeon Linux box will chew up heavy duty database stuff very sweetly:).
There is no, I repeat no stackguarding technique to completely prevent buffer overflows. Take a look at last week's Kernel Traffic for a summary of a good discussion about this.
Automated library-level checking, whether using a stackguarded compiler or weird stack hacks in the OS is no way to make an app buffer-overflow secure. The only way to do it is continuous human code auditing (and careful initial coding practices), à la OpenBSD. OpenBSD is tight, carefully audited, and in fact provides surprisingly little as far as applications. The size of a typical Linux install is a huge enemy of auditing -- there's just too much stuff to go through. You can however build quite a secure system (assuming you don't have any untrusted local users) simply by strictly limiting which services your machine offers to the outside.
The Internet Worm won't happen again in the UNIX world -- we learned our lesson at the time about poorly written programs and known problems. M$, typically, still hasn't figured this one out. The only reason UNIX users won't be vulnerable to Word Macro-type viruses is that no UNIX user would use such a pathitically stupid application -- and a UNIX user would know better than to execute a random chunk of code he found lying around.
Of course the user can still screw himself if he's dumb, but that's not fundamentally against the UNIX mentality -- 'rm -Rf *' has always been there waiting for you.
...
Actually, a real problem is the fact that most users go looking all over the internet for RPMs of their latest gotta-have applications, without checking the origins. Downloading RPMs from random webpages and installing them as root could be a very bad idea.
cases in GNOME where Win95 did things signifcantly differently -- an example is the configuration box with a series of tabs (Win95's Display Properties, GNOME's Control Center). Both GUIs have the same thing with the same intent, but GNOME's is a bit hard to figure out if you're used to Win95.
In Win95 the "Apply" button does things that can't be canceled by the "Cancel" button. If you change something, then hit "Apply", then "Cancel", your change takes effect. But in GNOME, each individual panel has its own "Try" and "Ok" buttons. It's much more consistent.
If you think about how it makes sense to work (how you'd want it to work if you were a new user who had been introduced to the WIMP paradigm but not the historical idiosyncracies of any particular implementation), GNOME is far more intuitive.
At CMU we now have wireless ethernet everywhere on campus. It's not all that fast, just 1-2 mbit, but it's enough. You can very reasonably run your laptop with X -query yourhomemachine.res.cmu.edu and have everything everywhere.
Till your battery runs out after an hour and a half.
But give me 6 (better, 12) hours of batter life and things begin to look very reasonable. With X style connectivity in a campus environment, you could have all the power of your desktop with you everywhere. Granted, it may be some time before areas larger than a college campus can be wired like this, but it is reasonable for businesses. So if you're willing to do most of your computing in a limited area (i.e. you do spend 40+ hours a week at work or at school, right?), you can have excellent connectivity today. How fast is PalmVII's "everywhere" connectivity? I imagine it'll be some time before that goes broadband...
sigh. I think my SPARC laptop is what Ditzel was talking about when he said people weren't willing to deal with 10 pound laptops that run 90 minutes:)
I can't imagine the scheduler is taking up more than the 20% it's taking up in this benchmark when you run Apache with a zillion processes.
So if the scheduler were infinitely fast, Apache would get 20% faster. BFD. I'm more interested in changing the design of the webserver itself so it's 2-10x faster.
You can't rely on user-space thread switches, it's just too messy. Remember, in theory Win3.1 did user space timesharing, and we all know how much of a joke that was. If you're going to be doing more than one thing at once (conceptually of course) in a single userland context, you should structure your code appropriately for the grain you want and build an event structure or whatever is appropriate. Calls to yield are just flaky -- you should be able to structure things much more intelligently that that.
For example, a webserver has the fundamental building block of a packet on the transport, which has an MTU. So a webserver ought to be able to build a grainsize based on sending at least one (or perhaps several if the packet size is very small, such as ATM; this would be decided by looking at the hardware at configtime or runtime on the server, not a big deal) packet, then considering which client to serve next. Of course it helps massively if you can collect intelligence on what type of connection the client has, i.e. don't try to send more than a few kilobit to modem users, etc etc.
It's bad in the first place if there has to be a VM choosing which code to general (slow slow slow!). I'm only talking about the "real-code" (i.e. traditional, compiled webservers and other multiconnection servers) case here. I don't believe one has the right to complain about performance at all if one chooses to use Java, so even tho "green-threads" style threads might be appropriate and effective for Java, they're not very useful for a real application.
You just need 1 web server process for each NIC; it's the equivalent of having a multithreaded TCP/IP stack for multiple NICs.
That's reasonable, since the processor can fundamentally move much more data than the combined throughput of the NICs (if that's not true, you need a faster processor/better memory bus, of course).
Okay, the Linux scheduler is slower than it could be. It is taking up "up to 20% of CPU cycles" in the very process-intensive (given that native threads are no lighter weight than processes) benchmark, 400-2000 processes.
But there's a more fundamental problem: a 20% speedup isn't significant. I'm not saying we should abandon all speedups that don't affect asymptotic complexity; I'm just saying that I'm looking for speedups of at least 2x-10x before I'm impressed with anything. 20% is small stuff.
There's a bigger issue here: this many processes will never be fast. The cost of a context switch is high given current processor designs, and is not likely to get lower. Even assuming that on a thread switch, since you're dealing with the same data as the previous thread was using, the TLB and code/data caches remain useful (on a process switch in general they don't, and refilling the caches is very expensive), you still have to store a whole bunch of stuff to memory for the old thread and bring a whole bunch of stuff of stuff out of memory for the new thread. And you've got to leave userland for a bit to do that. Slow slow slow slow.
It seems to me that in general we need to reconsider the approach of relying on the operating system to schedule and share resources (in the case of chatservers and ftpservers and especially webservers, where we see the real performance hits for massive thread/process expenses). Right now all this stuff is based on the Berkeley sockets API, a high level network API (i.e. one that doesn't at all consider what the transport will be). This has been a tremendously successful API; it's used on all platforms (well I can't speak for sure for Mac:) and it can be reasonably argued that Berkeley sockets paved the way for the Internet.
But the fact remains that your ethernet card is fundamentally a serial device. I have to wonder if it wouldnt' be possible to write a webserver which does know about the transport for a change, and which could in only one process sit there putting packets onto the wire at a level much closer to the hardware, and therefore save a lot of expense in making the operating system arbitrate all these zillions of threads that want to share the connection.
It would be an interesting project to say the least.
There's already a fast, free, all-ASM operating system out there, just looking for project members!
It's got way more background, and has a much more proven design. Better app support too. It's already got EMACS!!!
It's called ITS, the Incompatible Timesharing System, and it'll run on your frindly Digital Equipment Corporation PDP-10.
It became obsolete sometime in the early 1970s when K & R & T rewrote UNIX in C. For all its faults, honestly the new invention is much easier to maintain.
Your point about speed is completely specious, I'm afraid.
The ability of the PentiumII/III architecture to parallelize certain tasks (via having multiple execution units; the Pentium could do this in a limited way, and all modern chips such as SPARC or Alpha or PPC also do this) does not mean your processor can run multiple tasks at once.
Let me quantify that a bit better: each process (and processes and threads are very close to the same on all Unices, but running NT won't help you in this case) requires its own complete context, consisting of register values on the processor and page tables maintained by the OS. Since the processor only has one set of registers and only one program counter, it can only be executing one thread of instructions at a time. It can parallelize only in a very small local area around the PC. This speeds up execution of the current instruction thread, since you can get other things done (i.e. evaluate other non-dependent instructions) while waiting for a particularly slow instruction to finish. But it doesn't speed up multiple threads.
In fact, context switches (required to switch threads) are very expensive. You have to save out all the register values, load new ones, and bring up new page tables. In addition, unless the two threads happen to be working on the same chunk of memory, all the cache data will have to be thrown out (a significant slowdown).
I'm not arguing that Be is not fast, I know it is. And I'm sure it's possible to take excellent advantage of SMP with microkernels. But there's no way to do single-processor threading on your typical processor (of course you are free to build yourself a processor capable of whatever you want). Period. Sorry.
Suns come with Sun keyboards. The current ones are Types 5 and 6. They are very nice. They have many many keys. They have a blank mystery key. The have a Stop key. They have Ctrl keys in the right place. Old Type 4's are pretty usable, but they don't hold up all that well (I've got a lot of dead ones and a few working ones).
IBMs (RS/6ks) used to come with blessed IBM PS/2 keyboards. When our RS/6k died at my HS, the keyboard was still going strong. I use only IBM PS/2 keyboards on my PCs.
HP PA-RISCs come with fairly standard HP keyboards off the PCs, AFAICT. No special keys.
SGIs come with middling keyboards in funky colors of recycled-looking plastic. Grey and blue and crazy and all.
Never actually seen a DEC Alpha keyboard. Old DECStations came with kinda squishy keyboards.
My SPARC laptop has a standard Lexmark laptop keyboard, it's ok. Needs more Stop and mystery keys:)
You have to have the right keyboard
on
Interface Zen
·
· Score: 2
I agree with a lot of what Tom is saying, though not with the arrow keys -- I have no problem moving my hand slightly to get to them, and I can move one word at a time with the Ctrl key.
Of course the right editor is key. I can use vi, bt not fluently. I use nEdit, which I find extremely efficient and also easy.
But all of this is minor. In the end most of typing in code would work fine in pico. The real critical path is the keyboard. Here at school they seem to buy a lot of Dells with the cheapest keybaord, Dell's horrendous "Quietkey". It's squishy, you can nver tell if you've hit a key.
Sun's Type 5 keyboards are very nice -- good feel, intelligent key location. I use Suns for this reason when I'm not using my computer.
But ah, on my computer, I have a big old IBM PS/2 keyboard. Super tactile click. Indestructible (still working perfectly since '87!). The key doesn't actually contact till exactly on the click, and the peripheral keys are nice and big. The Ctrl key is in the wrong place, but that can be remapped pretty quickly...
I've seen IBM keyboards refurbished going for $50-80, and they're worth it. I'm just glad my highschool had a pile of them on really old machines, so we could just help ourselves when they finally junked 'em.
The chips used in Voodoo4/Voodoo5 are not old chips. They are new fully 32bit colordepth chips. Voodoo3 was the last of the Voodoos based on the old SST1 technology (which does indeed date back to the Voodoo1) AFAIK.
As for the "blurry lines", antialiasing is a major component of image quality. Making an argument on the correct tradeoff for fillrate and polyrate is a subtle thing. GeForce may have the next generation of Voodoos beat for poly rate (I don't have my GeForce, and you can't believe the numbers any of these companies put out; you have to do your own real-world benchmarks), but Voodoo4/5 are clearly ahead in fill rate.
That, to my mind, puts things up in the air as to which will be the better card in the end. Remember, this depends heavily on the kind of things programmers can figure out to do with the technologies available on the board. Not enough programmers are even using the dual texturing currently available on TNTs and Voodoo2+s
...
I guess I just get tired of the automatic siding with the perceived underdogs. Intel had (but seems to have lost) control of the PC chip market, I fully agree. And things are better pricewise and performancewise than they were three years ago, in terms of relative bang for buck (taking into account the predictable scaling in processor speeds).
But I'm not aware that 3Dfx ever had anything resembling a monopoly in the accelerator market. They made the best high-end boards for a long time, and that dominance may now be up in the air. But I'm not aware they ever screwed customers. The 3D market has always been a favorite example of mine of the power of competition -- a lot of companies seeking to one-up the other on a fairly even playing field. And so far the consumer has been the winner.
The GLX thet the TNT2 and TNT uses only works at 15-bit and 16-bit colour. Any other depth and the reverts back to software.
Yes. This was in the release notes. 32bit color would be nice, I agree wholeheartedly.
The driver didn't access all the features of the chipset. There was no advantage in having a TNT2 with 32Mb and a TNT with 16Mb. (Unless you had a ridiculously large Workspace with 32-bit colour, but that has nothing to do with the GLX code)
I have a secret for you: no one cares. 32 megs is on that card 'cos they wanted to have a bigger number on there, but there's no excuse for it. The only case in which you would care is if you literally have 32 megs of textures on the screen at once. Otherwise you can page on and off the card very efficiently. Speaking from experience here, about 4 megs of texture memory is more than plenty.
Basically, If you put a TNT-2 next to a comparative Matrox card (G200?) next to a comparative 3Dfx card (Voodoo2?), the TNT-2 would be only marginally better than a S3 Virge.:-(
You obviously haven't played Q3A on a TNT2 in Linux.
Again, speaking from experience, it's not bad. The cost is a weird one, since you're paying for data sent to the card, so it's kind of like having a slower computer. But it's no where near a Virge.
And this is a problem because of current GLX architecture, i.e. we're making the wrong trade-off now -- GL apps work beautifully in a network transparent way (you can display them remotely) but at a big speed hit. DRI will fix that. But all nVidia's got to do is reimplement their driver to use the DRI version of GLX... doesn't seem like that would be too hard to do given the code they've released. Granted, I've only read the design docs for DRI, not looked at code. So I don't really know how bad it'll end up being.
For that matter, I should really look more closely at the code nVidia released....
My TNT2 Ultra has worked nicely for some months now (since this summer), thank you very much. There's a fully open source (GPL iirc) driver built around Mesa and SGI's GLX.
What is who talking about? Is nVidia talking about a DRI-compliant driver for use with XFree86 4? I would hope they plan to provide one, but if Precision Insight's assorted whitepapers on the subject are on target, porting to DRI shouldn't be that hard...
Comments from someone with some level of clue? Is nVidia just re-releasing old news to have something to say at Comdex?
It's irrelevant what MS stuff comes with NT. Obviously you get the good stuff if you pay the big bucks -- that's always true.
The issue is that MS required you to effectively pay for their product in order to be able to use another product.
In other words, they realized that NT Workstation was much too viable a server platform using 3rd party daemons, and changed the license to make sure you were paying for the MS daemons. That's way more insidious than the bullshit about including a browser in the operating system -- clearly the webserver is not part of the OS here, but if you're going to use anybody's, you've got to pay for MS's.
I'm not sure if I consider that unethical or illegal. It doesn't really matter. No company is going to put up with that -- it's too direct an example of the Free software rationale: if you buy it from one vendor, that vendor can screw you. This has been demonstrated time and time again in the computer industry, starting with the original "renters" of mainframe technology in the 60s.
I could not in good faith recommend a completely proprietary system (i.e. one which could not be replaced by an equivalent system provided by another vendor if necessary) today. It's too dangerous -- no company should be willing to take that risk.
The TNT2 Xserver that comes with potato AFAIK doesn't yet include the 3D stuff.
Even if it does, you still need to get a copy of mesa installed. I see a debian packages listed for Mesa-Glide, but none for Mesa-TNT. So you'll probably need to do what I did: download the binary drivers from nVidia (you can get source if you feel like it). Put the libGL in the appropriate place, and you should probably also uninstall your Xserver package and just put the XF86_SVGA that comes with the nVidia drivers in place.
Solaris, obviously. The userland apps are generally 32 bit (for space efficiency), but the kernel is 64bit.
HP-UX. Those PA-RISC machines are 64bit, right?
IRIX runs on 64bit MIPS chips.
For that matter, several BSDs are truly Unices, and run on some 64bit platforms. NetBSD runs on all of these, right? FreeBSD runs on several of them, and I think even Open has one or two (verification?).
And of course, everyone's favortie 64bit Unix-alike, Linux, which runs on all of the above:)
I've got the source code, but I'll have to reinstall gcc 2.7.2 to compile it (I love you Debian). The static binary core dumped immediately.
Has anyone used VBS? How does it compare to the commercial packages -- where on the scale from Wellspring VeriWell (sucks) to Cadence Verilog (powerful, expensive, runs on SPARCs) is it?
I currently use the free (limited circuit size) version of VeriWell on my Linux box and my SPARC (we can use Cadence on the ECE computers here, but I have yet to design anything that complex). I'd just as soon use something free (or better, Free) that doesn't suck.
Warren Buffet is adamently opposed to stock splits -- he refuses to permit them for his own companies, and discourages them publicly for others.
He believes a stock split artificially inflates the price of stock, and would rather see large pools of investors (as in a mutual fund) buy single shares of high-valued stock to split among investors. You can invest in mutual funds which simply own shares in Berkshire Hathaway.
This goes with this investing advice that "the ideal amount of time to hold a stock for is forever". It's good investment advice, since it relies on the core meaning of the market -- we buy stocks because we believe companies will make money, and we want a share in the profits. It's the furor that ensues when we forget this and start madly speculating that causes investment bubbles and overvalued markets, which is bad for everbody.
Basically, Buffet is the antithesis of a day trader. Obviously, I have a tremendous amount of respect for him:)
Note that there have not yet been any mergers between separate technology manufacturers. nVidia, S3, and 3Dfx make their own chips, but STB and Diamond never did. So there are as many 3D architectures and product lines as there ever were.
It's true that reduction in the number of chipset resellers may hurt consumers, but it'd be tough to argue, since the chipset manufacturers got to set the wholesale price to the resellers in the first place. So 3Dfx, Diamond and nVidia have about the same level of freedom they always have. And of course Matrox and ATI have always made all their own boards.
I for one think it's great the way the 3D market continues to support such diverse offerings. Even though there have been some mergers, the range of architectures has remained the same (with the exception of the demise of Rendition some time ago).
The rate of technological change has if anything increased. The cycle time on new boards is barefly 6 months now. Voodoo3 and TNT2 in the spring, and now Voodoo4 and GeForce in a month or so (?)...
>>No-one's stuff works with anyone else's > >Come on. That's a teeny bit exaggerated. Yes >there are problems, but these are small compared >to using say C or C++ to develop the average >serious cross-platform app.
Ah, but when I mail NetBeans about the fact that the NetBeans IDE doesn't work with kaffe, they tell me, "Use the Blackdown JVM, it's the only one we support." But the speed on my 450a is not acceptable with Blackdown's interpreter. NetBeans doesn't work right with IBM's JITC either. The NetBeans people themselves told me "We recommend our customers turn off JITC."
C'mon, that's sad.
Sure, porting an app between compilers sucks. But for God's sake, when it's done, it works. I can give you a Windows or Linux binary and you can expect it to work. Period. I don't consider dumping this problem off on the user a solution; nor do I expect companies to continually assure compliance with every JVM that comes out. It's a problem you should have to solve once, rather than continually reinventing the wheel.
...
I don't deny, Java has some worthwhile concepts in it. But it doesn't live up to the promise. It's not fast enough to use, and it's not even delivering cross-platform support, due to the difficulty of adhering bug-for-bug exactly to the reference implementation (even worse when each app developer supports a different reference JVM).
Maybe that's why Java has had such slow uptake, according to that recent programmer poll. It's just not that good at getting solutions done yet. Maybe that will change, but I have yet to see the cross-platform major application done successfully in Java. The only use I've seen for it so far is as a toy. C/C++ is a proven solution for a reason.
BTW I know Gtk+ has major problems in its Win32 support that makes it a poor choice for that platform. But it has excellent support (as in perfect) across all Unices, which does cover a lot of ground. I agree that there's still no good way to write completely cross-platform WIMP apps yet.
It's a serious problem.
But I don't see slowing my machine down to the speed of a 486 as a solution. We could also all just buy and use 486s, but no one's suggesting that, either.
...
Coding in assembler can make you a cool hacker. But big assembly projects usually end up as messes -- there's too much detail, and it's too hard to abstract. That's why OSs stopped being written in assembler 25 years ago.
On the other hand, being cross-platform in a large C/C++ project forces some things that are very good for large object models:
- It forces you to abstract design blocks that are not consistent across platforms. This can be a very useful thing since those non-standardized blocks are the ones most likely to change in the future, in which case the abstraction can pay off.
- It forces you to avoid clever hacks and tricks and compiler quirks that really don't belong in any significant project, since they're much harder to understand and maintain later. It'll also make your life much easier when your compiler changes major versions.
This includes, dismissively (evidence the the contrary lacking completely, in my experience)
- all wordprocessors, IDEs, and anything else written in Java. Too many compatibility problems with JITC (no one's stuff works with anyone else's), and otherwise way too slow. Forget it.
- any app run through a web browser. Come on, the web browser is the single flakiest app on my machine. Slow, bloated, crashy. IE5 is better than Netscape but not so much so that I'd want my productivity to depend on a web based desktop. Also forget it.
A call to application developers:
There is, to paraphrase Carmack, a self-imposed discipline that comes from supporting multiple platforms. Get yourself a nice cross-platform widget library, Gtk+ (1.0 works in win32, but they need to spend the time to get 1.2 to win32 perfectly), wxWindows, Qt and pay for it, I don't care.
No Motif. Period.
No MFC. Period.
Anything you write should run beautifully on my SPARC 5 85MHz. Period. Nothing useful may ever require more power than that.
Slashdot Mirror
But I don't necessarily agree with him.
He never once considers (as far as I could tell in my admittedly hasty reading) speed issues for more advanced languages. There are plenty of fancy languages out there, but C/C++ is still the choice for power without sacraficing speed.
That said, I think more powerful constructs are very important, and I've seen several of them implemented in C++, with very positive effects.
Persistance can make managing of not only game objects (i.e. saved games become trivial) but resources very simple, since a resource file (standard formats like TGA or DXF, or your own internal formats) are just simple methods of persisting data. If your data all lives on disk in its "dead" state, it's very easy to organize and bring up what you want out of a database. It's possible to build very intelligent tools, too -- for example, developing the art and changing the game constants on top of a database that detects when you change something and loads it into the running game. Again, I've seen this system implemented in C++.
Along those lines, tools will become increasingly important as games get more complex. If you're going to run a massively-multiplayer RPG on the internet (à la Ultima Online, Everquest, etc) you need to have a crew of people there continously creating new art, models, and code, and they need to have an efficient way of doing it. Metadata about the objects in your game can let older chunks of code learn about and manipulate these objects as they are added. You can also do a lot of this in C++; the framework may be painful but once implemented there's no reason for it to be hard to use.
....
This is all well and good, but I still see a fundamental disconnect between language designers and practical programmers. Language designers are seeking elegant representations for cases that are complex in current practical languages (i.e. the mythical everpresent C/C++), but they aren't usually building "real" programs (the kind of programs you use every day) in them. There are other languages that are very practical, such as Python, or practical in theory, such as Java, but they're not particularly appropriate for games -- they're ungodly slow.
Perhaps it is time for a new language that balances hopefully a cleaner organization than C++ (perhaps dropping or at least heavily restructuring some of the more hopeless features like crazy dynamic casts and this chimaerical exception handling) but maintains the speed inherent in the language. It seems to me that game programmers are largely using a fairly safe subset of C++ anyhow; the representation changes in the language should make it easier to do the things we can now do with difficulty in C++, not make the impossible difficult. After all, that seems to be what Stroustrup was doing when he first wrote the first versions of C++ back in the early 80s.
....
You don't have to agree (except that Java sucks) and I'm not dissing PERL (but it will still never be a game language). Just my $0.02
Because it's something we always need to remember.
:).
It's nice to know Linux is fast (and it's no shame to get beaten out by Novell; they have a lot of experience in the area).
But for 99% of the server tasks people have in this area -- the interoffice server, sharing files and providing print and mail services, you could buy a meatier machine if you needed it. The real issue is reliability and ease of management. You need the thing up, period, because the whole office stops if it's down. And you probably prefer if you didn't have to have a tech for your department just to babysit that one machine. Ideally, your central tech support for all departments (or your part time tech support guy, if you're small) should be able to keep it running with minimal effort. We are, after all, looking for core services here, not cutting edge stuff.
IDG gave Linux the props it's due: Linux will beat out NetWare when it comes to building funky custom solutions. NetWare is very good at what it does. But you have to pay for every server module you want, and they're of course not open and flexible like the Linux ones are. NetWare would make it much harder for you to have that central office machine also be the web development machine for the office -- i.e. not only serve the files, but allow you to update them. And I don't know anything at all about adding database functionality to NetWare to drive a fancier website -- all very easy in Linux, and all there as soon as you want it.
This is one of the most balanced reviews I've seen. I may not agree with their choice of winner, but I can't criticize IDG's fundmental strategy of "choose the best NOS for your capabilities and your needs".
Of course SCO is worthless; and Solaris must be considered for its impressive scalability. Linux is fine for most scalability tasks, with the exception it seems of multiple NICs (which is a weird case anyhow. Rarely does a server need more than a single 100mbit link, and a quad-Xeon Linux box will chew up heavy duty database stuff very sweetly
There is no, I repeat no stackguarding technique to completely prevent buffer overflows. Take a look at last week's Kernel Traffic for a summary of a good discussion about this.
Automated library-level checking, whether using a stackguarded compiler or weird stack hacks in the OS is no way to make an app buffer-overflow secure. The only way to do it is continuous human code auditing (and careful initial coding practices), à la OpenBSD. OpenBSD is tight, carefully audited, and in fact provides surprisingly little as far as applications. The size of a typical Linux install is a huge enemy of auditing -- there's just too much stuff to go through. You can however build quite a secure system (assuming you don't have any untrusted local users) simply by strictly limiting which services your machine offers to the outside.
The Internet Worm won't happen again in the UNIX world -- we learned our lesson at the time about poorly written programs and known problems. M$, typically, still hasn't figured this one out. The only reason UNIX users won't be vulnerable to Word Macro-type viruses is that no UNIX user would use such a pathitically stupid application -- and a UNIX user would know better than to execute a random chunk of code he found lying around.
Of course the user can still screw himself if he's dumb, but that's not fundamentally against the UNIX mentality -- 'rm -Rf *' has always been there waiting for you.
...
Actually, a real problem is the fact that most users go looking all over the internet for RPMs of their latest gotta-have applications, without checking the origins. Downloading RPMs from random webpages and installing them as root could be a very bad idea.
cases in GNOME where Win95 did things signifcantly differently -- an example is the configuration box with a series of tabs (Win95's Display Properties, GNOME's Control Center). Both GUIs have the same thing with the same intent, but GNOME's is a bit hard to figure out if you're used to Win95.
In Win95 the "Apply" button does things that can't be canceled by the "Cancel" button. If you change something, then hit "Apply", then "Cancel", your change takes effect. But in GNOME, each individual panel has its own "Try" and "Ok" buttons. It's much more consistent.
If you think about how it makes sense to work (how you'd want it to work if you were a new user who had been introduced to the WIMP paradigm but not the historical idiosyncracies of any particular implementation), GNOME is far more intuitive.
At CMU we now have wireless ethernet everywhere on campus. It's not all that fast, just 1-2 mbit, but it's enough. You can very reasonably run your laptop with X -query yourhomemachine.res.cmu.edu and have everything everywhere.
:)
Till your battery runs out after an hour and a half.
But give me 6 (better, 12) hours of batter life and things begin to look very reasonable. With X style connectivity in a campus environment, you could have all the power of your desktop with you everywhere. Granted, it may be some time before areas larger than a college campus can be wired like this, but it is reasonable for businesses. So if you're willing to do most of your computing in a limited area (i.e. you do spend 40+ hours a week at work or at school, right?), you can have excellent connectivity today. How fast is PalmVII's "everywhere" connectivity? I imagine it'll be some time before that goes broadband...
sigh. I think my SPARC laptop is what Ditzel was talking about when he said people weren't willing to deal with 10 pound laptops that run 90 minutes
I mean a 2-10x speedup in anything.
I can't imagine the scheduler is taking up more than the 20% it's taking up in this benchmark when you run Apache with a zillion processes.
So if the scheduler were infinitely fast, Apache would get 20% faster. BFD. I'm more interested in changing the design of the webserver itself so it's 2-10x faster.
You can't rely on user-space thread switches, it's just too messy. Remember, in theory Win3.1 did user space timesharing, and we all know how much of a joke that was. If you're going to be doing more than one thing at once (conceptually of course) in a single userland context, you should structure your code appropriately for the grain you want and build an event structure or whatever is appropriate. Calls to yield are just flaky -- you should be able to structure things much more intelligently that that.
For example, a webserver has the fundamental building block of a packet on the transport, which has an MTU. So a webserver ought to be able to build a grainsize based on sending at least one (or perhaps several if the packet size is very small, such as ATM; this would be decided by looking at the hardware at configtime or runtime on the server, not a big deal) packet, then considering which client to serve next. Of course it helps massively if you can collect intelligence on what type of connection the client has, i.e. don't try to send more than a few kilobit to modem users, etc etc.
It's bad in the first place if there has to be a VM choosing which code to general (slow slow slow!). I'm only talking about the "real-code" (i.e. traditional, compiled webservers and other multiconnection servers) case here. I don't believe one has the right to complain about performance at all if one chooses to use Java, so even tho "green-threads" style threads might be appropriate and effective for Java, they're not very useful for a real application.
You just need 1 web server process for each NIC; it's the equivalent of having a multithreaded TCP/IP stack for multiple NICs.
That's reasonable, since the processor can fundamentally move much more data than the combined throughput of the NICs (if that's not true, you need a faster processor/better memory bus, of course).
I've got a fundmental disconnect here ...
:) and it can be reasonably argued that Berkeley sockets paved the way for the Internet.
Okay, the Linux scheduler is slower than it could be. It is taking up "up to 20% of CPU cycles" in the very process-intensive (given that native threads are no lighter weight than processes) benchmark, 400-2000 processes.
But there's a more fundamental problem: a 20% speedup isn't significant. I'm not saying we should abandon all speedups that don't affect asymptotic complexity; I'm just saying that I'm looking for speedups of at least 2x-10x before I'm impressed with anything. 20% is small stuff.
There's a bigger issue here: this many processes will never be fast. The cost of a context switch is high given current processor designs, and is not likely to get lower. Even assuming that on a thread switch, since you're dealing with the same data as the previous thread was using, the TLB and code/data caches remain useful (on a process switch in general they don't, and refilling the caches is very expensive), you still have to store a whole bunch of stuff to memory for the old thread and bring a whole bunch of stuff of stuff out of memory for the new thread. And you've got to leave userland for a bit to do that. Slow slow slow slow.
It seems to me that in general we need to reconsider the approach of relying on the operating system to schedule and share resources (in the case of chatservers and ftpservers and especially webservers, where we see the real performance hits for massive thread/process expenses). Right now all this stuff is based on the Berkeley sockets API, a high level network API (i.e. one that doesn't at all consider what the transport will be). This has been a tremendously successful API; it's used on all platforms (well I can't speak for sure for Mac
But the fact remains that your ethernet card is fundamentally a serial device. I have to wonder if it wouldnt' be possible to write a webserver which does know about the transport for a change, and which could in only one process sit there putting packets onto the wire at a level much closer to the hardware, and therefore save a lot of expense in making the operating system arbitrate all these zillions of threads that want to share the connection.
It would be an interesting project to say the least.
There's already a fast, free, all-ASM operating system out there, just looking for project members!
It's got way more background, and has a much more proven design. Better app support too. It's already got EMACS!!!
It's called ITS, the Incompatible Timesharing System, and it'll run on your frindly Digital Equipment Corporation PDP-10.
It became obsolete sometime in the early 1970s when K & R & T rewrote UNIX in C. For all its faults, honestly the new invention is much easier to maintain.
Your point about speed is completely specious, I'm afraid.
The ability of the PentiumII/III architecture to parallelize certain tasks (via having multiple execution units; the Pentium could do this in a limited way, and all modern chips such as SPARC or Alpha or PPC also do this) does not mean your processor can run multiple tasks at once.
Let me quantify that a bit better: each process (and processes and threads are very close to the same on all Unices, but running NT won't help you in this case) requires its own complete context, consisting of register values on the processor and page tables maintained by the OS. Since the processor only has one set of registers and only one program counter, it can only be executing one thread of instructions at a time. It can parallelize only in a very small local area around the PC. This speeds up execution of the current instruction thread, since you can get other things done (i.e. evaluate other non-dependent instructions) while waiting for a particularly slow instruction to finish. But it doesn't speed up multiple threads.
In fact, context switches (required to switch threads) are very expensive. You have to save out all the register values, load new ones, and bring up new page tables. In addition, unless the two threads happen to be working on the same chunk of memory, all the cache data will have to be thrown out (a significant slowdown).
I'm not arguing that Be is not fast, I know it is. And I'm sure it's possible to take excellent advantage of SMP with microkernels. But there's no way to do single-processor threading on your typical processor (of course you are free to build yourself a processor capable of whatever you want). Period. Sorry.
Hotmail has always run on Apache on top of Solaris, since the very beginning.
:)
Microsoft doesn't make anything with the cojones to handle it
Various workstations have interesting keyboards.
:)
Suns come with Sun keyboards. The current ones are Types 5 and 6. They are very nice. They have many many keys. They have a blank mystery key. The have a Stop key. They have Ctrl keys in the right place. Old Type 4's are pretty usable, but they don't hold up all that well (I've got a lot of dead ones and a few working ones).
IBMs (RS/6ks) used to come with blessed IBM PS/2 keyboards. When our RS/6k died at my HS, the keyboard was still going strong. I use only IBM PS/2 keyboards on my PCs.
HP PA-RISCs come with fairly standard HP keyboards off the PCs, AFAICT. No special keys.
SGIs come with middling keyboards in funky colors of recycled-looking plastic. Grey and blue and crazy and all.
Never actually seen a DEC Alpha keyboard. Old DECStations came with kinda squishy keyboards.
My SPARC laptop has a standard Lexmark laptop keyboard, it's ok. Needs more Stop and mystery keys
I agree with a lot of what Tom is saying, though not with the arrow keys -- I have no problem moving my hand slightly to get to them, and I can move one word at a time with the Ctrl key.
Of course the right editor is key. I can use vi, bt not fluently. I use nEdit, which I find extremely efficient and also easy.
But all of this is minor. In the end most of typing in code would work fine in pico. The real critical path is the keyboard. Here at school they seem to buy a lot of Dells with the cheapest keybaord, Dell's horrendous "Quietkey". It's squishy, you can nver tell if you've hit a key.
Sun's Type 5 keyboards are very nice -- good feel, intelligent key location. I use Suns for this reason when I'm not using my computer.
But ah, on my computer, I have a big old IBM PS/2 keyboard. Super tactile click. Indestructible (still working perfectly since '87!). The key doesn't actually contact till exactly on the click, and the peripheral keys are nice and big. The Ctrl key is in the wrong place, but that can be remapped pretty quickly...
I've seen IBM keyboards refurbished going for $50-80, and they're worth it. I'm just glad my highschool had a pile of them on really old machines, so we could just help ourselves when they finally junked 'em.
on the nVidia/3Dfx thing.
The chips used in Voodoo4/Voodoo5 are not old chips. They are new fully 32bit colordepth chips. Voodoo3 was the last of the Voodoos based on the old SST1 technology (which does indeed date back to the Voodoo1) AFAIK.
As for the "blurry lines", antialiasing is a major component of image quality. Making an argument on the correct tradeoff for fillrate and polyrate is a subtle thing. GeForce may have the next generation of Voodoos beat for poly rate (I don't have my GeForce, and you can't believe the numbers any of these companies put out; you have to do your own real-world benchmarks), but Voodoo4/5 are clearly ahead in fill rate.
That, to my mind, puts things up in the air as to which will be the better card in the end. Remember, this depends heavily on the kind of things programmers can figure out to do with the technologies available on the board. Not enough programmers are even using the dual texturing currently available on TNTs and Voodoo2+s
...
I guess I just get tired of the automatic siding with the perceived underdogs. Intel had (but seems to have lost) control of the PC chip market, I fully agree. And things are better pricewise and performancewise than they were three years ago, in terms of relative bang for buck (taking into account the predictable scaling in processor speeds).
But I'm not aware that 3Dfx ever had anything resembling a monopoly in the accelerator market. They made the best high-end boards for a long time, and that dominance may now be up in the air. But I'm not aware they ever screwed customers. The 3D market has always been a favorite example of mine of the power of competition -- a lot of companies seeking to one-up the other on a fairly even playing field. And so far the consumer has been the winner.
The GLX thet the TNT2 and TNT uses only works at 15-bit and 16-bit colour. Any other depth and the reverts back to software.
:-(
... doesn't seem like that would be too hard to do given the code they've released. Granted, I've only read the design docs for DRI, not looked at code. So I don't really know how bad it'll end up being.
Yes. This was in the release notes. 32bit color would be nice, I agree wholeheartedly.
The driver didn't access all the features of the chipset. There was no advantage in having a TNT2 with 32Mb and a TNT with 16Mb. (Unless you had a ridiculously large Workspace with 32-bit colour, but that has nothing to do with the GLX code)
I have a secret for you: no one cares. 32 megs is on that card 'cos they wanted to have a bigger number on there, but there's no excuse for it. The only case in which you would care is if you literally have 32 megs of textures on the screen at once. Otherwise you can page on and off the card very efficiently. Speaking from experience here, about 4 megs of texture memory is more than plenty.
Basically, If you put a TNT-2 next to a comparative Matrox card (G200?) next to a comparative 3Dfx card (Voodoo2?), the TNT-2 would be only marginally better than a S3 Virge.
You obviously haven't played Q3A on a TNT2 in Linux.
Again, speaking from experience, it's not bad. The cost is a weird one, since you're paying for data sent to the card, so it's kind of like having a slower computer. But it's no where near a Virge.
And this is a problem because of current GLX architecture, i.e. we're making the wrong trade-off now -- GL apps work beautifully in a network transparent way (you can display them remotely) but at a big speed hit. DRI will fix that. But all nVidia's got to do is reimplement their driver to use the DRI version of GLX
For that matter, I should really look more closely at the code nVidia released....
What am I missing here?
...
My TNT2 Ultra has worked nicely for some months now (since this summer), thank you very much. There's a fully open source (GPL iirc) driver built around Mesa and SGI's GLX.
What is who talking about? Is nVidia talking about a DRI-compliant driver for use with XFree86 4? I would hope they plan to provide one, but if Precision Insight's assorted whitepapers on the subject are on target, porting to DRI shouldn't be that hard
Comments from someone with some level of clue? Is nVidia just re-releasing old news to have something to say at Comdex?
It's irrelevant what MS stuff comes with NT. Obviously you get the good stuff if you pay the big bucks -- that's always true.
The issue is that MS required you to effectively pay for their product in order to be able to use another product.
In other words, they realized that NT Workstation was much too viable a server platform using 3rd party daemons, and changed the license to make sure you were paying for the MS daemons. That's way more insidious than the bullshit about including a browser in the operating system -- clearly the webserver is not part of the OS here, but if you're going to use anybody's, you've got to pay for MS's.
I'm not sure if I consider that unethical or illegal. It doesn't really matter. No company is going to put up with that -- it's too direct an example of the Free software rationale: if you buy it from one vendor, that vendor can screw you. This has been demonstrated time and time again in the computer industry, starting with the original "renters" of mainframe technology in the 60s.
I could not in good faith recommend a completely proprietary system (i.e. one which could not be replaced by an equivalent system provided by another vendor if necessary) today. It's too dangerous -- no company should be willing to take that risk.
The TNT2 Xserver that comes with potato AFAIK doesn't yet include the 3D stuff.
:)
Even if it does, you still need to get a copy of mesa installed. I see a debian packages listed for Mesa-Glide, but none for Mesa-TNT. So you'll probably need to do what I did: download the binary drivers from nVidia (you can get source if you feel like it). Put the libGL in the appropriate place, and you should probably also uninstall your Xserver package and just put the XF86_SVGA that comes with the nVidia drivers in place.
It has worked fine for me since day one
still waiting for X 4 and DRI...
Solaris, obviously. The userland apps are generally 32 bit (for space efficiency), but the kernel is 64bit.
:)
HP-UX. Those PA-RISC machines are 64bit, right?
IRIX runs on 64bit MIPS chips.
For that matter, several BSDs are truly Unices, and run on some 64bit platforms. NetBSD runs on all of these, right? FreeBSD runs on several of them, and I think even Open has one or two (verification?).
And of course, everyone's favortie 64bit Unix-alike, Linux, which runs on all of the above
I've got the source code, but I'll have to reinstall gcc 2.7.2 to compile it (I love you Debian). The static binary core dumped immediately.
Has anyone used VBS? How does it compare to the commercial packages -- where on the scale from Wellspring VeriWell (sucks) to Cadence Verilog (powerful, expensive, runs on SPARCs) is it?
I currently use the free (limited circuit size) version of VeriWell on my Linux box and my SPARC (we can use Cadence on the ECE computers here, but I have yet to design anything that complex). I'd just as soon use something free (or better, Free) that doesn't suck.
Warren Buffet is adamently opposed to stock splits -- he refuses to permit them for his own companies, and discourages them publicly for others.
:)
He believes a stock split artificially inflates the price of stock, and would rather see large pools of investors (as in a mutual fund) buy single shares of high-valued stock to split among investors. You can invest in mutual funds which simply own shares in Berkshire Hathaway.
This goes with this investing advice that "the ideal amount of time to hold a stock for is forever". It's good investment advice, since it relies on the core meaning of the market -- we buy stocks because we believe companies will make money, and we want a share in the profits. It's the furor that ensues when we forget this and start madly speculating that causes investment bubbles and overvalued markets, which is bad for everbody.
Basically, Buffet is the antithesis of a day trader. Obviously, I have a tremendous amount of respect for him
Note that there have not yet been any mergers between separate technology manufacturers. nVidia, S3, and 3Dfx make their own chips, but STB and Diamond never did. So there are as many 3D architectures and product lines as there ever were.
It's true that reduction in the number of chipset resellers may hurt consumers, but it'd be tough to argue, since the chipset manufacturers got to set the wholesale price to the resellers in the first place. So 3Dfx, Diamond and nVidia have about the same level of freedom they always have. And of course Matrox and ATI have always made all their own boards.
I for one think it's great the way the 3D market continues to support such diverse offerings. Even though there have been some mergers, the range of architectures has remained the same (with the exception of the demise of Rendition some time ago).
The rate of technological change has if anything increased. The cycle time on new boards is barefly 6 months now. Voodoo3 and TNT2 in the spring, and now Voodoo4 and GeForce in a month or so (?)...
>>No-one's stuff works with anyone else's
>
>Come on. That's a teeny bit exaggerated. Yes
>there are problems, but these are small compared
>to using say C or C++ to develop the average
>serious cross-platform app.
Ah, but when I mail NetBeans about the fact that the NetBeans IDE doesn't work with kaffe, they tell me, "Use the Blackdown JVM, it's the only one we support." But the speed on my 450a is not acceptable with Blackdown's interpreter. NetBeans doesn't work right with IBM's JITC either. The NetBeans people themselves told me "We recommend our customers turn off JITC."
C'mon, that's sad.
Sure, porting an app between compilers sucks. But for God's sake, when it's done, it works. I can give you a Windows or Linux binary and you can expect it to work. Period. I don't consider dumping this problem off on the user a solution; nor do I expect companies to continually assure compliance with every JVM that comes out. It's a problem you should have to solve once, rather than continually reinventing the wheel.
...
I don't deny, Java has some worthwhile concepts in it. But it doesn't live up to the promise. It's not fast enough to use, and it's not even delivering cross-platform support, due to the difficulty of adhering bug-for-bug exactly to the reference implementation (even worse when each app developer supports a different reference JVM).
Maybe that's why Java has had such slow uptake, according to that recent programmer poll. It's just not that good at getting solutions done yet. Maybe that will change, but I have yet to see the cross-platform major application done successfully in Java. The only use I've seen for it so far is as a toy. C/C++ is a proven solution for a reason.
BTW I know Gtk+ has major problems in its Win32 support that makes it a poor choice for that platform. But it has excellent support (as in perfect) across all Unices, which does cover a lot of ground. I agree that there's still no good way to write completely cross-platform WIMP apps yet.
It's a serious problem.
But I don't see slowing my machine down to the speed of a 486 as a solution. We could also all just buy and use 486s, but no one's suggesting that, either.
...
Coding in assembler can make you a cool hacker. But big assembly projects usually end up as messes -- there's too much detail, and it's too hard to abstract. That's why OSs stopped being written in assembler 25 years ago.
On the other hand, being cross-platform in a large C/C++ project forces some things that are very good for large object models:
- It forces you to abstract design blocks that are not consistent across platforms. This can be a very useful thing since those non-standardized blocks are the ones most likely to change in the future, in which case the abstraction can pay off.
- It forces you to avoid clever hacks and tricks and compiler quirks that really don't belong in any significant project, since they're much harder to understand and maintain later. It'll also make your life much easier when your compiler changes major versions.
this is way offtopic. woohoo!
I don't want to run apps that suck.
:)
This includes, dismissively (evidence the the contrary lacking completely, in my experience)
- all wordprocessors, IDEs, and anything else written in Java. Too many compatibility problems with JITC (no one's stuff works with anyone else's), and otherwise way too slow.
Forget it.
- any app run through a web browser. Come on, the web browser is the single flakiest app on my machine. Slow, bloated, crashy. IE5 is better than Netscape but not so much so that I'd want my productivity to depend on a web based desktop.
Also forget it.
A call to application developers:
There is, to paraphrase Carmack, a self-imposed discipline that comes from supporting multiple platforms. Get yourself a nice cross-platform widget library, Gtk+ (1.0 works in win32, but they need to spend the time to get 1.2 to win32 perfectly), wxWindows, Qt and pay for it, I don't care.
No Motif. Period.
No MFC. Period.
Anything you write should run beautifully on my SPARC 5 85MHz. Period. Nothing useful may ever require more power than that.
...
The OpenDesktop song is pretty good tho