you want google web toolkit. it will allow you to stay in the shit world of single-inheritance java that you are used to dealing with, as well as give you a decent widget toolkit to work with. when you wake up from the insanity of fighting with java, and are happy to program in a decent compact language like python, there's always pyjamas. the advantage of taking this route is that the widget set API of pyjamas is near-identical to that of GWT 1.5, with bits of 1.6 and 1.7 thrown in.
this is a misrepresentation of what President Barack Obama actually said. he said he would *investigate*, by putting this guy's resume in front of companies and ask them the pointed question of why such skilled engineers are not being prioritised for jobs. he didn't say "i'll find you a job".
what was actually much more stunning to my mind was the fact that it appears that the U.S. has a President who is willing to say "I Don't Know The Answer Right Now". he did it incredibly subtly: he said something along the lines of "this is very interesting and i too would like to find out what the answer is", which is just... it takes my breath away that he could be that sensible.
i thought politicians were supposed to be ignorant, arrogant and had to pretend to have all the answers - or at least to be intelligent enough to give the impression of being arrogant. although i fully appreciate that in the case of George W. Bush (jr), his ultra-low IQ means that he really was genuinely ignorant ["if the president of Ireland needs anything, anything at all, he only has to ask, now excuse me i gotta go get a burger"].
ahh, i can just see the divorce settlement arguments already, over who owns the contract, who owns the bill, and who's going to pay for little johnny's excessive Minecraft and Runescape usage...
i particularly like the section headings "once upon a time" and "the puzzle duh duh duhhhhh". i think however in the context of this article, the following exerpt from the background puts the corruption that has been highlighted by TFA to shame:
"So what follows is a novel study (scientifically and conceptually) in ‘kids speak’ without references to past literature, which is a challenge. Although the historical context of any study is of course important, including references in this instance would be disingenuous for two reasons. First, given the way scientific data are naturally reported, the relevant information is simply inaccessible to the literate ability of 8- to 10-year-old children, and second, the true motivation for any scientific study (at least one of integrity) is one's own curiousity, which for the children was not inspired by the scientific literature, but their own observations of the world. This lack of historical, scientific context does not diminish the resulting data, scientific methodology or merit of the discovery for the scientific and ‘non-scientific’ audience. On the contrary, it reveals science in its truest (most naive) form, and in this way makes explicit the commonality between science, art and indeed all creative activities."
the problem with _not_ enforcing GPL compliance is that if it goes on for long enough, companies may legitimately claim an "estoppel" defense, which summaries as "well you haven't bothered up until now, therefore you must not be bothered at all, go away". this is an *acceptable* legal defense, and it means that, by not enforcing Copyright, people are *losing* the right to that Copyright. that includes Google as much as anyone else, and the reason why i am singling them out is because a senior member of staff within Google specifically told me, when i pointed out the rampant GPL violations of the linux kernel source code inside Android, that "Google is not the world's GPL Cop".
the problem with the x86 architecture is that it was designed to be compact and space-saving: the escape-sequences that go up and up and up from 8086 to 80186 to 286 to 386 to 486 to 586 to 64-bit are incredibly efficiently encoded. *BUT*, there comes a massive performance penalty which is that the clock rate now has to be twice as fast as a RISC processor in order to achieve the same results. RISC processors, with the exception possibly of the Xtensa (which kinda cheats by allowing VLIW as well), tend to substitute larger memory requirements for less compact instructions; ARM cheats by actually compressing the instructions! (thumb).
so it's all quite horrendously complex, but the kicker is that power goes up in a square law with processor speed. double the speed you need FOUR times the power. so, if an x86 processor has to run twice as fast to achieve the same results as a lowly RISC core which is eating twice the amount of RAM as an x86, the x86 is using FOUR times the power in order to keep up with the RISC processor.
it's never that simple, though: ARM and other RISC cores also trade higher latency for lower power. _and_ there is the issue of trying to run a 64-bit or a 128-bit memory bus, off to a separate "Northbridge" chip: these RISC all-in-one SoCs with embedded GPUs and integrated I/O just don't have that problem, and they're not trying to drive massive amounts of external lines just to get access to memory [through a silly "Northbridge" chip].
but that's not the end of the story. with the advent of DDR3 and the introduction of 28nm, RISC cores are going to eat x86 for breakfast, lunch and dinner, as RISC CPU designs means can easily run at 2 to 2.5ghz in 28nm... and still only use 1 to 1.5 watts! and with DDR3 RAM being so fast, the "problem" of latency for RISC CPUs is *also* going away.
if AMD tells you they can do a 2 watt x86 CPU (like in TFA), they aren't exactly lying, but they're sailing pretty close to the wind.
bottom line is: if they're saying that they're architecture-agnostic, that basically saves their bacon. let's hope that they do a decent job, eh? it would be absolutely cool for them to put an ATI-based "Open" GPU with full and complete GPL'd source code along-side an ARM or any other CPU core.
i apologise for the smell. i know you're joking in some ways but i do actually genuinely know what you mean, and what you're referring to. it's a really strange phenomenon that i've encountered so many times now (over 15 years) that i've had enough empirical evidence to be able to summarise it as follows. any person who is genuine can encounter me (even if i say nothing) and they will react favourably towards me. any person who is *not* genuine - who is either deceitful or dishonest - will *automatically* try to attack me. they will find absolutely any way that they can to discredit or undermine everything and anything, in any way possible. sometimes their actions are so extreme that even they begin to notice that they are doing something wrong; sometimes they don't.
i'm a disruptive influence and an accelerator: what can i say? *shrugs*.
it's not "my" project. as a software engineer who knows the value of "egoless programming", which specifically trains people to avoid the use of personal pronouns, i cannot let this one go. allow me to make a correction for you:
"...from someone letting people know that there exists *a* project, which is community-based, that is actually set up as a Community Interest Company (google it)..."
"You've done reverse engineering; you didn't get results."
sorry, you've misunderstood. google "lkcl htc universal", "ct-pc89e", "lkcl hw6915", "lkcl htc blueangel" and "samba ntdom". i get results all right - _technical_ successful results. however, what i *didn't* get was the result "a mass-volume product pre-shipping with a GNU/Linux distribution out-of-the-box". it made absolutely no difference that i succeeded _technically_ in completing the reverse-engineering: the manufacturers still were not interested. this was the naive mistake that i made.
you've misunderstood, jojoba86. where are the devices which can be purchased off-the-shelf with rockbox linux pre-installed? where in the interview did it say "the rockbox developers have been working with manufacturer X on a deal which will bring you open devices"? in fact, the interview tells you a complete opposite story, doesn't it? it tells you that the developers are forced to perform reverse-engineering, forced to work for months *without* cooperation from the very people who actually created the hardware.
hardware which, given how fast things are moving, will have been on the verge of being out-of-date at the time it actually shipped, and, by the time the hardware actually has rockbox running on it is _definitely_ out-of-date.
so - tell me where i can purchase a *modern* device at an affordable price which has an entirely open non-DRM-locked, non-tivoised and Software (Libre) GNU/Linux distribution pre-installed on it, and an active and vibrant community around it, and i'll tell you what: i'll contact the slashdot operators for you and will urge them to remove what i wrote.
"Over time it's only grown to be even more challenging as over the years the companies involved have gotten more and more 'secret'. In the beginning you could actually read markers on chips in the devices and then search for the chips online and find data sheets for them that told us how to program them."
i've done reverse-engineering, and yes it is exciting, but it doesn't really get results: it's damn hard work, and for what? you're always behind the times - never innovating, always riding on the coat-tails of companies who, as linus notes on page 2 of the interview, end up making hardware design mistakes, and you invested _how_ much time in order to find that out?
so we set up http://rhombus-tech.net/ as an initiative to create open hardware that is actually desirable as mass-volume products, with free software developers being actively engaged and consulted on the hardware _and_ software development at every step of the way.
there are several such initiatives that could really do with working together - the most recent one is the plasma "spark" tablet - except that there, unfortunately, they appear to have picked a tablet from a company that is known to be willfully committing GPL violations (zenithink). not too many people spotted that one, in amongst the otherwise-exciting news reports, whoops.
yes. that's what i was referring to about the paging. but this is for a massively-simplified CPU, with "no cacheing". so you'd have to feed the DRAM very very precisely. can you imagine, however, explaining to application writers that they have to create the output / input at *exactly* the rate at which the DDR RAM accepts it?....:)
I know this is probably going to sound flippant, but I'm sure there is a genuine reason and I'd be interested to hear it... Why not just write it both ways and test?
Better yet, why not get the compiler to try different parallelisations and use a genetic algorithm to optimise automatically?
*sigh*. because it took literally days to write the assembly code and get the I/O routines right. the code rate was measured in DAYS per instruction, not the other way round. you couldn't reuse the functions because they were all completely different.
it also didn't help that the compiler was actually a pre-processor, which took out "ASP" instructions that were inserted with asp {.... } and replaced them with c code where the assembly instructions were encoded as 32-bit memory-writes to the FIFO's address! the reason for that was that the CPUs were actually on a memory-mapped PCI card.
plus, there were several hardware engineers in the company: they didn't really have time or resources for doing things like optimise the software, despite that being far more important than the actual hardware!
the DEC alpha didn't have a floating-point unit: it had primitives that could be used to emulate floating-point almost as quickly as having a dedicated FPU. i spoke to a friend several years back who know about these things: he said that a 1s complement add goes a long way towards speeding up floating-point using integer operations. i have _no_ idea what he meant but it was kinda interesting to hear from someone who'd really thought about this stuff.
Aspex Semiconductors took this a lot further. they did content-addressable-memory. ok, they did a hell of a lot more than that. they created a massively-parallel deep SIMD architecture with a 2-bit CPU (early versions were 1 bit), with each CPU having something like 256 bits of memory to play with. ok, early versions had 128-bits of "straight" RAM and 256 bits of content-addressable RAM. when i was working for them they were planning the VASP-G architecture which would have 65536 such 2-bit CPUs on a single die. it was the 10th largest CPU being designed, in the world, at the time.
programming such CPUs was - is - a complete f*****g nightmare. you not only have the parallelism of the CPU to deal with but you have the I/O handling to deal with. do you try to fit the data 1-bit-wide per CPU and process it serially? or... do you try to fit the data across 32 CPUs and process it in parallel? (each CPU was connected to its 2 neighbours so you could do this sort of thing). or... do you do anything in between, because if you have only 1-bit-wide that means that the I/O is held up, but if you do 32-bits across 32 CPUs you process it so quick that you're now I/O bound.
much of the work in fitting algorithms onto ASPs involved having to write bloody spreadsheets in Excel to analyse whether it was best to use 1, 2, 4.... 32 CPUs just to process the bloody data! 6 weeks of analysis to write 30 lines of code for god's sake!
it gets worse: you can't even go read a book on algorithms for hardware because that doesn't apply; you can't go read a book on algorithms for software because _that_ doesn't apply. working out how to fit AES onto the Aspex Semi CPU took me about... i think it was 6 weeks, to even _remotely_ make it optimal. i had to read up on the design of the 2-bit Galois Field theory behind the S-Boxes, because although you could do 8-bit S-Box substitution by running 256 "compare" instructions, one per substitution, in parallel across all 4096 CPUs, it turned out that if you actually implemented the *original* 2-bit Galois Field mathematical operations in each of the 2-bit CPUs you could get it down to 40 instructions, not 256.
and that was just for _one_ part of the Rijndael algorithm: i had to do a comprehensive detailed analysis of _every_ aspect of the algorithm.
in other words, everything that you _think_ you know about optimising software and algorithm design for either hardware or for software is completely and utterly wrong, for these types of massively-parallel map-reduce and content-addressable-memory CPUs.
that leaves them somewhere in the very very specialist dept, and even there, they have problems, because it takes so long to verify and design a new CPU. when the Aspex VASP-F architecture was being planned, it was AMAZING! wow! 100x faster than the best Pentium-III processor! of course, within 18 months it was only 20x better than the top-of-the-line Pentium that was available, and by the time it _actually_ came out, it was only 5x better than a bunch of x86 CPUs, which are a hell of a lot easier to program.
it was the same story for the next version of the CPU, even though that promised to have 64k processing elements...
the cache is there because the speed of DRAM, regardless of how fast you can communicate with it, still has latency issues on addressing.
to do the "routing" to address a 4-bit bus, you need 1/2 the number of transistors than if you addressed a 2-bit bus. each time you add another bit to the address range, you have increased the latency of access.
if you were to provide entirely random-access to an entire 32-bit range you would absolutely kill performance. so, what RAM IC designers do is they go "ok, you're not going to get 32-bit addressing, you're going to get 14-bit addressing, you're going to have to read an entire page of 1k or 2kbits, and you're going to have to have parallel ICs, the first IC does bits 0 to 1 of the data, the second IC does bits 2 and 3 etc."
this relies on the design of the processor having a VM architecture - paging.
but the same principle applies *inside* the processor: even just decoding the addressing, in the MMU, it's *still* too much latency involved.
so this is why you end up with hierarchical cacheing - 1st level is tiny, 2nd level is huge.
even with RISC designs you _still_ have to have 1st and 2nd level caches in order to remain competitive. if you've ever seen a picture of a RISC CPU, it's astounding: the actual CPU is like 1% of the total area; caches are huuuge by comparison, crossbar routing takes up 50% of the chip and the I/O pads, required to be massive in order to handle the current, can take up something like 5% of the chip (guessing here, it's been a while since i looked at an annotated example CPU).
there's a problem with doing designs like this. the tooling for CPUs is very very specific: 28nm, 32nm, 45nm - all those companies that do the simulations where they charge something like $USD 250,000 per week to license their tools like mentor do - have written the tools SPECIFICALLY for those geometries.
if you wander randomly outside of those geometries you are either on your own or you are into some unbelievably-high development costs.
why is this relevant?
it's because the DRAM manufacturers do *not* stick to the well-known geometries: they vary the geometry in order to get the absolute best performance because the cell layout is absolutely identical for DRAM ICs. and, because those cells _are_ identical, the verification process is much simpler than is required for a complex CPU.
in other words, this company is trying to mix-and-match two wildly different approaches. in other words, what he's doing is either incredibly expensive or is sub-optimal. which begs the question: what's it _for_?
The teacher, with a PhD in English, was a master. She probably couldn't code worth much, but she could take unclear concepts and make them clear enough for a newbie.
As long as you hire great programmers you are going to get great programs. If you want great documentation, you need a great documentor.
it's funny you should mention this, because somewhere about 3 years ago wasn't there a slashdot article about some entrepreneur who didn't hire computer science majors (this was the U.S...) he hired english language majors and then trained them to program?
the end-result was that he got people who produced better results because they were better able to express themselves and had already been trained to handle and comprehend more complex structures than people who thought they could program.
i've advised openddr to contact the SFLC but this is twitter: can i recommend that people also advise openddr on twitter to contact the SFLC, as well as pressurise the moron who doesn't understand what the DMCA is for.
the DMCA, afiui, requires some form of [potentially entirely and utterly useless] encryption. this is _data_. in an unencrypted, unencumbered and freely-licensed format. sounds like one for the SFLC....
i think it would be an interesting study, even an informal one, to see how many other people have a physical condition that is listed as "unsurvivable within period X" and to see if there is a correlation between them "defying the predictions" and, as hawking himself puts it, having "something to live for".
put another way: how many people have, on learning of their condition, literally lost the will to live, and how many took it as a challenge to fight for their right to life and a purpose?
a number of people have caught on to the fact that the engine behind webos is the exact same engine as behind safari, but that safari is *not* the basis of apple's operating systems. the glue that makes apple's OS so dynamic is objective-C, which has built-in runtime dynamic data typing similar to DCOM. that means that components can interact, written in c++, or any other programming language including scripting languages, *without* having to recompile any applications.
how do i know this? it's because i was asked, 2 years ago, to get pythonwebkit up-and-running for an embedded client, running on a superb but very strange 400mhz ARM9 processor with access to 800mhz DDR2 RAM (for doing 1080p HDMI video). for an ARM9 it ran like lightning. *but*... when i put pywebkitqt4 on it, it not only doubled the amount of memory usage but it absolutely _hammered_ the processor.
the startup time _just_ for webkitqt4 alone was something like 90 seconds and took up almost all of the available 256mb of RAM. the next best was webkit-enlightenment (130mb and about 8 seconds). webkit-efb was what samsung sponsored for the "bada" initiative. next after that was webkit-gtk at around 6 seconds.
however none of these were acceptable, so i helped denis do a port of webkit to directfb. that got the startup time - on a 400mhz ARM9 - to a stunning 1.5 seconds.
if HP or Palm had paid myself and denis to do that work several years ago, things would have been very different: the startup time and performance of WebOS would have been staggeringly quick.
and the thing is, because the browser _is_ the OS, there's absolutely no good reason to even have GTK, QT4 or in fact any other "engine" underneath. why do you think google created an entire new direct-rendering API ("silk" i think it was called) for android?
lesson learned. only cost $1.2 billion. i would have been happy to have been paid 0.1% of that to fix the problem. talk about irony.
Slashdot Mirror
you want google web toolkit. it will allow you to stay in the shit world of single-inheritance java that you are used to dealing with, as well as give you a decent widget toolkit to work with. when you wake up from the insanity of fighting with java, and are happy to program in a decent compact language like python, there's always pyjamas. the advantage of taking this route is that the widget set API of pyjamas is near-identical to that of GWT 1.5, with bits of 1.6 and 1.7 thrown in.
this is a misrepresentation of what President Barack Obama actually said. he said he would *investigate*, by putting this guy's resume in front of companies and ask them the pointed question of why such skilled engineers are not being prioritised for jobs. he didn't say "i'll find you a job".
what was actually much more stunning to my mind was the fact that it appears that the U.S. has a President who is willing to say "I Don't Know The Answer Right Now". he did it incredibly subtly: he said something along the lines of "this is very interesting and i too would like to find out what the answer is", which is just... it takes my breath away that he could be that sensible.
i thought politicians were supposed to be ignorant, arrogant and had to pretend to have all the answers - or at least to be intelligent enough to give the impression of being arrogant. although i fully appreciate that in the case of George W. Bush (jr), his ultra-low IQ means that he really was genuinely ignorant ["if the president of Ireland needs anything, anything at all, he only has to ask, now excuse me i gotta go get a burger"].
ahh, i can just see the divorce settlement arguments already, over who owns the contract, who owns the bill, and who's going to pay for little johnny's excessive Minecraft and Runescape usage...
in fact, these kids got their research published without any references *at all*. http://rsbl.royalsocietypublishing.org/site/misc/BlackawtonBees.xhtml
i particularly like the section headings "once upon a time" and "the puzzle duh duh duhhhhh". i think however in the context of this article, the following exerpt from the background puts the corruption that has been highlighted by TFA to shame:
"So what follows is a novel study (scientifically and conceptually) in ‘kids speak’ without references to past literature, which is a challenge. Although the historical context of any study is of course important, including references in this instance would be disingenuous for two reasons. First, given the way scientific data are naturally reported, the relevant information is simply inaccessible to the literate ability of 8- to 10-year-old children, and second, the true motivation for any scientific study (at least one of integrity) is one's own curiousity, which for the children was not inspired by the scientific literature, but their own observations of the world. This lack of historical, scientific context does not diminish the resulting data, scientific methodology or merit of the discovery for the scientific and ‘non-scientific’ audience. On the contrary, it reveals science in its truest (most naive) form, and in this way makes explicit the commonality between science, art and indeed all creative activities."
the problem with _not_ enforcing GPL compliance is that if it goes on for long enough, companies may legitimately claim an "estoppel" defense, which summaries as "well you haven't bothered up until now, therefore you must not be bothered at all, go away". this is an *acceptable* legal defense, and it means that, by not enforcing Copyright, people are *losing* the right to that Copyright. that includes Google as much as anyone else, and the reason why i am singling them out is because a senior member of staff within Google specifically told me, when i pointed out the rampant GPL violations of the linux kernel source code inside Android, that "Google is not the world's GPL Cop".
the problem with the x86 architecture is that it was designed to be compact and space-saving: the escape-sequences that go up and up and up from 8086 to 80186 to 286 to 386 to 486 to 586 to 64-bit are incredibly efficiently encoded. *BUT*, there comes a massive performance penalty which is that the clock rate now has to be twice as fast as a RISC processor in order to achieve the same results. RISC processors, with the exception possibly of the Xtensa (which kinda cheats by allowing VLIW as well), tend to substitute larger memory requirements for less compact instructions; ARM cheats by actually compressing the instructions! (thumb).
so it's all quite horrendously complex, but the kicker is that power goes up in a square law with processor speed. double the speed you need FOUR times the power. so, if an x86 processor has to run twice as fast to achieve the same results as a lowly RISC core which is eating twice the amount of RAM as an x86, the x86 is using FOUR times the power in order to keep up with the RISC processor.
it's never that simple, though: ARM and other RISC cores also trade higher latency for lower power. _and_ there is the issue of trying to run a 64-bit or a 128-bit memory bus, off to a separate "Northbridge" chip: these RISC all-in-one SoCs with embedded GPUs and integrated I/O just don't have that problem, and they're not trying to drive massive amounts of external lines just to get access to memory [through a silly "Northbridge" chip].
but that's not the end of the story. with the advent of DDR3 and the introduction of 28nm, RISC cores are going to eat x86 for breakfast, lunch and dinner, as RISC CPU designs means can easily run at 2 to 2.5ghz in 28nm... and still only use 1 to 1.5 watts! and with DDR3 RAM being so fast, the "problem" of latency for RISC CPUs is *also* going away.
if AMD tells you they can do a 2 watt x86 CPU (like in TFA), they aren't exactly lying, but they're sailing pretty close to the wind.
bottom line is: if they're saying that they're architecture-agnostic, that basically saves their bacon. let's hope that they do a decent job, eh? it would be absolutely cool for them to put an ATI-based "Open" GPU with full and complete GPL'd source code along-side an ARM or any other CPU core.
i apologise for the smell. i know you're joking in some ways but i do actually genuinely know what you mean, and what you're referring to. it's a really strange phenomenon that i've encountered so many times now (over 15 years) that i've had enough empirical evidence to be able to summarise it as follows. any person who is genuine can encounter me (even if i say nothing) and they will react favourably towards me. any person who is *not* genuine - who is either deceitful or dishonest - will *automatically* try to attack me. they will find absolutely any way that they can to discredit or undermine everything and anything, in any way possible. sometimes their actions are so extreme that even they begin to notice that they are doing something wrong; sometimes they don't.
i'm a disruptive influence and an accelerator: what can i say? *shrugs*.
:)
"When you have the wrong goal, it doesn't matter what you do, you will fail."
that's what i learned from that failure, and changed the goal.
"from someone trying to push their own project. "
it's not "my" project. as a software engineer who knows the value of "egoless programming", which specifically trains people to avoid the use of personal pronouns, i cannot let this one go. allow me to make a correction for you:
"...from someone letting people know that there exists *a* project, which is community-based, that is actually set up as a Community Interest Company (google it)..."
"You've done reverse engineering; you didn't get results ."
sorry, you've misunderstood. google "lkcl htc universal", "ct-pc89e", "lkcl hw6915", "lkcl htc blueangel" and "samba ntdom". i get results all right - _technical_ successful results. however, what i *didn't* get was the result "a mass-volume product pre-shipping with a GNU/Linux distribution out-of-the-box". it made absolutely no difference that i succeeded _technically_ in completing the reverse-engineering: the manufacturers still were not interested. this was the naive mistake that i made.
you've misunderstood, jojoba86. where are the devices which can be purchased off-the-shelf with rockbox linux pre-installed? where in the interview did it say "the rockbox developers have been working with manufacturer X on a deal which will bring you open devices"? in fact, the interview tells you a complete opposite story, doesn't it? it tells you that the developers are forced to perform reverse-engineering, forced to work for months *without* cooperation from the very people who actually created the hardware.
hardware which, given how fast things are moving, will have been on the verge of being out-of-date at the time it actually shipped, and, by the time the hardware actually has rockbox running on it is _definitely_ out-of-date.
so - tell me where i can purchase a *modern* device at an affordable price which has an entirely open non-DRM-locked, non-tivoised and Software (Libre) GNU/Linux distribution pre-installed on it, and an active and vibrant community around it, and i'll tell you what: i'll contact the slashdot operators for you and will urge them to remove what i wrote.
"Over time it's only grown to be even more challenging as over the years the companies involved have gotten more and more 'secret'. In the beginning you could actually read markers on chips in the devices and then search for the chips online and find data sheets for them that told us how to program them."
i've done reverse-engineering, and yes it is exciting, but it doesn't really get results: it's damn hard work, and for what? you're always behind the times - never innovating, always riding on the coat-tails of companies who, as linus notes on page 2 of the interview, end up making hardware design mistakes, and you invested _how_ much time in order to find that out?
so we set up http://rhombus-tech.net/ as an initiative to create open hardware that is actually desirable as mass-volume products, with free software developers being actively engaged and consulted on the hardware _and_ software development at every step of the way.
there are several such initiatives that could really do with working together - the most recent one is the plasma "spark" tablet - except that there, unfortunately, they appear to have picked a tablet from a company that is known to be willfully committing GPL violations (zenithink). not too many people spotted that one, in amongst the otherwise-exciting news reports, whoops.
yes. that's what i was referring to about the paging. but this is for a massively-simplified CPU, with "no cacheing". so you'd have to feed the DRAM very very precisely. can you imagine, however, explaining to application writers that they have to create the output / input at *exactly* the rate at which the DDR RAM accepts it? .... :)
I know this is probably going to sound flippant, but I'm sure there is a genuine reason and I'd be interested to hear it... Why not just write it both ways and test?
Better yet, why not get the compiler to try different parallelisations and use a genetic algorithm to optimise automatically?
*sigh*. because it took literally days to write the assembly code and get the I/O routines right. the code rate was measured in DAYS per instruction, not the other way round. you couldn't reuse the functions because they were all completely different.
it also didn't help that the compiler was actually a pre-processor, which took out "ASP" instructions that were inserted with asp { .... } and replaced them with c code where the assembly instructions were encoded as 32-bit memory-writes to the FIFO's address! the reason for that was that the CPUs were actually on a memory-mapped PCI card.
plus, there were several hardware engineers in the company: they didn't really have time or resources for doing things like optimise the software, despite that being far more important than the actual hardware!
the DEC alpha didn't have a floating-point unit: it had primitives that could be used to emulate floating-point almost as quickly as having a dedicated FPU. i spoke to a friend several years back who know about these things: he said that a 1s complement add goes a long way towards speeding up floating-point using integer operations. i have _no_ idea what he meant but it was kinda interesting to hear from someone who'd really thought about this stuff.
Aspex Semiconductors took this a lot further. they did content-addressable-memory. ok, they did a hell of a lot more than that. they created a massively-parallel deep SIMD architecture with a 2-bit CPU (early versions were 1 bit), with each CPU having something like 256 bits of memory to play with. ok, early versions had 128-bits of "straight" RAM and 256 bits of content-addressable RAM. when i was working for them they were planning the VASP-G architecture which would have 65536 such 2-bit CPUs on a single die. it was the 10th largest CPU being designed, in the world, at the time.
programming such CPUs was - is - a complete f*****g nightmare. you not only have the parallelism of the CPU to deal with but you have the I/O handling to deal with. do you try to fit the data 1-bit-wide per CPU and process it serially? or... do you try to fit the data across 32 CPUs and process it in parallel? (each CPU was connected to its 2 neighbours so you could do this sort of thing). or... do you do anything in between, because if you have only 1-bit-wide that means that the I/O is held up, but if you do 32-bits across 32 CPUs you process it so quick that you're now I/O bound.
much of the work in fitting algorithms onto ASPs involved having to write bloody spreadsheets in Excel to analyse whether it was best to use 1, 2, 4 .... 32 CPUs just to process the bloody data! 6 weeks of analysis to write 30 lines of code for god's sake!
it gets worse: you can't even go read a book on algorithms for hardware because that doesn't apply; you can't go read a book on algorithms for software because _that_ doesn't apply. working out how to fit AES onto the Aspex Semi CPU took me about... i think it was 6 weeks, to even _remotely_ make it optimal. i had to read up on the design of the 2-bit Galois Field theory behind the S-Boxes, because although you could do 8-bit S-Box substitution by running 256 "compare" instructions, one per substitution, in parallel across all 4096 CPUs, it turned out that if you actually implemented the *original* 2-bit Galois Field mathematical operations in each of the 2-bit CPUs you could get it down to 40 instructions, not 256.
and that was just for _one_ part of the Rijndael algorithm: i had to do a comprehensive detailed analysis of _every_ aspect of the algorithm.
in other words, everything that you _think_ you know about optimising software and algorithm design for either hardware or for software is completely and utterly wrong, for these types of massively-parallel map-reduce and content-addressable-memory CPUs.
that leaves them somewhere in the very very specialist dept, and even there, they have problems, because it takes so long to verify and design a new CPU. when the Aspex VASP-F architecture was being planned, it was AMAZING! wow! 100x faster than the best Pentium-III processor! of course, within 18 months it was only 20x better than the top-of-the-line Pentium that was available, and by the time it _actually_ came out, it was only 5x better than a bunch of x86 CPUs, which are a hell of a lot easier to program.
it was the same story for the next version of the CPU, even though that promised to have 64k processing elements...
the cache is there because the speed of DRAM, regardless of how fast you can communicate with it, still has latency issues on addressing.
to do the "routing" to address a 4-bit bus, you need 1/2 the number of transistors than if you addressed a 2-bit bus. each time you add another bit to the address range, you have increased the latency of access.
if you were to provide entirely random-access to an entire 32-bit range you would absolutely kill performance. so, what RAM IC designers do is they go "ok, you're not going to get 32-bit addressing, you're going to get 14-bit addressing, you're going to have to read an entire page of 1k or 2kbits, and you're going to have to have parallel ICs, the first IC does bits 0 to 1 of the data, the second IC does bits 2 and 3 etc."
this relies on the design of the processor having a VM architecture - paging.
but the same principle applies *inside* the processor: even just decoding the addressing, in the MMU, it's *still* too much latency involved.
so this is why you end up with hierarchical cacheing - 1st level is tiny, 2nd level is huge.
even with RISC designs you _still_ have to have 1st and 2nd level caches in order to remain competitive. if you've ever seen a picture of a RISC CPU, it's astounding: the actual CPU is like 1% of the total area; caches are huuuge by comparison, crossbar routing takes up 50% of the chip and the I/O pads, required to be massive in order to handle the current, can take up something like 5% of the chip (guessing here, it's been a while since i looked at an annotated example CPU).
there's a problem with doing designs like this. the tooling for CPUs is very very specific: 28nm, 32nm, 45nm - all those companies that do the simulations where they charge something like $USD 250,000 per week to license their tools like mentor do - have written the tools SPECIFICALLY for those geometries.
if you wander randomly outside of those geometries you are either on your own or you are into some unbelievably-high development costs.
why is this relevant?
it's because the DRAM manufacturers do *not* stick to the well-known geometries: they vary the geometry in order to get the absolute best performance because the cell layout is absolutely identical for DRAM ICs. and, because those cells _are_ identical, the verification process is much simpler than is required for a complex CPU.
in other words, this company is trying to mix-and-match two wildly different approaches. in other words, what he's doing is either incredibly expensive or is sub-optimal. which begs the question: what's it _for_?
The teacher, with a PhD in English, was a master. She probably couldn't code worth much, but she could take unclear concepts and make them clear enough for a newbie.
As long as you hire great programmers you are going to get great programs. If you want great documentation, you need a great documentor.
it's funny you should mention this, because somewhere about 3 years ago wasn't there a slashdot article about some entrepreneur who didn't hire computer science majors (this was the U.S...) he hired english language majors and then trained them to program?
the end-result was that he got people who produced better results because they were better able to express themselves and had already been trained to handle and comprehend more complex structures than people who thought they could program.
it looks like this person is responsible for the stupidity: https://twitter.com/#!/luca_passani
i've advised openddr to contact the SFLC but this is twitter: can i recommend that people also advise openddr on twitter to contact the SFLC, as well as pressurise the moron who doesn't understand what the DMCA is for.
the DMCA, afiui, requires some form of [potentially entirely and utterly useless] encryption. this is _data_. in an unencrypted, unencumbered and freely-licensed format. sounds like one for the SFLC....
i think it would be an interesting study, even an informal one, to see how many other people have a physical condition that is listed as "unsurvivable within period X" and to see if there is a correlation between them "defying the predictions" and, as hawking himself puts it, having "something to live for".
put another way: how many people have, on learning of their condition, literally lost the will to live, and how many took it as a challenge to fight for their right to life and a purpose?
a number of people have caught on to the fact that the engine behind webos is the exact same engine as behind safari, but that safari is *not* the basis of apple's operating systems. the glue that makes apple's OS so dynamic is objective-C, which has built-in runtime dynamic data typing similar to DCOM. that means that components can interact, written in c++, or any other programming language including scripting languages, *without* having to recompile any applications.
no, if you want to know why webos is so fracking slow, you only have to look right here: http://opensource.palm.com/3.0.4/index.html
notice anything? keep scrolling down... keep scrolling down.. lmnop..q... ah ha!
qt4 qt4-4.7.1.tgz qt4-4.7.1-patches.gz
that's the reason.
how do i know this? it's because i was asked, 2 years ago, to get pythonwebkit up-and-running for an embedded client, running on a superb but very strange 400mhz ARM9 processor with access to 800mhz DDR2 RAM (for doing 1080p HDMI video). for an ARM9 it ran like lightning. *but*... when i put pywebkitqt4 on it, it not only doubled the amount of memory usage but it absolutely _hammered_ the processor.
the startup time _just_ for webkitqt4 alone was something like 90 seconds and took up almost all of the available 256mb of RAM. the next best was webkit-enlightenment (130mb and about 8 seconds). webkit-efb was what samsung sponsored for the "bada" initiative. next after that was webkit-gtk at around 6 seconds.
however none of these were acceptable, so i helped denis do a port of webkit to directfb. that got the startup time - on a 400mhz ARM9 - to a stunning 1.5 seconds.
if HP or Palm had paid myself and denis to do that work several years ago, things would have been very different: the startup time and performance of WebOS would have been staggeringly quick.
and the thing is, because the browser _is_ the OS, there's absolutely no good reason to even have GTK, QT4 or in fact any other "engine" underneath. why do you think google created an entire new direct-rendering API ("silk" i think it was called) for android?
lesson learned. only cost $1.2 billion. i would have been happy to have been paid 0.1% of that to fix the problem. talk about irony.
Sadly nobody ever created the phone-peripheral to make this into a smartphone
gpephone. http://gpephone.linuxtogo.org/