rmac (+2.0)
23/8/06 3:20AM |
Several questions spring to mind:
How feasible will it be to utilise these in a RISC OS desktop environment?
How soon will the chips be available?
How long before they make it to our market if the answer to Q1 is positive?
Here is hoping the answers to all questions lead to a positive outcome for RISC OS. |
7thsoftware (+2.0)
23/8/06 3:30AM |
Hmm. Tastey! I'm sure you could devise an API to farm-off time-consuming tasks to the second core... of course, your software would then have to allow multitasking to continue while it waits for the results. |
gdshaw (+2.0)
23/8/06 5:30AM |
Particularly attractive is the fact that this would be a worthwhile upgrade even if one of the cores were left idle (as it probably would be at first). That gives it a chance to achieve a large enough installed base to make the necessary software enhancements viable. |
lostamarble
23/8/06 7:50AM |
so how old is the ARM11MP ? (ok synthesised multi core, but in the market a lot longer than anybody elses multi core options). [Link: www.arm.com]
Just odd that we all get excited over a paltry two cores now. Must be the 1GHz thing that is news here  |
timephoenix (+2.0)
23/8/06 8:59AM |
Wow, great news! Dual Core, 512MB L2, DDR2 RAM, PCI-Express... if an Iyonix II was released tomorrow we'd finally be reasonably close to the x86 pack. The disappointing thing is that by the time an RO machine actually gets to market with these specs, they will (again) be old hat. Still, a good development if the RO market can make use of it.
Is this processor actually available in large quantities yet? When ARM announces a new chip it normally takes 3 years or so to make it to market.
|
piemmm (+1.0)
23/8/06 9:12AM |
I'd love a 512MB L2 cache in my processor. bet it's really only 512K though  |
Gulli (+2.0)
23/8/06 9:13AM |
So, how much redesign would the Iyonix need to use this chip? |
tribbles2
23/8/06 9:20AM |
In reply to piemmm:
Who'd need main memory with 512M L2? |
JGZimmerle
23/8/06 9:44AM |
@timephoenix: How would we be reasonably close to the x86 pack? A single-core ARM offers about half the integer performance of a AMD or Intel x86 single-core at the same clockspeed. I guess the same is true for dual-core versions. Current dual-core x86 offer clock speeds of up to 3.8GHz. That makes current x86s about six times as fast as this future ARM for integer performance. But this ARM will probably once again have no FPU and no general-purpose SIMD extensions, making it abysmally slow in comparison for many applications.
For storage controllers a cache of 512MB might actually be quite useful (my current ICP Vortex SCSI controller has 256MB RAM on it), so I would not rule it out that this chip might actually support 512MB external 2nd level cache. |
druck (+1.0)
23/8/06 9:59AM |
If the IOP342 contains all the peripheral features of the current chip, which it seems to, then only there would only need to be a redisgn for the differing package layout, plus of course any other changes such as an updated southbridge which would be needed. The seperate flash to hold the ROM could be deleted as it has 32MB on board.
The 1.2GHz clock speed increment combined with the Level 2 (undoubtedly only 512K) would give a substantial speed boost over the IOP321. The 1MB of internal memory could be used to hold critical parts of the OS for further performance gains. This just may hit the 3x tipping point for Castle to consider an Iyonix Mk2.
Thats only considering single core perforamance of course, as currently RISC OS has no facilities to make use of multiple processors. How to utilise the 2nd core would be the big question, symetric multi-processing is obviously not feasible with a CMT OS model, but farming out certain operations which could run in parallel such as I/O handling, graphics rendering and sound synthesis would be possible.
It unlikely Castle would have the resouces to serious tack this, so it would be the ideal case for open sourcing some/all of the OS, as it would allow developers to tack managable chunks of work. As long as the OS establishes a frame work for mutlicore use, operations could be migrated over from the primary processor in a piecemeal fashion. |
knutson (+2.0)
23/8/06 10:00AM |
Regardless of whether RISC OS would use the second core, if the XScale is clocked at 1.2GHz it will be a good jump up in performance.
|
highlandcattle (+2.0)
23/8/06 10:07AM |
This looks promising indeed |
RichardHallas
23/8/06 10:10AM |
For handling the second core, I wonder if the API for Simtec's Hydra card could be adapted/adopted. The Hydra multi-processor card for the RiscPC did go into production a decade or so ago, though the StrongARM came along soon afterwards and pretty much eclipsed it in terms of potential performance gains. I'm not sure how much (if any) software was actually updated to take advantage of the Hydra. |
timephoenix
23/8/06 12:02PM |
In reply to JGZimmerle:
Oh dear, I really did make a mash of that last post in my pre-work haste. What I really meant to say is that at least we would be making ground on the x86 pack, particularly in the area of supporting modern PCI-X expansion and DDR2 RAM and a limited performance improvement (certainly not matching, by any means). When simple tasks on the Iyonix such as burning a DVD takes 80 minutes, I'm willing to take anything!
"Who'd need main memory with 512M L2?"
Aaah, that day will come one day, I guess |
JGZimmerle (+1.0)
23/8/06 2:03PM |
A cache can not be used as a replacement for main memory.
I think the most important new feature of the new chip (apart from higher clock-speed) is the PCIe-support. This would finally enable us to use modern GPUs and fast, low-latency transfers from the GPU to the CPU. |
hubersn (+1.0)
23/8/06 2:15PM |
The reason that burning a DVD takes 80 minutes on an IYONIX is that CD devices are talked to via PIO mode 0. If this was upgraded to UDMA33, we would be on par with x86 PC performance. Remember the massive performance boost when HD access was UDMA'ed back in 2003?
Steffen |
snapper (-1.0)
23/8/06 4:43PM |
Forgive me, but it's been a while since I looked at CPU architecture but why can't you use cache,at least for the most part, in place of system RAM?
Things are a little foggy but I seem to recall that instructions and data are loaded into RAM then the required instructions and data are loaded into cache and only knocked out of cache when something else needs the space ( determined by some algorithm ). If there is no need to replace the data / instructions, then why is it not possible to run at least a basic system with cache only?
What sort of data can only reside in RAM and if it has to be in RAM is there a problem with it in cache or does the CPU bypass cache completely? Or is it that the OS would require a drastic rewrite to achieve such a thing? |
druck (-1.2)
23/8/06 5:03PM |
In reply to snapper:
ask that on the newsgroups, its too involved to enter in to in comments. |
egel (+1.0)
23/8/06 5:07PM |
In reply to RichardHallas:
Or the second core (first) just as FPU |
adrianl (+1.0)
23/8/06 5:10PM |
Data that needs to be accessible to I/O hardware such as DMA controllers might need to reside in main memory as opposed to L1/L2 cache, it depends upon the architecture. Likewise, for some systems you can just use cache memory as a replacement for main memory. In fact the XScale core used in the Iyonix allows you to do exactly that. You need to write some special code to allocate the cache lines to the addresses you want your 'pseudo-RAM' and then lock those lines in the cache. Hey presto, very fast RAM that makes all other memory accesses that little bit slower by reducing the amount of cache space available to them |
snapper (-1.0)
23/8/06 5:27PM |
Thanks fo that |
dms
23/8/06 5:41PM |
If you look at the details here [Link: www.em.avnet.com] not only does it confirm that the L2 cache is 512 MB (not 512 kB) as some have speculated, but this is per core. In other words, there is 1 GB of on-chip RAM. It also explicitly mentions the possibility of using this in place of external RAM in some applications. |
dms
23/8/06 5:44PM |
OK - the information in the link I just posted may be wrong, because although it does talk about dual 512MB L2 caches, it then talks about 1MB of on-chip memory. This may be the original source of confusion. |
Jwoody
23/8/06 8:05PM |
The referenced web site talks about upto two cores and mentions one or two so it looks like one will be able to buy single core chips which would solve what to do with the xtra core and Risc OS |
JGZimmerle (+1.0)
23/8/06 9:53PM |
I think the 512MB 2nd-level cache would probably be off-chip. |
Cogs (+3.0)
24/8/06 12:20AM |
In reply to egel:
"Or the second core (first) just as FPU"
If you mean via a modified FPEmulator I think any theoretical benefits would be non-existant in practice. Farming off individual instructions from one core to another identical core is pointless. Even if you let the first core continue while the second completes a calculation, the amount of useful integer code the first core could complete before it stalls due to a data dependancy is likely to be less than the overheads in getting the two CPUs to talk to each other in the first place. Even if they communicate entirely on-chip.
To benefit properly from a dual core CPU in RISC OS, apps will need to be multi-threaded and processing split between the two cores by some kind of threading system designed specifically for that purpose. If the code contains floating point calculations, both cores will have to either use FPEmulator or a floating point library. |
AMS
24/8/06 4:17PM |
Again good news.
With a larger 512KB cache and 1MB of on chip RAM (not to mention higher clock speed) I could forsee the performance being better than x3 times the Iyonix CPU's performance. As to using the second processor I am sure that some tasks could be "offloaded" to it. Even if that were not the case - just having one CPU at 1.2GHz with that extra cache would still make it worthwhile doing.
Not so bad for a family of chips some pundits pronounced as dead is it ? |
harmsy
24/8/06 5:59PM |
Gosh, this would be nice! My problem is that my nearly decade old (although seriously upgraded) SA RPC is more than enough for my needs. A 1GHz Iyonix would change my mind there... |
Jaco
25/8/06 3:50PM |
If at some point the OS will be changed to take the benefits of the dual core we could go a step further and put more than one processor on a board.
As I understand ARM based processors are not expensive so why not use that? |
Gollum
25/8/06 4:28PM |
Is there someone around who knows what the new 1.2 GHz XScale CPU will cost? |
| Use the forum for more comments on this article |
A new dual-core 1.2GHz XScale processor is expected to be showcased at this autumn's Intel embedded roadshow. The conference, due to run in North America from September to November, will include 