psp is the only INTERESTING device out there because its the ONLY portable device with 3d capabilities AS OF YET. *rabble rabble rabble*
Furthermore: <a href="http://www.goop.org/psp/gl/">http://www.goop .org/psp/gl/</a> <i>My goal with this library is to provide a efficient, useful and (relatively) complete subset of OpenGL which makes all the PSP's hardware abilities available, either through standard OpenGL mechanisms or with extensions.</i>
please go put that back in your mouth and go smoke it. then wash that mouth out.
to everyone else, hurry up and get me 12-inch-tablets with 128+-core-gpu's and 5000Hz-refresh-rate input stylus's and army of accelerometer sensors in them, so i can CACKLE MANIACALLY laughing down at the PSP. actually i just want good rfid with a really good phased array, that'd be a much more "robust" sensor solution, albiet a little difficult to pull of technically.
i'm fucking so god damned tired of the fucking 3d printer stories. why the fuck would everyone need a cheap piece of shit desktop printer? i'd much much rather the 10,000$ office xerox thank you kindly.
i wonder how the developers feel about BGE's market performance. it was slightly broader target audience than most games, but still mostly a gamers game. great stuff though.
To the best of my knowledge, Torrenza is already implemented. The HTX port on many Opteron motherboards is a HyperTransport connection. You can already buy FPGA dev kits from U. of Mannheim that plug into this HyperTransport slot and interface with the rest of your system. Torrenza may continue to advance the HyperTransport / Coprocessor war, but as far as I'm concerned, Torrenza is already here.
In the mean while, the inquirer continues its series of posts of articles about external video card connections.
Me? I fly with proprietary fibre solutions! Well, I would if i were dirt rich.
Having your graphics display remote from the consoles they are attached to is absolutely amazing. I wish we could wire our entire office with decent thin clients.
I find in GoW there's occasional shit talking that sometimes degrades to racial remarks, either about the character model picked or picking on a players speech pattern. For the most part it is just stupid cunts to be ignored anyways, but it does show that race can have rather direct and immediate impact, particularly in multiplayer games.
So far the greatest way I've found to diffuse any tensions -- at least in Gears of War -- is to bring up the obvious issue at hand: dont be afraid of or pick on another race, if you're going to be phobic, be phobic of another god damn species. When someone starts saying "oh look a gook," to the guy that just chose the asian character, "oh look, a mother fucking alien" kinda adds perspective.
Wikipedia lists the following text in its "filing a dmca notice" section: "Reproduce the next statements: I have a good faith belief that use of the copyrighted materials described above on the infringing web pages is not authorized by my registered copyright and by the law. I swear, under penalty of perjury, that the information in the notification is accurate and that I am the copyright owner of an exclusive right that is infringed. Your signature"
Fuck yes. Sue the assclowns to kingdom come, and rob these robber barons to their grave. These guys are evil anti-humanitarian monsters.
the tooling is pretty extensive for AVR, and although somewhat windows biased is still competent in linux. defiantely a huge plus.
the other big plus is that the chips often have Read Only Memory with extensive functionality built in. in terms of startup, it can save a lot of effort; the uC will initialize itself for a variety of different modes.
MS Proprietary Cruft aside, Linux/OSS is actually a pretty terrible network citizen. Every package under the sun has LDAP integration, networking protocol support is extensive (so put it mildly) in the kernel, but integration... integration is awful. Theres no one to blame but Linux/OSS itself: the packages all have support for network protocols, but using these protocols requires extensive manual configuration. Dealing with configuration and deployment on any reasonable scale becomes very complex very quickly, and without truly expert help and continued extensive sheppardship, will result in persistent problems throughout network life.
Operations of linux in a network buisness environment is 100% reliant on proprietary RHEL and Novell voodoo, there's nothing freely available or open source for making huge numbers of linux machiens behave properly in a network environment. Its pure DIY, every step of the way, setting up Directory servers then painstakingly setting up every single god damned app and service to rely on the directory server. Linux is an OS with enormous networking support and no tools for utilizing it.
You point out there's many places linux cannot integrate for lack of consistent standards. I'm pointing out that in the places where there are consistent standards, utilizing these standards is an enormous task requiring careful configuration of a very large number of applications, and that these configurations are very difficult to perform accurately on any reasonably large collection of systems, which often require sublte tweaking per workgroup.
I am concerned about net neutrality. Quality VoIP and video conferencing requires low latency, and thats not typically available on the public internet. Paying extra for a low latency pipe seems valid to me. My understanding is that net neutrality would prevent this intelligent discrimination. No doubt, any slack in disciminating between users will be immediately exploited in terrible corporate ways, but principally i cant see how anyone could support enforcing a lowest common denominator upon everyone. Theres so much hype on this topic its really hard for me to figure out what is the regulation target and what the ramifications would be.
We had a software engineering & ethics lecture in our software engineering class back at uni. The nutshell of the opener was, every other engineering department has far better success/failure ratios, and its coders fault for being sloppy and not following proper practice. My first reaction was that every other engineering has tolerances built in, deliberate overcapacity. There's no such thing in software product, yet software is a very long chain/directed graph of co-reliant structures where a single failure will in most cases cascade out to mass system failure. Any tolerances or overcapacity is implicit in the development process, not so much the code itself (how exactly do you give code tolerance or overcapacity?), yet we're constrained to very serious deadlines. We're relied upon to produce large complex rube goldberg devices that function perfectly, you'd damned well better expect failure and a lot of it. The only compensation we have is culture and practice, to manage the process and the complexity both.
It'd be so convenient to say that programming is just spec writing and product development. The truth is much further out there though. 99% of the time the requirements are a moving target. That is one of the most important features of code and programming, its ability to be responsive. It'd be great if we could coax our clients into deciding what they want and then building it, but no matter how many spec processes we run through, the end product is invariably 50% spec at best, and 50% ad hocracy. Specs are not the only way to scope and define and manage complexity.
My other main gripe is that OSS has less than done nothing to build itself better coding environments. Past the compiler and the object, its hard to see real forward progress in managing complexity of code. The code environment we work in and the practice of coding is largely shaped by vendors, and they've been feeding us the same worthless excrement for years now, and no ones built a simple enough powerful enough comprehensive environment to demonstrate how much more natural programming should be (try as Smalltalk/Squeak might). I think vendors have added huge mental overhead to managing what is often a reasonable consumable chunk of complexity, and in many cases its deliberate. Its poisoning the entire developer gene pool. And no one is stepping up to make better coding environments, we're so busy building more crappy product with the existing tool set.
because you pussy fucking bitches eat the dog crap the vendors sell you. no one has gotten off their ass and made the infrastructure, we rely on re-implementing the awful cruft vendors excrete where we should be making distributed information spaces ripe for modification and mashup. the only ones defining rules and pushing outwards are vendors, and linux is left focused on pussy 1993 shit like making a nice pretty desktop and clean installers. fuck that shit, thats catching up, its old hack low level crap thats irrelevant to the information war taking place (xgl aside) and most importantly it will never play a single step in creating better technology. its pure implementation, no tool advancing. right now, the vendors are defining the verbose vicious hideous standards that will dictate the rules and ethics of our online existance. i blame all of you and your worthless desktop projects for not turning the internet into a viable medium. we need the compelling rich mashup based extensively hyperlinked peer to peer environment before coding becomes an act worthy of being done. right now we're coding in sludgepools, isolated little worlds that pull a couple libraries together to dredge up a single interface for a single user. its trash and its shite and it sucks because the environment sucks, the environment is literally 18 inches in front of you and no where else. code needs to get the fuck out of the constrained shit hole of the application and become mobile. across the network, code has a purpose. some day it will all be self evident, that the code sucked because the environment sucked. get the fuck off the desktop, start building something pervasive, and stop fucking wasting everyones time. before the vendors fill our gene pool with any more feces. i blame you all. you started an asymetric competition and then competed directly against the lowest common denominator available. the desktop is a worthless god damned endeavour.
go read Data Trash. figure out whats being said. and tell me we're not just the bitch of the corporations. AND THEN, after a little edumacation and contet, you can consider flamebaiting me.
The original plan for microkernels was to create more componentized runtime environments, so you could dynamically create virtualized OS's as a collection of the active componenets you needed. Very much like chroot, but pervading way beyond file systems and in to running libraries kernel modules and devices. The tooling was never here, but many people had stary eyes for esssentially a mix-and-match environment that would let you configure and cobble together operating environments at will, and maintain strong privledge seperation.
It really is a pity we gave the whole project up and decided to just implement YET ANOTHER page table in hardware, rather than try to solve the PIC code layout, IPC performance issues, and wrestle with building a new dynamical component based environment. I think we'd see virtualization on a much more pervasive level and a much stronger conception of mobile code, stretching all the way to embedded devices. As it is, the hardware virtualized environments are so insular from each other that there is a) no reason to run it on embedded systems (since integration is all application level, tracing through pretty meaty stacks) (watchdog systems aside) and b) it would impose colossal power consumption needs for mobile devices since it has to run each OS seperately.
Virtualization as we know it is a terrible terrible excuse for unix never having built itself a sufficiently dynamical and configurable environment. Two thumbs down. As cool as running multiple OS's is, it should not have been necessary in the first place.
the positional data is key. there's enough sig figs with a 64bit float that even if you are truncating a lot of the absolute positional data there's still enough sig figs remaining to keep accuracy.
furthermore, to say that 32bit fp per component rendered down to 32 bit color (24 bit actually, my monitor doesnt do alpha) is excessive is an egrigious lie. the 128bit wide drawing buffer contains far more information than the screen can display, yes, but the graphics card generates some kind of mapping that makes the best use out of that high precision information. 32bit integer color granularity is massively degrading: if you're in extreme darkness, visually discerning the difference between #000200020003 and #000300030004 is really hard. to make the difference noticable, the system might attempt to scale the color differences, quadruple the luminocity. in 32bit integer, we get #00080008000c and #000c000c0010, but nothing in between. with a floating point component system, there can be inherently a lot more information to work with. the screen can have a large number of shades of gray someplace between #000200020003 and #000300030004, and this extra precision can be translated with HDR mappings into better scaling. 32bit fp per component is the bee's knees; a huge part of modern video gaming technology is possible because of the enhanced precision.
on a stack based system, no application would ever require new registers. the new registers are simply a performance boost. then again, going from a pentium III to a 32bit mode opteron will also give you a performance/IPC boost. i'm trying to say its just a marginal factor, a performance feature just like any other hardware performance feature and not really worthy of being considered a new capability or functionality. i'm sure its well warrented in some places; i'd like to see some best case performance gains for some computationally intensive tight loops to give an idea of what kind or improvements are possible, but its simply not a significant difference.
otoh, limited addressability is hard fixed limitation with consequences beyond merely performance.
x86-64's main use is its address space. 32 bits places a 4 million word limitation on your addressing. systems like zfs that are heavily heavily transactional end up addressing a lot more objects than this. once you've breeched your 32bit addressing, the performance of native 64 bit addressing v. some kind of page extension mode is night and day. zfs's _need_ for x86-64 stems from this; it'll run on an "old" athlon, but in 64bit mode it flies.
my personal belief is that the future, the nebulous area Stroustroupe outlines as "better concurrency," is really going to be implemented at a platform level as this kind of deeply nested transactional data structuring, where instead of overwriting your object to change its state, you simply append the new state in a new part of memory. thus each object accumulates address space (referentiability) as it changes across time. i'll leave the full details implementation & ramifications of Copy on Update up to the user for now.
otoh, a lot of science people want double floats and 64 bit words, but look at the big boys, nvidia. it may bite them in the @#$@# someday, but for now they're sticking to a strong party line: 32bit floating point is sufficient. this works alright for video cards & games, since 4 channels of 32bit fp is an 128bit fp buffer. thats large, but still not entirely that accurate. i'd like to see a time when even game worlds are so massive they straight up require 64bit fp. i'd like to see nvidia release consumer cards with 64bit float performance sometime soon, but i dont think the odds of that happening are very big: its new technology with only a couple scientifc users making any use of it. just as it took the boys at Epic, Sweeny & CliffyB both stating the xbox needed more video ram, without vocal powreful demand we probably wont see it for a while.
hopefully we'll be doing more distributed dispatching with gpus in the future. 64 bit ints are going to be required there.
microdisplays have been available at 320x240 resolutions for a long time now. i'm just waiting for a res boost. however, given the long sordid history of microdisplays, i suggest you not hold your breath for product releases. place little faith in a press release.
Cool? Depends entirely on what Sony releases for dev tools. The odds of us getting OpenGL ES access is really low. The odds of us needing it are really high. I would love to be wrong about this, but I highly suspect the whatever tooling Sony bestows to the end user will be massively crippled.
DLNA would be sweet. UPnP Control over PS3 would be very convenient. I hadnt heard anything about this before.
I hope ATI still releases an Intel RD580 chipset. They are pretty power efficient and acceptable performers. I'm just waiting for one to get used in a small form factor system.
Uh, VMware was part of the the threat. Other considerations: 1. MS is giving their own vm software away for free now anyways. 2. MS was one of the original funders of Xen. 3. Xen can run Windows now anyways.
I dont think they're going back to Xen after all these years intending to kill the project they helped birth. Its not some old forogtten nearly aborted freak child. I think MS might be smart enough to realize Xen is the best virtualization technology out there, makes the most use out of existing virtualization hardware, and that perhaps they'd like to ally and borrow as much badass smoking paravirtualization as they can. In a world of increasing linux relevancy, MS would be happy to have one of your VM's be a MS VM, and they're realizing they should probably not fight that.
Affordable dual processor boards would be very tempting. Unfortunately, I suspect most will be gimped, and only have memroy and a northbridge hanging off one processor. A $250 dual processor board with a memory and a PCI 16x off each processor would have a huge impact on countering Inte's Duo2 strike.
Slashdot Mirror
psp is the only INTERESTING device out there because its the ONLY portable device with 3d capabilities AS OF YET.
p .org/psp/gl/</a>
*rabble rabble rabble*
Furthermore:
<a href="http://www.goop.org/psp/gl/">http://www.goo
<i>My goal with this library is to provide a efficient, useful and (relatively) complete subset of OpenGL which makes all the PSP's hardware abilities available, either through standard OpenGL mechanisms or with extensions.</i>
please go put that back in your mouth and go smoke it.
then wash that mouth out.
to everyone else, hurry up and get me 12-inch-tablets with 128+-core-gpu's and 5000Hz-refresh-rate input stylus's and army of accelerometer sensors in them, so i can CACKLE MANIACALLY laughing down at the PSP. actually i just want good rfid with a really good phased array, that'd be a much more "robust" sensor solution, albiet a little difficult to pull of technically.
yeah its frigging killing me. i'd be reselling the @#$# out of them if they had space. as it is, i cant even expand. :/
i'm not so sure why everyone bans irc clients though. it frustrates the living @#$@ out of me.
i'm fucking so god damned tired of the fucking 3d printer stories.
why the fuck would everyone need a cheap piece of shit desktop printer? i'd much much rather the 10,000$ office xerox thank you kindly.
dumb. shits. everywhere
i wonder how the developers feel about BGE's market performance. it was slightly broader target audience than most games, but still mostly a gamers game. great stuff though.
To the best of my knowledge, Torrenza is already implemented. The HTX port on many Opteron motherboards is a HyperTransport connection. You can already buy FPGA dev kits from U. of Mannheim that plug into this HyperTransport slot and interface with the rest of your system. Torrenza may continue to advance the HyperTransport / Coprocessor war, but as far as I'm concerned, Torrenza is already here.
In the mean while, the inquirer continues its series of posts of articles about external video card connections.
Me? I fly with proprietary fibre solutions! Well, I would if i were dirt rich.
Having your graphics display remote from the consoles they are attached to is absolutely amazing. I wish we could wire our entire office with decent thin clients.
I find in GoW there's occasional shit talking that sometimes degrades to racial remarks, either about the character model picked or picking on a players speech pattern. For the most part it is just stupid cunts to be ignored anyways, but it does show that race can have rather direct and immediate impact, particularly in multiplayer games.
So far the greatest way I've found to diffuse any tensions -- at least in Gears of War -- is to bring up the obvious issue at hand: dont be afraid of or pick on another race, if you're going to be phobic, be phobic of another god damn species. When someone starts saying "oh look a gook," to the guy that just chose the asian character, "oh look, a mother fucking alien" kinda adds perspective.
Wikipedia lists the following text in its "filing a dmca notice" section:
"Reproduce the next statements:
I have a good faith belief that use of the copyrighted materials described above on the infringing web pages is not authorized by my registered copyright and by the law. I swear, under penalty of perjury, that the information in the notification is accurate and that I am the copyright owner of an exclusive right that is infringed.
Your signature"
Fuck yes. Sue the assclowns to kingdom come, and rob these robber barons to their grave. These guys are evil anti-humanitarian monsters.
the tooling is pretty extensive for AVR, and although somewhat windows biased is still competent in linux. defiantely a huge plus.
the other big plus is that the chips often have Read Only Memory with extensive functionality built in. in terms of startup, it can save a lot of effort; the uC will initialize itself for a variety of different modes.
MS Proprietary Cruft aside, Linux/OSS is actually a pretty terrible network citizen. Every package under the sun has LDAP integration, networking protocol support is extensive (so put it mildly) in the kernel, but integration... integration is awful. Theres no one to blame but Linux/OSS itself: the packages all have support for network protocols, but using these protocols requires extensive manual configuration. Dealing with configuration and deployment on any reasonable scale becomes very complex very quickly, and without truly expert help and continued extensive sheppardship, will result in persistent problems throughout network life.
Operations of linux in a network buisness environment is 100% reliant on proprietary RHEL and Novell voodoo, there's nothing freely available or open source for making huge numbers of linux machiens behave properly in a network environment. Its pure DIY, every step of the way, setting up Directory servers then painstakingly setting up every single god damned app and service to rely on the directory server. Linux is an OS with enormous networking support and no tools for utilizing it.
You point out there's many places linux cannot integrate for lack of consistent standards. I'm pointing out that in the places where there are consistent standards, utilizing these standards is an enormous task requiring careful configuration of a very large number of applications, and that these configurations are very difficult to perform accurately on any reasonably large collection of systems, which often require sublte tweaking per workgroup.
I am concerned about net neutrality. Quality VoIP and video conferencing requires low latency, and thats not typically available on the public internet. Paying extra for a low latency pipe seems valid to me. My understanding is that net neutrality would prevent this intelligent discrimination. No doubt, any slack in disciminating between users will be immediately exploited in terrible corporate ways, but principally i cant see how anyone could support enforcing a lowest common denominator upon everyone. Theres so much hype on this topic its really hard for me to figure out what is the regulation target and what the ramifications would be.
I really like this, and think its pretty dead on.
We had a software engineering & ethics lecture in our software engineering class back at uni. The nutshell of the opener was, every other engineering department has far better success/failure ratios, and its coders fault for being sloppy and not following proper practice. My first reaction was that every other engineering has tolerances built in, deliberate overcapacity. There's no such thing in software product, yet software is a very long chain/directed graph of co-reliant structures where a single failure will in most cases cascade out to mass system failure. Any tolerances or overcapacity is implicit in the development process, not so much the code itself (how exactly do you give code tolerance or overcapacity?), yet we're constrained to very serious deadlines. We're relied upon to produce large complex rube goldberg devices that function perfectly, you'd damned well better expect failure and a lot of it. The only compensation we have is culture and practice, to manage the process and the complexity both.
It'd be so convenient to say that programming is just spec writing and product development. The truth is much further out there though. 99% of the time the requirements are a moving target. That is one of the most important features of code and programming, its ability to be responsive. It'd be great if we could coax our clients into deciding what they want and then building it, but no matter how many spec processes we run through, the end product is invariably 50% spec at best, and 50% ad hocracy. Specs are not the only way to scope and define and manage complexity.
My other main gripe is that OSS has less than done nothing to build itself better coding environments. Past the compiler and the object, its hard to see real forward progress in managing complexity of code. The code environment we work in and the practice of coding is largely shaped by vendors, and they've been feeding us the same worthless excrement for years now, and no ones built a simple enough powerful enough comprehensive environment to demonstrate how much more natural programming should be (try as Smalltalk/Squeak might). I think vendors have added huge mental overhead to managing what is often a reasonable consumable chunk of complexity, and in many cases its deliberate. Its poisoning the entire developer gene pool. And no one is stepping up to make better coding environments, we're so busy building more crappy product with the existing tool set.
because you pussy fucking bitches eat the dog crap the vendors sell you. no one has gotten off their ass and made the infrastructure, we rely on re-implementing the awful cruft vendors excrete where we should be making distributed information spaces ripe for modification and mashup. the only ones defining rules and pushing outwards are vendors, and linux is left focused on pussy 1993 shit like making a nice pretty desktop and clean installers. fuck that shit, thats catching up, its old hack low level crap thats irrelevant to the information war taking place (xgl aside) and most importantly it will never play a single step in creating better technology. its pure implementation, no tool advancing. right now, the vendors are defining the verbose vicious hideous standards that will dictate the rules and ethics of our online existance. i blame all of you and your worthless desktop projects for not turning the internet into a viable medium. we need the compelling rich mashup based extensively hyperlinked peer to peer environment before coding becomes an act worthy of being done. right now we're coding in sludgepools, isolated little worlds that pull a couple libraries together to dredge up a single interface for a single user. its trash and its shite and it sucks because the environment sucks, the environment is literally 18 inches in front of you and no where else. code needs to get the fuck out of the constrained shit hole of the application and become mobile. across the network, code has a purpose. some day it will all be self evident, that the code sucked because the environment sucked. get the fuck off the desktop, start building something pervasive, and stop fucking wasting everyones time. before the vendors fill our gene pool with any more feces. i blame you all. you started an asymetric competition and then competed directly against the lowest common denominator available. the desktop is a worthless god damned endeavour.
go read Data Trash. figure out whats being said. and tell me we're not just the bitch of the corporations. AND THEN, after a little edumacation and contet, you can consider flamebaiting me.
The original plan for microkernels was to create more componentized runtime environments, so you could dynamically create virtualized OS's as a collection of the active componenets you needed. Very much like chroot, but pervading way beyond file systems and in to running libraries kernel modules and devices. The tooling was never here, but many people had stary eyes for esssentially a mix-and-match environment that would let you configure and cobble together operating environments at will, and maintain strong privledge seperation.
It really is a pity we gave the whole project up and decided to just implement YET ANOTHER page table in hardware, rather than try to solve the PIC code layout, IPC performance issues, and wrestle with building a new dynamical component based environment. I think we'd see virtualization on a much more pervasive level and a much stronger conception of mobile code, stretching all the way to embedded devices. As it is, the hardware virtualized environments are so insular from each other that there is a) no reason to run it on embedded systems (since integration is all application level, tracing through pretty meaty stacks) (watchdog systems aside) and b) it would impose colossal power consumption needs for mobile devices since it has to run each OS seperately.
Virtualization as we know it is a terrible terrible excuse for unix never having built itself a sufficiently dynamical and configurable environment. Two thumbs down. As cool as running multiple OS's is, it should not have been necessary in the first place.
LordMyren
I'm saying that if you have a lot more information to start with, you can create a much better projection of that information into screen data.
m aging
http://en.wikipedia.org/wiki/High_dynamic_range_i
the positional data is key. there's enough sig figs with a 64bit float that even if you are truncating a lot of the absolute positional data there's still enough sig figs remaining to keep accuracy.
furthermore, to say that 32bit fp per component rendered down to 32 bit color (24 bit actually, my monitor doesnt do alpha) is excessive is an egrigious lie. the 128bit wide drawing buffer contains far more information than the screen can display, yes, but the graphics card generates some kind of mapping that makes the best use out of that high precision information. 32bit integer color granularity is massively degrading: if you're in extreme darkness, visually discerning the difference between #000200020003 and #000300030004 is really hard. to make the difference noticable, the system might attempt to scale the color differences, quadruple the luminocity. in 32bit integer, we get #00080008000c and #000c000c0010, but nothing in between. with a floating point component system, there can be inherently a lot more information to work with. the screen can have a large number of shades of gray someplace between #000200020003 and #000300030004, and this extra precision can be translated with HDR mappings into better scaling. 32bit fp per component is the bee's knees; a huge part of modern video gaming technology is possible because of the enhanced precision.
on a stack based system, no application would ever require new registers. the new registers are simply a performance boost. then again, going from a pentium III to a 32bit mode opteron will also give you a performance/IPC boost. i'm trying to say its just a marginal factor, a performance feature just like any other hardware performance feature and not really worthy of being considered a new capability or functionality. i'm sure its well warrented in some places; i'd like to see some best case performance gains for some computationally intensive tight loops to give an idea of what kind or improvements are possible, but its simply not a significant difference.
otoh, limited addressability is hard fixed limitation with consequences beyond merely performance.
x86-64's main use is its address space. 32 bits places a 4 million word limitation on your addressing. systems like zfs that are heavily heavily transactional end up addressing a lot more objects than this. once you've breeched your 32bit addressing, the performance of native 64 bit addressing v. some kind of page extension mode is night and day. zfs's _need_ for x86-64 stems from this; it'll run on an "old" athlon, but in 64bit mode it flies.
my personal belief is that the future, the nebulous area Stroustroupe outlines as "better concurrency," is really going to be implemented at a platform level as this kind of deeply nested transactional data structuring, where instead of overwriting your object to change its state, you simply append the new state in a new part of memory. thus each object accumulates address space (referentiability) as it changes across time. i'll leave the full details implementation & ramifications of Copy on Update up to the user for now.
otoh, a lot of science people want double floats and 64 bit words, but look at the big boys, nvidia. it may bite them in the @#$@# someday, but for now they're sticking to a strong party line: 32bit floating point is sufficient. this works alright for video cards & games, since 4 channels of 32bit fp is an 128bit fp buffer. thats large, but still not entirely that accurate. i'd like to see a time when even game worlds are so massive they straight up require 64bit fp. i'd like to see nvidia release consumer cards with 64bit float performance sometime soon, but i dont think the odds of that happening are very big: its new technology with only a couple scientifc users making any use of it. just as it took the boys at Epic, Sweeny & CliffyB both stating the xbox needed more video ram, without vocal powreful demand we probably wont see it for a while.
hopefully we'll be doing more distributed dispatching with gpus in the future. 64 bit ints are going to be required there.
lordmyren
by 2012 -- the end of time
microdisplays have been available at 320x240 resolutions for a long time now. i'm just waiting for a res boost. however, given the long sordid history of microdisplays, i suggest you not hold your breath for product releases. place little faith in a press release.
|| VooDoo
|
| Stop that.
| --
| Hail Eris, full of mischief...
You just earned yourself one Greyface cursing.
FUCK-ASS. Consider your banal ass cursed.
I had no idea perl6 was doing STM.a .htmll s/browse_frm/thread/8431e8ffbf74d77a/319b36760b1d5 a74#319b36760b1d5a74
http://pugs.blogs.com/pugs/2006/06/software_trans
http://groups.google.com/group/perl.perl6.interna
STM will kick your concurrencies ass.
Cool? Depends entirely on what Sony releases for dev tools. The odds of us getting OpenGL ES access is really low. The odds of us needing it are really high. I would love to be wrong about this, but I highly suspect the whatever tooling Sony bestows to the end user will be massively crippled.
DLNA would be sweet. UPnP Control over PS3 would be very convenient. I hadnt heard anything about this before.
Glad to see power consumption measured!
I hope ATI still releases an Intel RD580 chipset. They are pretty power efficient and acceptable performers. I'm just waiting for one to get used in a small form factor system.
-LM
Uh, VMware was part of the the threat. Other considerations:
1. MS is giving their own vm software away for free now anyways.
2. MS was one of the original funders of Xen.
3. Xen can run Windows now anyways.
I dont think they're going back to Xen after all these years intending to kill the project they helped birth. Its not some old forogtten nearly aborted freak child. I think MS might be smart enough to realize Xen is the best virtualization technology out there, makes the most use out of existing virtualization hardware, and that perhaps they'd like to ally and borrow as much badass smoking paravirtualization as they can. In a world of increasing linux relevancy, MS would be happy to have one of your VM's be a MS VM, and they're realizing they should probably not fight that.
2c,
-LM
Affordable dual processor boards would be very tempting. Unfortunately, I suspect most will be gimped, and only have memroy and a northbridge hanging off one processor. A $250 dual processor board with a memory and a PCI 16x off each processor would have a huge impact on countering Inte's Duo2 strike.