THe idea of clockless sections on a clocked chip has relatively little benefits over a completely clocked chip. Since the result of the onclocked operation needs to be picked up by a (globally) synchronoized part later, that part will either use - (worst case) the unclocked part's worst-case timing, or - (best case) throw away some possible intra-clock-cycle benefit. Therefor only benefit will be frequency spread and the module not being dependent on freq. skew.
For "clockless" to thrive, the complete chip should be clockless.
First, as others have already commented, a gcc backend is already available and Linux runs on Cell.
Second, optimizing compilers tend to optimize only small parts of linear code. Simply put, this comes down to filtering binaries and replacing inefficient code sequences by more efficient ones. Depending on the quality of the compilercore, this typically gains a few percent, occasionally some 25% but that's nowhere near what Cell could offer, namely (theoretically) 800%. The problem is refactoring the problem to run in - small chunks, - independently (parallel) - and on a specialized processor. A compiler can help only modestly with the last point. In any non-trivial case, this means reanalyzing the problem and reimplementing the solution from the start, making different tradeoffs. That is why people say Cell is difficult.
IMHO, the benefits of code optimization will be close to irrelevant for almost any successful application on Cell over the coming years. And while Moore's law has provided us with bigger and faster hardware, we programmers are still mostly empty-handed when it comes to program translation for parallel architectures.
We need a paradigm shift, not an optimizing compiler.
Hmm. My comment was actually intended as a joke. But seriously, if trusted computing ever takes off, in that it completely and ultimately limits users from peeking inside software (which I personally doubt) even malicious software will be below the radar. That's like a rootkit that a user cannot technically (or legally) detect, modify, remove, etc.
Now your question basically translates as: will anti-virus companies behave as "user", or will they force, reverse-engineer or bypass TC layers in the OS?
...crackers' IP cannot be properly protected by law (DMCA) and patents. The *only* way to protect virusses, spyware and other malware effectively from these kind of companies is through trusted computing, people. Go figure!
>There is a way round the problem, but it puts you at risk from the DMCA as (by definition) it is circumventing security technology. By having a hypervisor-like OS running at the lowest level, and then having Vista run on top of that, you can make any piece of physical hardware look like any other piece of hardware that you like. Nothing Vista can do about it, as it can't see the hardware directly, all it can see is the results of pushing data of one type in one direction, then pulling data of another type in the opposite direction.
Unfortunately, even that won't work once trusted computing takes over. Trusted hardware protects trusted firmware which in turn protects a trusted OS. IMHO, that's what MS is gambling at.
True. It won't be the average users that will persuade Microsoft to drop this approach (or suffer), and it won't be us nerds either. It will be hardware vendors and potential customers in emerging markets, like China.
Initially this won't actually hurt MS since buying their software isn't the fashion there anyway. But increasingly, high-end hardware vendors like ATI and nVidia will provide drivers for (more or less) open systems like Linux, BSD and Solaris or help others to do so - MS no longer has the control to leverage their platform.
Meanwhile, some small low-end ("brandless") vendors will provide only unsigned drivers as their hardware doesn't end up in your typical Dell, Compaq, Packard-Bell, Toshiba,... anyway. Eventually, this low end Asian (or even African) market is going to take over what we currently consider mainstream, at least in volume. What little chance there ever was for MS to be on the majority of those systems is certainly nilled by discussed initiative.
I think Microsoft is seeing the threat. That's why they tentatively try pushing only the 64b systems. That's where it's most likely (or least unlikely) to succee. If it does, they may move to 32b (if that still exists by the time Vista is released) and if it doesn't (cos the 64b loot is already taken by Sun, Apple, RedHat - whoever) the'll certainly reconsider.
By the way - this doesn't mean typical hardware geeks won't suffer. As with all of MS' "plans" it could be over next week or it may be a long bloody battle.
I can't prove this unless you want to come over and look at my bookshelf;-) Seriously. It's very hard to find a good book on xhtml and css. I've found it even harder to find one that discusses it from a design perspective. "Desiging with Web Standards" was tempting enough for me to order - I just don't advise anyone to do so. I was just stupid enough to ignore remarks like these:
and some not-so-positive hints by/. readers. Indeed, his style is wordy and he frequently fails to get down to the technicals because he's too busy showing off, explaining why writing this book is so important. The first 100 pages are all about legacy sites and whats wrong with them.
He then continues basically allong the lines of porting your tables based sites to xhtml+css. This may be revealing to some frontpage users, it may even help adapting these standards, but it really has nothing to do with design.
There are many views on design, but from what I learned, this is called redesign, in a bottom up fashion, whereas design is generally top down. He might have called the book "porting to web standard - and why you should consider it". And, at that, he does a poor job - IMHO.
Now, if you want to be stuborn, go buy that book and tell me that it was worth your money. Make the same mistake I did - please.
I remember reading about a similar attempt using EPROMs in late '80s. In a normal recycling procedure, these were erased by shining a high intensity UV light for a couple of minutes through the glass window that's present in the IC shielding. After making sure all bits are reset, the window is covered by a sticker or label. Then the data is 'burned' and the (typically 256Kb/32KB) ROM was inserted into your BBC micro (insert favorite hobby computer).
Similar to the process you describe, an image could be gathered by setting all bits to 1 (or actually 0, as EPROMs have negative logic), then waiting for bits to flip. I don't think a lense was used, just a diafragm (dot in piece of black paper). On average, an exposure took 1-4 hours (and resulted in a very poor quality black/white image for current standards) if the scene was bright enough. Lighting the scene with a UV helped a bit, though visible light worked surprisingly well.
Of course, the whole whing was hardly useful, but remember that - at the time - the average micro had little more periferals than a keyboard, joystick. Mac had a mouse and some MSX systems had support for an analog "gen-locked" camera, BBC had some support for light pens. There may have been handscanners for PC/ATs. So mostly any hardware that would allow translation from analog to digital was greedily welcomed.
Jeffrey Zeldman
on
Web 3.0
·
· Score: 1, Informative
Jeffrey Zeldman is the author of Designing with Web Standards (and who was somehow never adequately punished for writing that book; please look inside to see what I mean).
I recently made the mistake of buying that book a while ago, as it seemed to present information on... well... designing with web standards, you know, xhtml & css. Instead, I found it's a 400+ page rant on oldfashioned non-standard design. There's no information at all about design and hardly anything helpful on web standards.
So, though Jeffrey himself may think differently, IMHO it's silly to regard him as a authority on anything web related.
This proves that - apparently - scientists have finally been able to *exactly* reproduce previous empirical results. Just imagine: not only is the impact exactly the same and on the same spot; on top of that the same musings appear on/. !
"The Collaborative International Dictionary of English v.0.48" Gimp Gimp, a. W. gwymp fair, neat, comely.
Smart; spruce; trim; nice. Obs. or Prov. Eng.
1913 Webster
...Not to bad... OK. I'll admit that gimp sounds like wimp, which closely resembles GIMPs logo. Nevertheless, GIMP is called GIMP because it is an image manipulation program that happened to be blessed by the GNU brand - its called what it is.
This seems more apt than your Firefox example. Firefox is a great brand, but it's far from obvious that "fire", "fox" or "firefox" have anything to do with browsing web pages. Neither are Netscape or Mozilla. Firefox is a great brand because it stands for a popular product, not the other way around. Same for "Linux", "Apache", "PHP", "Safari", ".net", or "XP".
So I can't see why GIMP would gain popularity by changing its name to GNU Photoshop or Kingkong (legal issues aside). A linspire/ubuntu/mandrake-newby will find GIMP under Start=>Applications=>Graphics (or similar) which is pretty intuitive to a Windows user.
I think blaming GIMPs lack of popularity with the general public on its name is very simplistic. I'm tempted to say that Photoshop is simply a better product - which is debatable - but its obvious that issues like marketing budget and commercial plugin support from third parties are important factors.
Yes - browsing for not-so-obvious applications in Freshmeat give me headaches as well. But it's not just the name, it's the varrying formats and quality of meta information about this software, and most importantly: a universal way to asses a component's quality, applicability for a certain task.
GNU Image Manipulation Program (because that's basically what it is)
You're (probably) refering to this story. IMHO GIMP is a great name, or at least as good as Ps would be for Phostoshop. A more justified criticism would be directed against the GIMPs somewhat unintuitive GUI. Then, there are historical reasons to not do that...
But, as others have pointed out, with GIMP you have a choice: GIMPShop (which is still somewhat immature). For lazy readers:
GIMPShop is a free Open Source image editor that is similar to the popular Adobe Photoshop. Specifically GIMPShop is a version of the GIMP that has been edited to be more user-friendly for Photoshop users.
[...]
GIMPShop was orginally developed for Mac OS X, but has been ported to Windows, Linux, and Solaris.
I Agree. I think you could draw an anology between current predictions on nanotech and predictions about nuclear applications in the 1930s or space travel in 1950s. Nanotech is promising, but it is impossible to tell what we'll see in 15 years.
In 1955, people standing on the moon in spacesuits within 15 years seemed just as likely/unlikely as having a collony on Mars, battling the Russians from earh orbiting satelites or launching spacecrafts with an atomic motor. Who would have thought we'd mostly loose interest in manned space flight shortly after pissing on the Moon?
Here's a dark vision on the future of nanotech, biotech or whatever hyped techs we've currently: First applications for may revolutionary technologies are in WARFARE. Carbon-nitrogen chemistry didn't solve starvation through fertilizers, but gave wealth to Alfred Nobel selling dynamite. Nuclear plants only followed after the atomic bomb's "succes". Computers have roots in WWII. Arguably, the ubiquitous communications and sharing of knowledged provided by the internet, cell phones and physical transport vehicles have enabled (some of) the terrorism we see currently. And though an all-out worldwide cyberwar is unlikely, internet has (yet again) not closed the gap between rich and poor, wealth and hunger, world peace, whatever - I digres.
It is not hard to imagine military applications for nanotech. A dirty bomb filled with nanofibers with asbestus-like properties should be just around the corner. And IMHO a bunch of undetectibly small spy bots is more foreseeable than a trillion gates on a chip.
Of course, you are correct in your statement that this doesn't affect the turing completeness of your computer. Thus there is no effect on the types of programs the computer can execute, only how quickly they compute them, how much power is consumed, and how big the machine is that does the computing.
For modern computers, a more relevant abstraction of computational power would be a random-access machine, since it models not just what kind of problems can be solved, but also (more realistically) in how much time that solution is found.
At a practical level, current chips are limited by the distance (lenght of wires) between interacting gates. In normal, planar designs, this distance can be reduced by regrouping interacting gates as close to each other as possible (ie.: making designs more clever), reducing the total number of gates or reducing the gate size (thus reducing the total chip size). Adding a second layer could half the needed die surface, allowing for smaller propagation times, thus higher clock frequency/more complexity/surface.
However, adding more layers has a lot of practical problems in the current production process. Therefore *any* successful alternative to produce 3D semi conductors is likely to boost processing power.
OK. Some good questions, but also some you really shouldn't ask, IMHO. Stuff like: What is the philosophy of the company? shows you didn't bother to study their marketing material. Similarly, you shouldn't ask How financially sound is this company? just like that. Better do some research and ask more targetted questions on that topic.
What is this company's culture? (Ex: Is it rigid and formal or relaxed and flexible?) What insight would that give you? What company is going to admid that they are either flexible in the sense that they regularly lay off 80% of employees or rigid in the sense that some processes completely lock up in a bureaucracy? Anyone at this point trying to sell his company will suggest they are both "professional" and have an "informal, pleasant" atmosphere.
Questions like Whom will I supervise? What projects and assignments will I be working on? and With whom will I be working most closely? should have been answered in the natural flow of conversation. If not, I'd definitely ask them, yes.
What do you consider to be the company's strengths and weaknesses? is brilliant. Even better have a taylored version of that, more relevant to that specific job. Be sure to suggest why you're qualified to help fix weaknesses. Same for What are the most challenging aspects of the position?
You can use C++ if you don't use multiple inheritance.
Worse: you can use C++ if you feel like doing C# without any of its merrits.
Some time ago I looked at porting a solid Windows based 100.000 lines of code C++ GUI application to managed C++. If was a mature and stable application developed over 15 years.
The idea was to used managed functionality for UI and maintain unmanaged code for the older parts. While there is some "support" for using both managed and unmanaged code, it became clear very soon that doing so leads to huge problems. All advice basically points you either to one or the other, mostly favouring managed code (its *NEW*, after all).
In doing so we ran into a lot of low level problems more than multiple class-inheritance (which IMHO is a stupid concept in C++ anyway). We finally ended up with loads of messy code that in a hardly supported IDE (I guess Visual Studio abandoned C++ almost entirely some bugs in VC6 are still not fixed). Also performance halfed in some of the low level functions, requiring complete redesign.
The short story. After a month we abandoned Microsoft's "seamless" CLR migration path in favor for good old-fashioned Java+CORBA for the UI and kept the C++ core mostly intact.
We could have used C#+CORBA as well, but I guess the morale is that the CLR as a multi-language vehicle is just a laugh - at least in case of C++.
>Flash = SVG + sound + ECMAScript. That's what I'm talking about. So if you think that has hickups on 5GHz, it'll have that on 350MHz.
Right. But does that tell you something about the adequacy of certain CPU or does that tell you something about Flash? And why do you need flash on an appliance again?
OK. My point is that in terms of usability, we havent come nearly as far from the old Newton days to justify the hefty hardware requirements of modern appliances. Chips get more powerful more or less according to Moore's law and software takes advantage, mostly by wasting clock cycles on eye candy. I like alpha blending, and full lenght DVD movies, but I'd much rather have a portable that's useful for more than a couple of hours. If it means a photo album slide show can only show 20 jpegs per second, that's fine with me;-)
WRT to embedded it is *very* important to notice that batteries do not "grow" according to Moore's law. That's why we shouldn't expect mobile to look anything like desktop software in the first place.
Sure there's some truth in a higher number of bits that need to be moved on high-res color devices. But bitshifting is only a portion of GUI incurred CPU load. Don't have any number, but I suppose a significant portion is in clipping logic, or simply message passing, heap allocation, event handing and context switching. I mean, theoretically at 32bits moving 800x600x16 bits takes less than a microsecond so something other than bitshifting must be going on. Like, shifting the wrong bits in the first place - for example - due to inefficient programming.
For example. Scrolling in firefox is noticible on my 90MHz pentium. Sure, it may tak up to a full second. But it's noticible on my 3GHz Athlon as well. (Must be somewhere around one or two deciseconds). I use both with standard non-accelerated VGA at 1280x1024x32bpp. So, with a "bitshifter" that's supposed to be roughly 33 times faster a speedupfactor of only 10 is a bit disappointing, don't you think? (More so if you would take fsb bandwidth into account).
On the xyz developer thing. In a sense, you're right: embedded programming is just like programming C64, Amiga, Win32. The main difference is that here, size and bloat matters. Small screen, no keyboard and slow hardware requires tradoffs. In Wince, Microsoft makes most of these tradeoffs for you, but not necessarily the way you would make them yourself.
As you may have read in other posts, some stuff that you've come to think of as essential is simply not there. So a lot of time you find yourself recoding basic functions from scratch. Also, it doesn't give you the tools to scim and trim your binaries to the bare minimum, which is a major problem in the embedded area.
I thought mice - being pan dimensional beings - were far more advanced than humans (ranked 3, just after dolphins). This is like modding an xbox 360/ps3/whatever with a Z80 - why whould you want to do that?
SVG: help is underway. Xara has a very fast anti-aliased vector rendering engine that has origins in Artworks, an unknown but blazingly fast vectorgraphics designer launched in 1991 for 12MHz ARM2 based archimedes A440. But I'd have to admit that 20 frames per second is pushing it on a 90MHz pentium. Should just be possible with a 250MHz ARM, though;-).
On mp3's, mind that this specific appliance features TI's OMAP arch which I believe includes a DSP that should take the major workload off the CPU; unlike my 90MHz pentium system. Could help on some video tasks as well, I suppose.
Flash. Well, if probably will have some hickups once intel finally hits the 5GHz. That both due to macromedia beefing up the platform in sync or faster than Moore's law can provide for and partly due to incompetent programmers. Its a nice gadget for games, animations and simple interfaces, but I suppose Flash was never intended for any kind of real-time performance.
...But your math doesn't work, most of the time. The ratio you refer to applies to video out and is mostly unrelated to the CPU. Except for streaming video, which really is a silly application on a lightweight tablet. There, wifi bandwidth is more likely to be a bottleneck than the CPU. Anyway, the newton *was* able to reproduce audio in the formats considered "standard" at the time. I don't see why contemporary (compressed) formats would be a problem, as they take less than 30% CPU time on my 10 year old 90MHz Pentium box. And images. What exactly is it that you want to do with them that requires over 250MHz ARM power?
As for browsers, I have to agree that these have evolved to very complex pieces of software. Though I won't debate that firefox, opera, safari and IE all carry a certain portion of bloat, I don't see small embedded browsers with full support any time soon.
As for Windows, you gottabe joking. You're not a WinCE developer, are you?
Really people, there is an easy way out if you don't like the idea of the DoD getting a utility out of this dish in exchanger for millions of tax payer dollars: Raise the money yourself.
Is the DoD suddenly a profitable organization, kind enough to sahre some of these profits with science projects? Last time I checked the money was raised by "ourselves" through taxes and borrowing from future generations.
All products seem to support Linux on ARM/XScale and (at least) some in combination with a DSP. Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?
Slashdot Mirror
THe idea of clockless sections on a clocked chip has relatively little benefits over a completely clocked chip. Since the result of the onclocked operation needs to be picked up by a (globally) synchronoized part later, that part will either use
- (worst case) the unclocked part's worst-case timing, or
- (best case) throw away some possible intra-clock-cycle benefit.
Therefor only benefit will be frequency spread and the module not being dependent on freq. skew.
For "clockless" to thrive, the complete chip should be clockless.
First, as others have already commented, a gcc backend is already available and Linux runs on Cell.
Second, optimizing compilers tend to optimize only small parts of linear code. Simply put, this comes down to filtering binaries and replacing inefficient code sequences by more efficient ones. Depending on the quality of the compilercore, this typically gains a few percent, occasionally some 25% but that's nowhere near what Cell could offer, namely (theoretically) 800%.
The problem is refactoring the problem to run in
- small chunks,
- independently (parallel)
- and on a specialized processor.
A compiler can help only modestly with the last point. In any non-trivial case, this means reanalyzing the problem and reimplementing the solution from the start, making different tradeoffs. That is why people say Cell is difficult.
IMHO, the benefits of code optimization will be close to irrelevant for almost any successful application on Cell over the coming years. And while Moore's law has provided us with bigger and faster hardware, we programmers are still mostly empty-handed when it comes to program translation for parallel architectures.
We need a paradigm shift, not an optimizing compiler.
Hmm. My comment was actually intended as a joke.
But seriously, if trusted computing ever takes off, in that it completely and ultimately limits users from peeking inside software (which I personally doubt) even malicious software will be below the radar. That's like a rootkit that a user cannot technically (or legally) detect, modify, remove, etc.
Now your question basically translates as: will anti-virus companies behave as "user", or will they force, reverse-engineer or bypass TC layers in the OS?
...crackers' IP cannot be properly protected by law (DMCA) and patents.
The *only* way to protect virusses, spyware and other malware effectively from these kind of companies is through trusted computing, people. Go figure!
>There is a way round the problem, but it puts you at risk from the DMCA as (by definition) it is circumventing security technology. By having a hypervisor-like OS running at the lowest level, and then having Vista run on top of that, you can make any piece of physical hardware look like any other piece of hardware that you like. Nothing Vista can do about it, as it can't see the hardware directly, all it can see is the results of pushing data of one type in one direction, then pulling data of another type in the opposite direction.
Unfortunately, even that won't work once trusted computing takes over. Trusted hardware protects trusted firmware which in turn protects a trusted OS. IMHO, that's what MS is gambling at.
True. It won't be the average users that will persuade Microsoft to drop this approach (or suffer), and it won't be us nerds either. It will be hardware vendors and potential customers in emerging markets, like China.
... anyway. Eventually, this low end Asian (or even African) market is going to take over what we currently consider mainstream, at least in volume. What little chance there ever was for MS to be on the majority of those systems is certainly nilled by discussed initiative.
Initially this won't actually hurt MS since buying their software isn't the fashion there anyway. But increasingly, high-end hardware vendors like ATI and nVidia will provide drivers for (more or less) open systems like Linux, BSD and Solaris or help others to do so - MS no longer has the control to leverage their platform.
Meanwhile, some small low-end ("brandless") vendors will provide only unsigned drivers as their hardware doesn't end up in your typical Dell, Compaq, Packard-Bell, Toshiba,
I think Microsoft is seeing the threat. That's why they tentatively try pushing only the 64b systems. That's where it's most likely (or least unlikely) to succee. If it does, they may move to 32b (if that still exists by the time Vista is released) and if it doesn't (cos the 64b loot is already taken by Sun, Apple, RedHat - whoever) the'll certainly reconsider.
By the way - this doesn't mean typical hardware geeks won't suffer. As with all of MS' "plans" it could be over next week or it may be a long bloody battle.
I can't prove this unless you want to come over and look at my bookshelf
Seriously. It's very hard to find a good book on xhtml and css. I've found it even harder to find one that discusses it from a design perspective.
"Desiging with Web Standards" was tempting enough for me to order - I just don't advise anyone to do so. I was just stupid enough to ignore remarks like these:
and some not-so-positive hints by
He then continues basically allong the lines of porting your tables based sites to xhtml+css. This may be revealing to some frontpage users, it may even help adapting these standards, but it really has nothing to do with design.
There are many views on design, but from what I learned, this is called redesign, in a bottom up fashion, whereas design is generally top down. He might have called the book "porting to web standard - and why you should consider it". And, at that, he does a poor job - IMHO.
Now, if you want to be stuborn, go buy that book and tell me that it was worth your money. Make the same mistake I did - please.
I remember reading about a similar attempt using EPROMs in late '80s. In a normal recycling procedure, these were erased by shining a high intensity UV light for a couple of minutes through the glass window that's present in the IC shielding. After making sure all bits are reset, the window is covered by a sticker or label. Then the data is 'burned' and the (typically 256Kb/32KB) ROM was inserted into your BBC micro (insert favorite hobby computer).
Similar to the process you describe, an image could be gathered by setting all bits to 1 (or actually 0, as EPROMs have negative logic), then waiting for bits to flip. I don't think a lense was used, just a diafragm (dot in piece of black paper). On average, an exposure took 1-4 hours (and resulted in a very poor quality black/white image for current standards) if the scene was bright enough. Lighting the scene with a UV helped a bit, though visible light worked surprisingly well.
Of course, the whole whing was hardly useful, but remember that - at the time - the average micro had little more periferals than a keyboard, joystick. Mac had a mouse and some MSX systems had support for an analog "gen-locked" camera, BBC had some support for light pens. There may have been handscanners for PC/ATs. So mostly any hardware that would allow translation from analog to digital was greedily welcomed.
Jeffrey Zeldman is the author of Designing with Web Standards (and who was somehow never adequately punished for writing that book; please look inside to see what I mean).
... well ... designing with web standards, you know, xhtml & css. Instead, I found it's a 400+ page rant on oldfashioned non-standard design. There's no information at all about design and hardly anything helpful on web standards.
I recently made the mistake of buying that book a while ago, as it seemed to present information on
So, though Jeffrey himself may think differently, IMHO it's silly to regard him as a authority on anything web related.
This proves that - apparently - scientists have finally been able to *exactly* reproduce previous empirical results. Just imagine: not only is the impact exactly the same and on the same spot; on top of that the same musings appear on /. !
Amazing..
This seems more apt than your Firefox example. Firefox is a great brand, but it's far from obvious that "fire", "fox" or "firefox" have anything to do with browsing web pages. Neither are Netscape or Mozilla. Firefox is a great brand because it stands for a popular product, not the other way around. Same for "Linux", "Apache", "PHP", "Safari", ".net", or "XP".
So I can't see why GIMP would gain popularity by changing its name to GNU Photoshop or Kingkong (legal issues aside). A linspire/ubuntu/mandrake-newby will find GIMP under Start=>Applications=>Graphics (or similar) which is pretty intuitive to a Windows user.
I think blaming GIMPs lack of popularity with the general public on its name is very simplistic. I'm tempted to say that Photoshop is simply a better product - which is debatable - but its obvious that issues like marketing budget and commercial plugin support from third parties are important factors.
Yes - browsing for not-so-obvious applications in Freshmeat give me headaches as well. But it's not just the name, it's the varrying formats and quality of meta information about this software, and most importantly: a universal way to asses a component's quality, applicability for a certain task.
You're (probably) refering to this story. IMHO GIMP is a great name, or at least as good as Ps would be for Phostoshop. A more justified criticism would be directed against the GIMPs somewhat unintuitive GUI. Then, there are historical reasons to not do that...
But, as others have pointed out, with GIMP you have a choice: GIMPShop (which is still somewhat immature). For lazy readers:
Satisfied?
I Agree. I think you could draw an anology between current predictions on nanotech and predictions about nuclear applications in the 1930s or space travel in 1950s. Nanotech is promising, but it is impossible to tell what we'll see in 15 years.
In 1955, people standing on the moon in spacesuits within 15 years seemed just as likely/unlikely as having a collony on Mars, battling the Russians from earh orbiting satelites or launching spacecrafts with an atomic motor. Who would have thought we'd mostly loose interest in manned space flight shortly after pissing on the Moon?
Here's a dark vision on the future of nanotech, biotech or whatever hyped techs we've currently: First applications for may revolutionary technologies are in WARFARE. Carbon-nitrogen chemistry didn't solve starvation through fertilizers, but gave wealth to Alfred Nobel selling dynamite. Nuclear plants only followed after the atomic bomb's "succes". Computers have roots in WWII. Arguably, the ubiquitous communications and sharing of knowledged provided by the internet, cell phones and physical transport vehicles have enabled (some of) the terrorism we see currently. And though an all-out worldwide cyberwar is unlikely, internet has (yet again) not closed the gap between rich and poor, wealth and hunger, world peace, whatever - I digres.
It is not hard to imagine military applications for nanotech. A dirty bomb filled with nanofibers with asbestus-like properties should be just around the corner. And IMHO a bunch of undetectibly small spy bots is more foreseeable than a trillion gates on a chip.
The answer to Life, the Universe, and Everything must surely be the answer to finding this new prime number as well, right?!
(Unfortunately, Earth will probably be destroyed before anyone can read this post.)
For modern computers, a more relevant abstraction of computational power would be a random-access machine, since it models not just what kind of problems can be solved, but also (more realistically) in how much time that solution is found.
At a practical level, current chips are limited by the distance (lenght of wires) between interacting gates. In normal, planar designs, this distance can be reduced by regrouping interacting gates as close to each other as possible (ie.: making designs more clever), reducing the total number of gates or reducing the gate size (thus reducing the total chip size). Adding a second layer could half the needed die surface, allowing for smaller propagation times, thus higher clock frequency/more complexity/surface.
However, adding more layers has a lot of practical problems in the current production process. Therefore *any* successful alternative to produce 3D semi conductors is likely to boost processing power.
OK. Some good questions, but also some you really shouldn't ask, IMHO. Stuff like: What is the philosophy of the company? shows you didn't bother to study their marketing material. Similarly, you shouldn't ask How financially sound is this company? just like that. Better do some research and ask more targetted questions on that topic.
What is this company's culture? (Ex: Is it rigid and formal or relaxed and flexible?) What insight would that give you? What company is going to admid that they are either flexible in the sense that they regularly lay off 80% of employees or rigid in the sense that some processes completely lock up in a bureaucracy? Anyone at this point trying to sell his company will suggest they are both "professional" and have an "informal, pleasant" atmosphere.
Questions like Whom will I supervise? What projects and assignments will I be working on? and With whom will I be working most closely? should have been answered in the natural flow of conversation. If not, I'd definitely ask them, yes.
What do you consider to be the company's strengths and weaknesses? is brilliant. Even better have a taylored version of that, more relevant to that specific job. Be sure to suggest why you're qualified to help fix weaknesses. Same for What are the most challenging aspects of the position?
You can use C++ if you don't use multiple inheritance.
Worse: you can use C++ if you feel like doing C# without any of its merrits.
Some time ago I looked at porting a solid Windows based 100.000 lines of code C++ GUI application to managed C++. If was a mature and stable application developed over 15 years.
The idea was to used managed functionality for UI and maintain unmanaged code for the older parts. While there is some "support" for using both managed and unmanaged code, it became clear very soon that doing so leads to huge problems. All advice basically points you either to one or the other, mostly favouring managed code (its *NEW*, after all).
In doing so we ran into a lot of low level problems more than multiple class-inheritance (which IMHO is a stupid concept in C++ anyway). We finally ended up with loads of messy code that in a hardly supported IDE (I guess Visual Studio abandoned C++ almost entirely some bugs in VC6 are still not fixed). Also performance halfed in some of the low level functions, requiring complete redesign.
The short story. After a month we abandoned Microsoft's "seamless" CLR migration path in favor for good old-fashioned Java+CORBA for the UI and kept the C++ core mostly intact.
We could have used C#+CORBA as well, but I guess the morale is that the CLR as a multi-language vehicle is just a laugh - at least in case of C++.
>Flash = SVG + sound + ECMAScript. That's what I'm talking about. So if you think that has hickups on 5GHz, it'll have that on 350MHz.
Right. But does that tell you something about the adequacy of certain CPU or does that tell you something about Flash? And why do you need flash on an appliance again?
OK. My point is that in terms of usability, we havent come nearly as far from the old Newton days to justify the hefty hardware requirements of modern appliances. Chips get more powerful more or less according to Moore's law and software takes advantage, mostly by wasting clock cycles on eye candy. I like alpha blending, and full lenght DVD movies, but I'd much rather have a portable that's useful for more than a couple of hours. If it means a photo album slide show can only show 20 jpegs per second, that's fine with me ;-)
WRT to embedded it is *very* important to notice that batteries do not "grow" according to Moore's law. That's why we shouldn't expect mobile to look anything like desktop software in the first place.
Sure there's some truth in a higher number of bits that need to be moved on high-res color devices. But bitshifting is only a portion of GUI incurred CPU load. Don't have any number, but I suppose a significant portion is in clipping logic, or simply message passing, heap allocation, event handing and context switching. I mean, theoretically at 32bits moving 800x600x16 bits takes less than a microsecond so something other than bitshifting must be going on. Like, shifting the wrong bits in the first place - for example - due to inefficient programming.
For example. Scrolling in firefox is noticible on my 90MHz pentium. Sure, it may tak up to a full second. But it's noticible on my 3GHz Athlon as well. (Must be somewhere around one or two deciseconds). I use both with standard non-accelerated VGA at 1280x1024x32bpp. So, with a "bitshifter" that's supposed to be roughly 33 times faster a speedupfactor of only 10 is a bit disappointing, don't you think? (More so if you would take fsb bandwidth into account).
On the xyz developer thing. In a sense, you're right: embedded programming is just like programming C64, Amiga, Win32. The main difference is that here, size and bloat matters. Small screen, no keyboard and slow hardware requires tradoffs. In Wince, Microsoft makes most of these tradeoffs for you, but not necessarily the way you would make them yourself.
As you may have read in other posts, some stuff that you've come to think of as essential is simply not there. So a lot of time you find yourself recoding basic functions from scratch. Also, it doesn't give you the tools to scim and trim your binaries to the bare minimum, which is a major problem in the embedded area.
I thought mice - being pan dimensional beings - were far more advanced than humans (ranked 3, just after dolphins).
This is like modding an xbox 360/ps3/whatever with a Z80 - why whould you want to do that?
SVG: help is underway. Xara has a very fast anti-aliased vector rendering engine that has origins in Artworks, an unknown but blazingly fast vectorgraphics designer launched in 1991 for 12MHz ARM2 based archimedes A440. ;-).
But I'd have to admit that 20 frames per second is pushing it on a 90MHz pentium. Should just be possible with a 250MHz ARM, though
On mp3's, mind that this specific appliance features TI's OMAP arch which I believe includes a DSP that should take the major workload off the CPU; unlike my 90MHz pentium system. Could help on some video tasks as well, I suppose.
Flash. Well, if probably will have some hickups once intel finally hits the 5GHz. That both due to macromedia beefing up the platform in sync or faster than Moore's law can provide for and partly due to incompetent programmers. Its a nice gadget for games, animations and simple interfaces, but I suppose Flash was never intended for any kind of real-time performance.
>At any rate, a custom OS would do this device better than whatever they've got right now.
this could help. A little, at least...
...But your math doesn't work, most of the time. The ratio you refer to applies to video out and is mostly unrelated to the CPU. Except for streaming video, which really is a silly application on a lightweight tablet. There, wifi bandwidth is more likely to be a bottleneck than the CPU.
Anyway, the newton *was* able to reproduce audio in the formats considered "standard" at the time. I don't see why contemporary (compressed) formats would be a problem, as they take less than 30% CPU time on my 10 year old 90MHz Pentium box.
And images. What exactly is it that you want to do with them that requires over 250MHz ARM power?
As for browsers, I have to agree that these have evolved to very complex pieces of software. Though I won't debate that firefox, opera, safari and IE all carry a certain portion of bloat, I don't see small embedded browsers with full support any time soon.
As for Windows, you gottabe joking. You're not a WinCE developer, are you?
Really people, there is an easy way out if you don't like the idea of the DoD getting a utility out of this dish in exchanger for millions of tax payer dollars: Raise the money yourself.
Is the DoD suddenly a profitable organization, kind enough to sahre some of these profits with science projects? Last time I checked the money was raised by "ourselves" through taxes and borrowing from future generations.
This is great and all, I just don't see why this is front page news. I would consider ARM-DSP hardware with Linux support mainstream rather than a bold step taken by TI. A random grab from sponsored adds on google:
http://www.sandorlabs.com/
http://www.compulab.co.il/
http://www.plexxa.com/
http://www.atmel.com/products/AT91/
http://www.xbow.com/
http://www.lynuxworks.com/
All products seem to support Linux on ARM/XScale and (at least) some in combination with a DSP.
Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?