If you've just bought a bunch of expensive Windows or Solaris servers, why would you later decide to throw them all away and buy new servers just so you could move your software to another OS?
Sure. It's all about the scalability. If I find that I've scaled my app to the limit of say, the IA-32 architecture, I can move to a more powerful architecture like AMD64 or Sparc. All depends on the needs. If there's a bottleneck between the machines, maybe it's time to replace them with that 64 way Starfire. If the problem is maintainability of these systems, maybe I need to move from Windows to *nix.
And let's not forget development. It's nice for the developers to be able to develop on Windows or Macs and deploy on Solaris servers.
There are a lot of reasons to change architectures, even on the server side.
I'm sorry, but if you can't manage to track down a JVM for your platform, you need your geek card revoked. I mean, hell, there are JVM instructions built into the damn ARM processors! What more do you want, an Angel to come down from the sky and say, "Hey you, over that way!"
Re:C++ is cross-platform, dont know what your smok
on
Write Portable Code
·
· Score: 1
Now where did I put that interpreter again? Ah! Here it is! *oof*. Geez, that's getting heavier every year.
The interpreter is small. So is the JIT. That's why those are the options usually offered on cell phones and other embedded devices. It's the highly optimized, mixed-mode execution model that gets us such a massive chunk of translation. It is fast, though.;-)
I refer to the trend I've seen where types are checked at run-time out of laziness instead of using plain old polymorphism.
You mean like this: "if(object instanceof MyObject) DoSomthing();"?
There are a lot of good reasons to do that. However, I do agree that some programmers abuse it. If they'd just create an Interface, they could stop with the "if" statements.
Then again, I spent a lot of time in the embedded world, where you do as much at compile time as you can to avoid spending the time, code, and memory, to do it at run-time. Footprint matters.
Ah, different worlds. Java's most popular platform (business logic) requires maintainability and architectural clarity above all else. So plugging code at odd times can make a lot of sense. In the embedded world, stripping your Java code down is one of the first things you do. And I say this as a previous winner of the Java 4K Coding Contest.
Re:C++ is cross-platform, dont know what your smok
on
Write Portable Code
·
· Score: 2
gotta......ugh......carry......all... *pant*...that... *wheeze*... run time type information...around. Whew!
And yet, Java programs tend to compile to smaller files than native code, and also take a far shorter period of time. Even on the largest projects, I can compile Java code inside of ten minutes. It can take days to compile a C program of comperable size. And once it's in bytecode, it's only a short hop for the JVM to compile it to native code. Works pretty darn well.:-)
Still, the whole idea of using RTTI to defer what should be a compile-time decision to run-time just leaves a bad taste in my mouth.
Not sure what you mean by this. Pretty much all code with direct references are properly checked at compile time. Obviously the run-time has to be a bit smarter when you dynamically load things via reflection, but that's very much a feature, not a bug.
Besides, you gotta love the ability to build a self-organizing program scheme in 20-30 lines of Java code. Doing the same thing in C++ is a PITA, and would only serve to confuse the heck out of the developer debugging the app and the OS trying to run it. I can just see it now, "Program X has 3,102 DLLs loaded.";-)
If it's doing that much work in the software, and can't be reasonably done on the GPU, they should just put a damn CPU on the graphic card.
To what end? You've got a perfectly good CPU sitting inside your computer, and it's generally not doing anything anyway. Plus you've got memory galore for all those complex transformations. Why stick yet another computer onto the VidCard?
Re:C++ is cross-platform, dont know what your smok
on
Write Portable Code
·
· Score: 1
You forgot reflection. Reflection is the key to the awesome serialization, and is useful for all kinds of cool and interesting stuff.:-)
AJAX is a bridge thin-client technology that doesn't go as far as to shunt an entire desktop across the network, yet is robust enough to support nearly any application. All the real logic is usually done on the server using a real language. (No matter how much I grow fond of JavaScript, I will never think of it as a "real" language.)
As a thin client platform it works pretty well. As a general purpose coding platform it sucks. You still need to have a portable language on the server or you won't be able to move your code from system to system. (Though you will have the client nailed.)
mix that with the fact that java doesn't run well for most things that people try and use it for..
Most people seem to be doing server side development with it. Works fine.:-)
i am sorry but without inter proccess comunication it is usless to me.
You mean like TCP/IP, CORBA, RMI, SOAP, XML-RPC, etc.? You need to be more specific if you're going to complain. BTW, there are libraries for SMB Remote IPC and POSIX IPC, but using either of them won't result in very portable code under ANY language.
Which raises the question, what exactly are you doing that you need native IPC?
If you write C# or Java, there is a middle man in there. The OS has to load this whole runtime environment, which takes up a big memory footprint and system resources, and then interprets your code, and then based on that tells the processor what to do.
That's precisely why the Java Runtime should be the OS.;-) (I'm only half joking, too. Java is basically an OS platform. Moving it down isn't that big of a step.)
BTW, Java might be interpreted, or it may be JITted, it may be run in a mix of the two, or it may be outright pre-compiled. Depends on the runtime.
And I'd just like to say that the mods are a bunch of pricks for modding 955301 down. Remember the modding guidelines? Mod UP, not down. If you don't like it, leave it alone.
Dude. Java is everywhere. It's in tiny little cards and in the latest ARM processors. You can't run. You can't hide. Java will find your OS, and you will be assimilated. Submit to the collective!
They've been changing with greater frequency as the years go by. The rise of digital wireless technology has had the FCC scrambling to reorganize the bands. Examples of this include the Digital TV bands, Family Bands, and Internet over Powerlines. They're also considering new technologies such as Ultra Wide Band to ensure that such tech doesn't interfere with existing bands.
2/3. You are arguing for a flexibility in the cards that is unneeded/unused. Vendors still want to release new cards to follow changing technology.
Only for major changes. Minor changes to improve the performance of existing hardware usually results in new drivers.
Speaking of which, where were your simple firmware updates when WPA came out, and now WPA2?
Firmware would be the problem. A new encryption standard on the card would require new hardware for decryption. Handled in the software (not firmware), the card could be updated with the feature. I can't speak to your particular card, but it's probably because you chose a card with self-contained firmware that you had to purchase a new card. Sorry. Get a software controlled one next time.
Despite the advantages of having a software driven card, vendors still sell hardware.
Yes they do. And if they can get away with not having to design a brand new piece of hardware, they will. Hardware development costs are tremendous and are generally avoided whenever possible. Which means that many hardware manufacturers strive to design their hardware with software controls so that they can repackage/rebrand with a few software changes on the same hardware. Most of these manufacturers will then release the driver updates for Windows. Using Linux? Too bad, you're using something someone else wrote.
Any code to modulate and regulate the transmitter is fairly constant and doesn't need to be in software.
Are you a HAM operator? How do you know this with any certainty? Most radio equipment has a reasonably large frequncy band available. From the Wikipedia article on IEEE 802.11, section 802.11b:
802.11b and 802.11g divide the spectrum into 14 overlapping, staggered channels whose center frequencies are 5 megahertz (MHz) apart. It is a common misconception that channels 1, 6 and 11 (and, if available in the regulatory domain, channel 14) do not overlap and those channels (or other sets with similar gaps) can be used such that multiple networks can operate in close proximity without interfering with each other, but this statement is somewhat over-simplified. The 802.11b and 802.11g standards do not specify the width of a channel; rather, they specify the center frequency of the channel and a spectral mask for that channel. The spectral mask for 802.11b requires that the signal be attenuated by at least 30 dB from its peak energy at ±11 MHz from the center frequency, and attenuated by at least 50 dB from its peak energy at ±22 MHz from the center frequency.
Since the spectral mask only defines power output restrictions up to ±22 MHz from the center frequency, it is often assumed that the energy of the channel extends no further than these limits. In reality, if the transmitter is sufficiently powerful, the signal can be quite strong even beyond the ±22 MHz point. Therefore, it is incorrect to say that channels 1, 6, and 11 do not overlap. It is more correct to say that, given the separation between channels 1, 6, and 11, the signal on any channel should be sufficiently attenuated to minimally interfere with a transmitter on any other channel. However, this is not universally true; for example, a powerful transmitter on channel 1 can easily overwhelm a weaker transmitter on channel 6. In one lab test, throughput on a file transfer on channel 11 decreased slightly when a similar transfer began on channel 1, indicating that even channels 1 and 11 can interfere with each other to some extent.
In theory, it could be a single port that the driver crams all requests and data into and the GPU does whatever it wants and hands any return data back on a second port, although there are obvious thoroughput problems there.
Oh Lord. Save me from the ignorant. Hardware systems are NOT that easy to design. The GPU doesn't do JACK other than crunch some numbers, and it's already one of the most complicated devices in existence! (Primarily thanks to the complex pipeline designs, the number of parallel pipelines, and the microcode space and execution hardware carried on chip and intertwined with each pipeline.) ALL the real work is in the software. The hardware just executes its instructions. If you tried to cram all the work the software is doing into the hardware, you'd have something more complex than the latest Pentium and NVidia GPU combined. Not to mention that you'd never be able to increase performance through driver updates.
And you need to be careful with your concepts of Ports. Bus design is tricky business and can easily bottle up the entire computing platform if you're not careful. Many commands on one bus is something you see more of in general purpose computing where the raw performance isn't an issue. In the case of a GPU, raw performance IS an issue, and the software directly controls the entire bus + the GPU.
What the hell are you talking about? I wasn't complaining about GPUs or CPUs.
That's because you have no idea what you're talking about. The hardware doesn't do video processing. I don't know how many times I'm going to have to repeat that. It's all software, and it's all trying to compile the instructions, reorder them, JIT microcode, parallelize the data, and do other complex optimizations that will actually feed the computations into the GPU. The GPU spits out an answer that ends up in VRAM. How nice.
And, before you ask, I do indeed program, although admittedly it's been a decade since any assembly language.
No offense, but ASM is way off in left field. We're talking hardware design here. And the only way to truly understand hardware (including the software that drives it and WHY it drives it that way) is to go design some yourself. Unlike yourself, I've actually taken the time to do so, and now understand why things are the way they are. I'm not sure how I can get this through your skull, but complex hardware is HARD and EXPENSIVE. It never makes sense to use hardware when software will do the job just as effectively (or in this case, more so).
When it does make sense is when you're trying to accelerate very specific and abstract mathematical operations. e.g. Matrix math can be easily accelerated in hardware. Drawing a line on the screen? Not so much. If you want to accelerate something like drawing a line, you'll want to use Microcode. Microcode is tiny software that loads up and executes on the CPU itself. Microcode is pretty micro though, so it can only go so far. To do something more complex, (say, draw a shape with those lines) you want to bump it up to software. The on-chip cache will keep the code running smoothly inside the chip so that the software isn't constantly crossing the bus during the operations. Thus you end up with software that drives the hardware.
Now imagine that you had software that waited until you had drawn all the objects with lines, then sorted them to figure out which ones get drawn in what order, removes any lines that are hidden, checks which lines can be drawn in parallel because they don't cross, then does a final reordering of the line drawing commands so that the hardware can draw four lines simultanousously (complicated by the fact that some lines are shorter than others, and will take fewer cycles to complete). That is what your big blob of "useless" software is doing.
If you think there's a better way this stuff can work, then by all means. Go design some hardware and show the world. (It's not that hard to get started. Really.) In the meantime, though, just be quiet. You're making yourself look bad.
Indeed. However, I was referring to the use of small batteries in devices that never die, which is something that we don't have today. All the current RTGs/SRGs are big monsters that act as a small power plant for a craft or scientific equipment. Russia used to use the things to power Lighthouses indefinitely.
So far no one has actually brought a miniturized version to market, though.:-)
Precisely. Though I'm still holding out for SRGs and other more efficient heat engines.
What do you mean I'll get cancer?
What d'ya mean, what d'ya mean? You could shield Alpha radiation with a sheet of paper, and Beta radiation with a bit of foil. You'd get more radiation exposure from the Earth's crust than you would a hundred Plutonium-powered cell phones.
true mobility. Connected and powered 24/7, anywhere.
Would be nice wouldn't it? Unfortunatly, there are exactly three devices that can make this happen:
1) A portable solar generator and battery. This only works as long as the generator is able to produce more than ample power to cover periods where sunlight is unavailable and the panels are always facing the sun. e.g. The roof of a car. Plus you still have to charge devices in it.
2) Beaming power to devices. This is actually related to solar power as it reqires that a laser or maser hold a targetting lock on your device's power converter. Besides how tricky this is to implement, it's also dangerous to be broadcasting a number of lased transmissions in the multi-watt range.
3) Harnessing the radiation from radioisotopes. This is the most promising option as there are several types of radioisotope that are easy to contain, and no more dangerous than today's battery chemicals. This option could easily provide power in the 1-50 watt range, 24x7 for 10-30 years. The drawbacks to this method are a) radioisotopes are too expensive, b) the public has an irrational fear of anything "nukular", and c) the radioisotopes must be treated as hazardous waste (just like batteries) and disposed of properly.
I fully expect that option 3 will be embraced by future space explorers. It just wouldn't do to have equipment that can't survive long spans of time away from a charging station.
In the case of the wifi cards, though, the transmitter power is set in software. There is absolutely no reason for this because the transmission strength is heavily regulated by the FCC.
1. FCC regulations change. 2. Radio transmissions are tricky things. A Wifi producer might release a patch that provides greater range by constantly modulating the power levels, yet remaining within the FCC's guidelines. 3. It's about a lot more than power. You can accidently generate a massive amount of broadband radio noise if you're not careful. Basically, the software is playing HAM operator with the Wifi card in order to tune the best performance out of it without running afoul of regulations. That's a good use for software.
I said they licensed an OpenGl implementation from somebody that won't let them open the code (or so they say).
You're not listening
The OpenGL implementation is seconday. Forget about it. We're talking about REAL technology that buffers, tweaks, and translates 3D requesting into highly sophisticated instructions that feeds to the GPU, manage VRAM, and generally control the entire 3D video bus. All that has JACK to do with OpenGL. OpenGL is just an API. It's unimportant. The real code is the stuff going on under the hood that tells the GPU "this is how you Antialias" or "this is how you rotate the textures" or "I've automatically prepped this bit of microcode to make this routine faster". The end result from the *drivers* is little more than a bunch of complex math instructions and VRAM updates. The GPU doesn't even know or care that it's calculating 3D pictures. It's just doing what the drivers tell it to do.
When you consider that the translation from 3D down to sets on complex math instructions happen only in software, it should become clear that NVidia and ATI didn't develop all that technology by themselves. There's simply too much complexity there. Thus they licensed NOT OpenGL, but all kinds of bits and pieces of 3D trickery, microcode, and hardware design thats patented by someone else, produced by someone else, and only made use of by NVidia and ATI in as quick of a fashion as possible so they can beat each other to market.
If you still think it's about the OpenGL implementation, you need to exit the computer market because you have not a clue what you're talking about.
A lot of hardware in linux gets supported by someone reverse-engineering the damn chip because they can't get the specs, and the driver ends up working as good as or better than anything that gets released by the vendor, if that ever happens.
That's why there are full drivers for NVidia, right? No wait, there aren't.
That's why there are full drivers for WinModems, right? No wait, there aren't.
That's why there are full drivers for WiFi cards, right? No wait, there aren't.
Hell, it took 5 years to get USB right, and it still has problems. I'm not sure what you're so impressed by.
The OSS drivers are workable, but in most cases they only exist for reasonably simple devices (or standardized devices), and they don't support the full feature set of those devices. Sometimes the only way they get the job done is because the card exposes the underlying chipset which they can find manufacturer documentation for. There's no magic here, I'm afraid.
Oh, well then. I'm sure that's very Free(TM) and Open(TM). I'm also sure that any 3D designs you need to do will be very easy to do on your GameCube. Good luck on that.
Linux is software made for companies
Pretty much every company I've been in would prefer driver support from the hardware vendor because "they know their hardware better than anyone else." In fact, the *only* ones I see who don't want a standard driver ABI are the Linux OSS people who don't want it for philosophical reasons. Which would be fine if they weren't trying to force the hand of every hardware company in existence, but they are.
You know what I think? I think you should actually TRY designing a CPU. You may not find things to be as cut and dry as you think. Here's some great tools to get you started. Hope you have a good grasp on the parallelism of circuit design, and understand microcode, instruction decoders, on-chip cache, and pipelining. When you're ready to put your masterpiece in fabric, go grab an FPGA and check to see if you made efficient enough use of silicon to make it fit.
When you're done, show us your design and we'll show you how the existing stuff has been done better.
Their 'serious advantage' is THE major cause of their operating system's most notable problem, aka blue screens.
That sounds like a fucking stupid 'advantage' to me.
Linux's 'serious advantage' is THE major reason why I couldn't have USB until 5 years after the spec was released.
That sounds like a fucking stupid 'advantage' to me.
Damn thing still never works right. (It was working correctly in BSD in '98! What the hell is the problem?)
In the worse case, it might be due to someone emailing patches to you and telling you to try them out, because no one has exactly the problem, but by gum they'll fix it.
You mean like the USB Intelli-mouse problem that I was having that had hundreds to thousands of reports on the kernel mailing lists but wasn't ever fixed? The only fix was that Microsoft changed their hardware to a new model.
That sounds like a fucking stupid 'advantage' to me.
When it blue screens in XP? Well, I dunno, because the damn company that made the cable went out of business before XP and their driver from 2000 doesn't work.
As opposed to the unmaintained drivers in the Linux kernel that no longer work, in part because no one has the cable any longer because the company went out of business. Good plan there, chief.
This is because producing drivers is not their business, whereas it is the 'business' of Linux kernel developers.
Let's stop the wanking and be serious here for a moment. The only business of the Linux developers is to scratch the itch they feel like scratching. They'll sometimes go out of their way for users, but if they don't think highly of you or your bug report than you can expect it to get buried. That's what happens when the users aren't actually customers.
BZZZT! This is due to GOOD hardware design. By moving many of the controls to the software logic, the chips can be made simpler and more flexible. New features can be added by simply upgrading the software rather than requiring the consumer to purchase a new card.
A perfect example of this is a video capture card I used to have. The signal lock was handled in software. Unfortunately, the initial release couldn't lock onto some of the more esoteric timings. (TV signals come in a few slightly different timing depending on if it's broadcast, RCA, or an RF feed.) Had they hardcoded these timings in the hardware, they couldn't have released a new version that supported everyone's video cameras.
I'm sure you'll argue that they should have got it right the first time, but consider this: How many times have you "gotten it right" when you followed the spec to a 'T', only to find that there were slight variations on the spec by different implementations?
If you are referring to NVidia's licensed OpenGL implementation, the solution is to use an open source implementation, such as Mesa.
You really have no idea how these cards work, do you? The GPU isn't a magic implementation of a 3D processor that you can just plug APIs into. It's a high-performance, multi-pipelined, single-instruction/many-data, vector processor! It relies exclusively on the drivers to correctly feed it the data in such a way as to keep all the pipelines at maximum saturation, and all features of the chip at maximum utilization. Every release of the drivers that come out are nothing more than more optimizations to help common games make the best use of the silicon. If you think it's JUST an OpenGL implementation, you need to do your homework!
Nevermind the fact that a lot of hardware vendors don't actually support NDIS to begin with.
They would if it was better supported.
You know those wireless drivers that came with your card that you had to load separately in Windows, and they have their own little control panel? Not NDIS.
Okay, let's be honest here. Do you *really* need the little control panels? Even if we do, let's consider for a moment that the cross-platform ABIs/APIs could be updated to support such features. The only reason why it hasn't is that no one uses NDIS or UDI. They have got to be some of the most useful yet ignored technologies in the history of computing! Yet everyone is so happy because X-Windows has a platform independent API for drivers built in, when those drivers should be OS drivers.
Seriously, vendors can offload a lot of work and we can get higher quality drivers (on all platforms) if they would just release the specs.
Most of the ones who can, either have or are simply not that great of vendors. You and many others severely underestimate the problems inherent in releasing them.
Vendors are refusing to release specs because drivers have always been proprietary.
Yeah, whatever. Speaking as someone who was programming computers since before anyone had even heard the word "driver", I can say with confidence that the only reason for the current situation is that Microsoft pushed the responsibility of creating drivers for Windows onto the manufacturers. Prior to that you had to develop your own damn hardware interfaces. We were absolutely shocked when Creative gave the world a loadable API module for controlling their sound card. That was simply unheard of!
I'm sure you'll go off into a rant about how Microsoft was just being Microsoft, But you know what? Microsoft was right on this one. Supporting that much hardware is crazy for one. For another, hardware today is simply too complex for everyone to be developing their own drivers. Considering that some hardware is on the level of the most sophisticated interaction between software and hardware ever developed, I'd say that we should be counting ourselves lucky we have the drivers at all.
Of course that means I'd need to LEARN JMF, which for what I'm doing might not be a bad thing, but still, it's another library that I don't know yet.
Can't help you there. It's been forever since I last used the bugger.:-)
And as I put in my original reply above, the bitwise-AND is what I was already doing
Oh, sorry. I missed that part. Well, hope some of what I said was useful, anyway.
Thanks for your help man.
Wish I could do more, but it sounds like you've generally got a good grasp on things. I'm not precisely sure what you're doing (PAL capture?), but the bitwise and should serve you well for most everything you'd need to do. If you really need the performance, then the SIMD route might be worth exploring.:-)
Then we in the Linux community just won't buy their stuff
Good luck on those video games, then.
or find ways to force it to work when we do (ndiswrapper or reverse engineering).
I really should be snickering like an idiot at this. Really. Read the first four letters of the driver name you just gave. Now think long and hard about how much trouble could have been saved if Linux had just supported binary NDIS drivers in the first place.
What I'm actually doing is bringing in image data in a 4:2:0 format
YUV! Gotta love that stuff. (Not.) Perfect for reducing bandwidth with only minor information loss, though.:-)
I can see why you're looking for bitwise manipulation.
As long as you're not looking for real-time performance, all you need to do is try this little trick:
public class Test {
public static void main(String[] args)
{
byte test = -20;
int unsigned = (0xFF & test);
System.out.println(unsigned);
} }
You should get 236 instead of -20. This works because the JVM implicitly casts the byte to an int by padding it to four bytes before performing the operation.
Your mention SIMD instructions intrigue me though. What can be done in Java on that front?
Me and my big mouth. Ok, here goes. This whole thing is a bit on the undocumented side, so you'll have to hang with me here. Basically the ByteBuffers give you a raw memory block on both the native and Java side. Now Java can't execute SIMD directly (though they are working on adding such a thing to the Math package in the future), but it can define and control such streams. So what you want is to create an SPI plugin that creates a channel that does what you want. In your channel code, you need an input buffer and an output buffer. (Or at least, I assume. You can operate on the same data if you want, but I assume you're converting to the much larger RGB format.) You can then select the processor in your code. You'll probably want a pure Java version that uses the trick above to perform the conversion to fall back on. But for systems where you have native drivers, you can use JNI to write a small bit of C/C++/Assembler to execute a bit of SIMD on the two byte buffers.
Basically, you want to tell the SIMD instructions (be they SSE, Altivec, or Sparc SIMD) to operate on the memory block at the byte buffer location, and put the results of the operations at the second byte buffer memory location. You would then have a super-fast YUV -> RGB channel with only a minor amount of optional accelerator code.
Now, with that out of the way, can I ask a question? Is there any chance that the ImageIO package or JMF already does what you need? (JMF has a bunch of fast YUV stuff built-in.)
Slashdot Mirror
If you've just bought a bunch of expensive Windows or Solaris servers, why would you later decide to throw them all away and buy new servers just so you could move your software to another OS?
Sure. It's all about the scalability. If I find that I've scaled my app to the limit of say, the IA-32 architecture, I can move to a more powerful architecture like AMD64 or Sparc. All depends on the needs. If there's a bottleneck between the machines, maybe it's time to replace them with that 64 way Starfire. If the problem is maintainability of these systems, maybe I need to move from Windows to *nix.
And let's not forget development. It's nice for the developers to be able to develop on Windows or Macs and deploy on Solaris servers.
There are a lot of reasons to change architectures, even on the server side.
Is that all you're waiting for? We've had that for years.
I'm sorry, but if you can't manage to track down a JVM for your platform, you need your geek card revoked. I mean, hell, there are JVM instructions built into the damn ARM processors! What more do you want, an Angel to come down from the sky and say, "Hey you, over that way!"
Now where did I put that interpreter again? Ah! Here it is! *oof*. Geez, that's getting heavier every year.
;-)
The interpreter is small. So is the JIT. That's why those are the options usually offered on cell phones and other embedded devices. It's the highly optimized, mixed-mode execution model that gets us such a massive chunk of translation. It is fast, though.
I refer to the trend I've seen where types are checked at run-time out of laziness instead of using plain old polymorphism.
You mean like this: "if(object instanceof MyObject) DoSomthing();"?
There are a lot of good reasons to do that. However, I do agree that some programmers abuse it. If they'd just create an Interface, they could stop with the "if" statements.
Then again, I spent a lot of time in the embedded world, where you do as much at compile time as you can to avoid spending the time, code, and memory, to do it at run-time. Footprint matters.
Ah, different worlds. Java's most popular platform (business logic) requires maintainability and architectural clarity above all else. So plugging code at odd times can make a lot of sense. In the embedded world, stripping your Java code down is one of the first things you do. And I say this as a previous winner of the Java 4K Coding Contest.
gotta... ...ugh... ...carry... ...all... *pant* ...that... *wheeze* ... run time type information ...around. Whew!
:-)
;-)
And yet, Java programs tend to compile to smaller files than native code, and also take a far shorter period of time. Even on the largest projects, I can compile Java code inside of ten minutes. It can take days to compile a C program of comperable size. And once it's in bytecode, it's only a short hop for the JVM to compile it to native code. Works pretty darn well.
Still, the whole idea of using RTTI to defer what should be a compile-time decision to run-time just leaves a bad taste in my mouth.
Not sure what you mean by this. Pretty much all code with direct references are properly checked at compile time. Obviously the run-time has to be a bit smarter when you dynamically load things via reflection, but that's very much a feature, not a bug.
Besides, you gotta love the ability to build a self-organizing program scheme in 20-30 lines of Java code. Doing the same thing in C++ is a PITA, and would only serve to confuse the heck out of the developer debugging the app and the OS trying to run it. I can just see it now, "Program X has 3,102 DLLs loaded."
If it's doing that much work in the software, and can't be reasonably done on the GPU, they should just put a damn CPU on the graphic card.
To what end? You've got a perfectly good CPU sitting inside your computer, and it's generally not doing anything anyway. Plus you've got memory galore for all those complex transformations. Why stick yet another computer onto the VidCard?
You forgot reflection. Reflection is the key to the awesome serialization, and is useful for all kinds of cool and interesting stuff. :-)
AJAX is a bridge thin-client technology that doesn't go as far as to shunt an entire desktop across the network, yet is robust enough to support nearly any application. All the real logic is usually done on the server using a real language. (No matter how much I grow fond of JavaScript, I will never think of it as a "real" language.)
As a thin client platform it works pretty well. As a general purpose coding platform it sucks. You still need to have a portable language on the server or you won't be able to move your code from system to system. (Though you will have the client nailed.)
mix that with the fact that java doesn't run well for most things that people try and use it for..
:-)
Most people seem to be doing server side development with it. Works fine.
i am sorry but without inter proccess comunication it is usless to me.
You mean like TCP/IP, CORBA, RMI, SOAP, XML-RPC, etc.? You need to be more specific if you're going to complain. BTW, there are libraries for SMB Remote IPC and POSIX IPC, but using either of them won't result in very portable code under ANY language.
Which raises the question, what exactly are you doing that you need native IPC?
If you write C# or Java, there is a middle man in there. The OS has to load this whole runtime environment, which takes up a big memory footprint and system resources, and then interprets your code, and then based on that tells the processor what to do.
;-) (I'm only half joking, too. Java is basically an OS platform. Moving it down isn't that big of a step.)
That's precisely why the Java Runtime should be the OS.
BTW, Java might be interpreted, or it may be JITted, it may be run in a mix of the two, or it may be outright pre-compiled. Depends on the runtime.
And I'd just like to say that the mods are a bunch of pricks for modding 955301 down. Remember the modding guidelines? Mod UP, not down. If you don't like it, leave it alone.
For instance, there is no Java JVM for a Palm.
There isn't? What will I do?
Dude. Java is everywhere. It's in tiny little cards and in the latest ARM processors. You can't run. You can't hide. Java will find your OS, and you will be assimilated. Submit to the collective!
They've been changing with greater frequency as the years go by. The rise of digital wireless technology has had the FCC scrambling to reorganize the bands. Examples of this include the Digital TV bands, Family Bands, and Internet over Powerlines. They're also considering new technologies such as Ultra Wide Band to ensure that such tech doesn't interfere with existing bands.
2/3. You are arguing for a flexibility in the cards that is unneeded/unused. Vendors still want to release new cards to follow changing technology.
Only for major changes. Minor changes to improve the performance of existing hardware usually results in new drivers.
Speaking of which, where were your simple firmware updates when WPA came out, and now WPA2?
Firmware would be the problem. A new encryption standard on the card would require new hardware for decryption. Handled in the software (not firmware), the card could be updated with the feature. I can't speak to your particular card, but it's probably because you chose a card with self-contained firmware that you had to purchase a new card. Sorry. Get a software controlled one next time.
Despite the advantages of having a software driven card, vendors still sell hardware.
Yes they do. And if they can get away with not having to design a brand new piece of hardware, they will. Hardware development costs are tremendous and are generally avoided whenever possible. Which means that many hardware manufacturers strive to design their hardware with software controls so that they can repackage/rebrand with a few software changes on the same hardware. Most of these manufacturers will then release the driver updates for Windows. Using Linux? Too bad, you're using something someone else wrote.
Any code to modulate and regulate the transmitter is fairly constant and doesn't need to be in software.
Are you a HAM operator? How do you know this with any certainty? Most radio equipment has a reasonably large frequncy band available. From the Wikipedia article on IEEE 802.11, section 802.11b:
In theory, it could be a single port that the driver crams all requests and data into and the GPU does whatever it wants and hands any return data back on a second port, although there are obvious thoroughput problems there.
Oh Lord. Save me from the ignorant. Hardware systems are NOT that easy to design. The GPU doesn't do JACK other than crunch some numbers, and it's already one of the most complicated devices in existence! (Primarily thanks to the complex pipeline designs, the number of parallel pipelines, and the microcode space and execution hardware carried on chip and intertwined with each pipeline.) ALL the real work is in the software. The hardware just executes its instructions. If you tried to cram all the work the software is doing into the hardware, you'd have something more complex than the latest Pentium and NVidia GPU combined. Not to mention that you'd never be able to increase performance through driver updates.
And you need to be careful with your concepts of Ports. Bus design is tricky business and can easily bottle up the entire computing platform if you're not careful. Many commands on one bus is something you see more of in general purpose computing where the raw performance isn't an issue. In the case of a GPU, raw performance IS an issue, and the software directly controls the entire bus + the GPU.
What the hell are you talking about? I wasn't complaining about GPUs or CPUs.
That's because you have no idea what you're talking about. The hardware doesn't do video processing. I don't know how many times I'm going to have to repeat that. It's all software, and it's all trying to compile the instructions, reorder them, JIT microcode, parallelize the data, and do other complex optimizations that will actually feed the computations into the GPU. The GPU spits out an answer that ends up in VRAM. How nice.
And, before you ask, I do indeed program, although admittedly it's been a decade since any assembly language.
No offense, but ASM is way off in left field. We're talking hardware design here. And the only way to truly understand hardware (including the software that drives it and WHY it drives it that way) is to go design some yourself. Unlike yourself, I've actually taken the time to do so, and now understand why things are the way they are. I'm not sure how I can get this through your skull, but complex hardware is HARD and EXPENSIVE. It never makes sense to use hardware when software will do the job just as effectively (or in this case, more so).
When it does make sense is when you're trying to accelerate very specific and abstract mathematical operations. e.g. Matrix math can be easily accelerated in hardware. Drawing a line on the screen? Not so much. If you want to accelerate something like drawing a line, you'll want to use Microcode. Microcode is tiny software that loads up and executes on the CPU itself. Microcode is pretty micro though, so it can only go so far. To do something more complex, (say, draw a shape with those lines) you want to bump it up to software. The on-chip cache will keep the code running smoothly inside the chip so that the software isn't constantly crossing the bus during the operations. Thus you end up with software that drives the hardware.
Now imagine that you had software that waited until you had drawn all the objects with lines, then sorted them to figure out which ones get drawn in what order, removes any lines that are hidden, checks which lines can be drawn in parallel because they don't cross, then does a final reordering of the line drawing commands so that the hardware can draw four lines simultanousously (complicated by the fact that some lines are shorter than others, and will take fewer cycles to complete). That is what your big blob of "useless" software is doing.
If you think there's a better way this stuff can work, then by all means. Go design some hardware and show the world. (It's not that hard to get started. Really.) In the meantime, though, just be quiet. You're making yourself look bad.
Indeed. However, I was referring to the use of small batteries in devices that never die, which is something that we don't have today. All the current RTGs/SRGs are big monsters that act as a small power plant for a craft or scientific equipment. Russia used to use the things to power Lighthouses indefinitely.
:-)
So far no one has actually brought a miniturized version to market, though.
All we need are some RTGs.
Precisely. Though I'm still holding out for SRGs and other more efficient heat engines.
What do you mean I'll get cancer?
What d'ya mean, what d'ya mean? You could shield Alpha radiation with a sheet of paper, and Beta radiation with a bit of foil. You'd get more radiation exposure from the Earth's crust than you would a hundred Plutonium-powered cell phones.
true mobility. Connected and powered 24/7, anywhere.
Would be nice wouldn't it? Unfortunatly, there are exactly three devices that can make this happen:
1) A portable solar generator and battery. This only works as long as the generator is able to produce more than ample power to cover periods where sunlight is unavailable and the panels are always facing the sun. e.g. The roof of a car. Plus you still have to charge devices in it.
2) Beaming power to devices. This is actually related to solar power as it reqires that a laser or maser hold a targetting lock on your device's power converter. Besides how tricky this is to implement, it's also dangerous to be broadcasting a number of lased transmissions in the multi-watt range.
3) Harnessing the radiation from radioisotopes. This is the most promising option as there are several types of radioisotope that are easy to contain, and no more dangerous than today's battery chemicals. This option could easily provide power in the 1-50 watt range, 24x7 for 10-30 years. The drawbacks to this method are a) radioisotopes are too expensive, b) the public has an irrational fear of anything "nukular", and c) the radioisotopes must be treated as hazardous waste (just like batteries) and disposed of properly.
I fully expect that option 3 will be embraced by future space explorers. It just wouldn't do to have equipment that can't survive long spans of time away from a charging station.
Ummm...we were talking about wireless cards.
So?
In the case of the wifi cards, though, the transmitter power is set in software. There is absolutely no reason for this because the transmission strength is heavily regulated by the FCC.
1. FCC regulations change.
2. Radio transmissions are tricky things. A Wifi producer might release a patch that provides greater range by constantly modulating the power levels, yet remaining within the FCC's guidelines.
3. It's about a lot more than power. You can accidently generate a massive amount of broadband radio noise if you're not careful. Basically, the software is playing HAM operator with the Wifi card in order to tune the best performance out of it without running afoul of regulations. That's a good use for software.
I said they licensed an OpenGl implementation from somebody that won't let them open the code (or so they say).
You're
not
listening
The OpenGL implementation is seconday. Forget about it. We're talking about REAL technology that buffers, tweaks, and translates 3D requesting into highly sophisticated instructions that feeds to the GPU, manage VRAM, and generally control the entire 3D video bus. All that has JACK to do with OpenGL. OpenGL is just an API. It's unimportant. The real code is the stuff going on under the hood that tells the GPU "this is how you Antialias" or "this is how you rotate the textures" or "I've automatically prepped this bit of microcode to make this routine faster". The end result from the *drivers* is little more than a bunch of complex math instructions and VRAM updates. The GPU doesn't even know or care that it's calculating 3D pictures. It's just doing what the drivers tell it to do.
When you consider that the translation from 3D down to sets on complex math instructions happen only in software, it should become clear that NVidia and ATI didn't develop all that technology by themselves. There's simply too much complexity there. Thus they licensed NOT OpenGL, but all kinds of bits and pieces of 3D trickery, microcode, and hardware design thats patented by someone else, produced by someone else, and only made use of by NVidia and ATI in as quick of a fashion as possible so they can beat each other to market.
If you still think it's about the OpenGL implementation, you need to exit the computer market because you have not a clue what you're talking about.
A lot of hardware in linux gets supported by someone reverse-engineering the damn chip because they can't get the specs, and the driver ends up working as good as or better than anything that gets released by the vendor, if that ever happens.
That's why there are full drivers for NVidia, right? No wait, there aren't.
That's why there are full drivers for WinModems, right? No wait, there aren't.
That's why there are full drivers for WiFi cards, right? No wait, there aren't.
Hell, it took 5 years to get USB right, and it still has problems. I'm not sure what you're so impressed by.
The OSS drivers are workable, but in most cases they only exist for reasonably simple devices (or standardized devices), and they don't support the full feature set of those devices. Sometimes the only way they get the job done is because the card exposes the underlying chipset which they can find manufacturer documentation for. There's no magic here, I'm afraid.
I don't need luck, my Gamecube work fine.
Oh, well then. I'm sure that's very Free(TM) and Open(TM). I'm also sure that any 3D designs you need to do will be very easy to do on your GameCube. Good luck on that.
Linux is software made for companies
Pretty much every company I've been in would prefer driver support from the hardware vendor because "they know their hardware better than anyone else." In fact, the *only* ones I see who don't want a standard driver ABI are the Linux OSS people who don't want it for philosophical reasons. Which would be fine if they weren't trying to force the hand of every hardware company in existence, but they are.
You know what I think? I think you should actually TRY designing a CPU. You may not find things to be as cut and dry as you think. Here's some great tools to get you started. Hope you have a good grasp on the parallelism of circuit design, and understand microcode, instruction decoders, on-chip cache, and pipelining. When you're ready to put your masterpiece in fabric, go grab an FPGA and check to see if you made efficient enough use of silicon to make it fit.
When you're done, show us your design and we'll show you how the existing stuff has been done better.
Analog VGA? As opposed to what?
Analog NTSC, PAL, SECAM, EGA, UGA, etc.
Digital DVI, MPEG, etc.
Their 'serious advantage' is THE major cause of their operating system's most notable problem, aka blue screens.
That sounds like a fucking stupid 'advantage' to me.
Linux's 'serious advantage' is THE major reason why I couldn't have USB until 5 years after the spec was released.
That sounds like a fucking stupid 'advantage' to me.
Damn thing still never works right. (It was working correctly in BSD in '98! What the hell is the problem?)
In the worse case, it might be due to someone emailing patches to you and telling you to try them out, because no one has exactly the problem, but by gum they'll fix it.
You mean like the USB Intelli-mouse problem that I was having that had hundreds to thousands of reports on the kernel mailing lists but wasn't ever fixed? The only fix was that Microsoft changed their hardware to a new model.
That sounds like a fucking stupid 'advantage' to me.
When it blue screens in XP? Well, I dunno, because the damn company that made the cable went out of business before XP and their driver from 2000 doesn't work.
As opposed to the unmaintained drivers in the Linux kernel that no longer work, in part because no one has the cable any longer because the company went out of business. Good plan there, chief.
This is because producing drivers is not their business, whereas it is the 'business' of Linux kernel developers.
Let's stop the wanking and be serious here for a moment. The only business of the Linux developers is to scratch the itch they feel like scratching. They'll sometimes go out of their way for users, but if they don't think highly of you or your bug report than you can expect it to get buried. That's what happens when the users aren't actually customers.
This is due to bad hardware design.
BZZZT! This is due to GOOD hardware design. By moving many of the controls to the software logic, the chips can be made simpler and more flexible. New features can be added by simply upgrading the software rather than requiring the consumer to purchase a new card.
A perfect example of this is a video capture card I used to have. The signal lock was handled in software. Unfortunately, the initial release couldn't lock onto some of the more esoteric timings. (TV signals come in a few slightly different timing depending on if it's broadcast, RCA, or an RF feed.) Had they hardcoded these timings in the hardware, they couldn't have released a new version that supported everyone's video cameras.
I'm sure you'll argue that they should have got it right the first time, but consider this: How many times have you "gotten it right" when you followed the spec to a 'T', only to find that there were slight variations on the spec by different implementations?
If you are referring to NVidia's licensed OpenGL implementation, the solution is to use an open source implementation, such as Mesa.
You really have no idea how these cards work, do you? The GPU isn't a magic implementation of a 3D processor that you can just plug APIs into. It's a high-performance, multi-pipelined, single-instruction/many-data, vector processor! It relies exclusively on the drivers to correctly feed it the data in such a way as to keep all the pipelines at maximum saturation, and all features of the chip at maximum utilization. Every release of the drivers that come out are nothing more than more optimizations to help common games make the best use of the silicon. If you think it's JUST an OpenGL implementation, you need to do your homework!
Nevermind the fact that a lot of hardware vendors don't actually support NDIS to begin with.
They would if it was better supported.
You know those wireless drivers that came with your card that you had to load separately in Windows, and they have their own little control panel? Not NDIS.
Okay, let's be honest here. Do you *really* need the little control panels? Even if we do, let's consider for a moment that the cross-platform ABIs/APIs could be updated to support such features. The only reason why it hasn't is that no one uses NDIS or UDI. They have got to be some of the most useful yet ignored technologies in the history of computing! Yet everyone is so happy because X-Windows has a platform independent API for drivers built in, when those drivers should be OS drivers.
Seriously, vendors can offload a lot of work and we can get higher quality drivers (on all platforms) if they would just release the specs.
Most of the ones who can, either have or are simply not that great of vendors. You and many others severely underestimate the problems inherent in releasing them.
Vendors are refusing to release specs because drivers have always been proprietary.
Yeah, whatever. Speaking as someone who was programming computers since before anyone had even heard the word "driver", I can say with confidence that the only reason for the current situation is that Microsoft pushed the responsibility of creating drivers for Windows onto the manufacturers. Prior to that you had to develop your own damn hardware interfaces. We were absolutely shocked when Creative gave the world a loadable API module for controlling their sound card. That was simply unheard of!
I'm sure you'll go off into a rant about how Microsoft was just being Microsoft, But you know what? Microsoft was right on this one. Supporting that much hardware is crazy for one. For another, hardware today is simply too complex for everyone to be developing their own drivers. Considering that some hardware is on the level of the most sophisticated interaction between software and hardware ever developed, I'd say that we should be counting ourselves lucky we have the drivers at all.
Of course that means I'd need to LEARN JMF, which for what I'm doing might not be a bad thing, but still, it's another library that I don't know yet.
:-)
:-)
Can't help you there. It's been forever since I last used the bugger.
And as I put in my original reply above, the bitwise-AND is what I was already doing
Oh, sorry. I missed that part. Well, hope some of what I said was useful, anyway.
Thanks for your help man.
Wish I could do more, but it sounds like you've generally got a good grasp on things. I'm not precisely sure what you're doing (PAL capture?), but the bitwise and should serve you well for most everything you'd need to do. If you really need the performance, then the SIMD route might be worth exploring.
Then we in the Linux community just won't buy their stuff
Good luck on those video games, then.
or find ways to force it to work when we do (ndiswrapper or reverse engineering).
I really should be snickering like an idiot at this. Really. Read the first four letters of the driver name you just gave. Now think long and hard about how much trouble could have been saved if Linux had just supported binary NDIS drivers in the first place.
YUV! Gotta love that stuff. (Not.) Perfect for reducing bandwidth with only minor information loss, though.
I can see why you're looking for bitwise manipulation.
As long as you're not looking for real-time performance, all you need to do is try this little trick:You should get 236 instead of -20. This works because the JVM implicitly casts the byte to an int by padding it to four bytes before performing the operation.
Your mention SIMD instructions intrigue me though. What can be done in Java on that front?
Me and my big mouth. Ok, here goes. This whole thing is a bit on the undocumented side, so you'll have to hang with me here. Basically the ByteBuffers give you a raw memory block on both the native and Java side. Now Java can't execute SIMD directly (though they are working on adding such a thing to the Math package in the future), but it can define and control such streams. So what you want is to create an SPI plugin that creates a channel that does what you want. In your channel code, you need an input buffer and an output buffer. (Or at least, I assume. You can operate on the same data if you want, but I assume you're converting to the much larger RGB format.) You can then select the processor in your code. You'll probably want a pure Java version that uses the trick above to perform the conversion to fall back on. But for systems where you have native drivers, you can use JNI to write a small bit of C/C++/Assembler to execute a bit of SIMD on the two byte buffers.
Basically, you want to tell the SIMD instructions (be they SSE, Altivec, or Sparc SIMD) to operate on the memory block at the byte buffer location, and put the results of the operations at the second byte buffer memory location. You would then have a super-fast YUV -> RGB channel with only a minor amount of optional accelerator code.
Now, with that out of the way, can I ask a question? Is there any chance that the ImageIO package or JMF already does what you need? (JMF has a bunch of fast YUV stuff built-in.)