The clever boffins at Oxford University's Sub department of Particle Physics have written a pure Java x86 emulation environment with support for fully virtual peripherals.
I first came across this story on TheRegister
Obviously the sand boxing of the JVM makes this an ideal environment for testing "hostile" applications, Viruses and Honeypots etc.
The main thing I'm going nuts about is the speed. I'm tired of having the same old arguments with C++ coders. "Java is slow". Its just not. The hostspot (JVM) performs some amazing Just in Time compilation optimisations. Maths has not been slow on Java for a long time, FFT's are on a par with C++ speed wise now. Now I have an impressive benchmark to show alongside systems like Qemu and VMware. Unlike these systems though, JPC is fully platform independant and according the site hosted by the research team will run on any recent Java enabled device including mobile phones. Finally I can play my old dos games on my phone!
What I'm most excited about is the support for fully virtual peripherals. Working in my department means I am often exposed to new hardware and new protocols. The ability to prototype this interaction in a rapid development environment like Java could really improve the way peripheral protocols are designed in future.
The futures bright. The futures Java.
-Rob
*Yes* I realise I have become one of the accursed fan boys.
Showing posts with label Work. Show all posts
Showing posts with label Work. Show all posts
Tuesday, 27 March 2007
Bloody Hell, It works!
I worked late again last night, only till about 9pm but this time I was triumphant!
My distributed configuration application passed its first major test, grabbing the Front End Electronics configuration information from my central database, parsing it and rebuilding it and then pushing that data to two front end cards.
key: DCS:Detector Configuration System RCU:ReadOut Control Unit
Pre push latency:
2 seconds AFL start (Design constraint, I cant change this.)
0.5 seconds Database query. (This can be increased by a factor of 4 or 5 using prepared statements and 'views')
0.1 seconds Data parsing and rebuilding. (Taking data from the DCS Schema and putting into a useful state)
Push benchmarks
4.8 seconds to Push the 2096 (131 * 8 * 2) registers to the altros. (Via the RCU instruction memory)
8.9 seconds to Push the 2096 and perform 1 to 1 read write checks.
I think these figures can be greatly improved but based on these rough numbers I can estimate the time it will take to perform a whole Time Project Chamber configuration:
Presuming an average partition size of 18 Front End Cards per RCU that makes an altro push time of
4.8 * 9 = 43 seconds.
Due to the limitations of the Front End Cards and the power supply available at the pit the cards have to be stagger started sequentially, waiting 0.6 seconds per card:
0.6 * 18 = 10.8 seconds.
Total: 53.8seconds + unknown DB latency for multiple requests (est 3seconds);
In short, I think that we can confidently commit to having a full TPC configuration in less than 1 minute. The improvements to the RCU firmware should allow building of large instruction memory blocks for multiple register writes, this could improve the performance by a further 20-30% by my estimates.
In short, Woohoo!
My distributed configuration application passed its first major test, grabbing the Front End Electronics configuration information from my central database, parsing it and rebuilding it and then pushing that data to two front end cards.
key: DCS:Detector Configuration System RCU:ReadOut Control Unit
Pre push latency:
2 seconds AFL start (Design constraint, I cant change this.)
0.5 seconds Database query. (This can be increased by a factor of 4 or 5 using prepared statements and 'views')
0.1 seconds Data parsing and rebuilding. (Taking data from the DCS Schema and putting into a useful state)
Push benchmarks
4.8 seconds to Push the 2096 (131 * 8 * 2) registers to the altros. (Via the RCU instruction memory)
8.9 seconds to Push the 2096 and perform 1 to 1 read write checks.
I think these figures can be greatly improved but based on these rough numbers I can estimate the time it will take to perform a whole Time Project Chamber configuration:
Presuming an average partition size of 18 Front End Cards per RCU that makes an altro push time of
4.8 * 9 = 43 seconds.
Due to the limitations of the Front End Cards and the power supply available at the pit the cards have to be stagger started sequentially, waiting 0.6 seconds per card:
0.6 * 18 = 10.8 seconds.
Total: 53.8seconds + unknown DB latency for multiple requests (est 3seconds);
In short, I think that we can confidently commit to having a full TPC configuration in less than 1 minute. The improvements to the RCU firmware should allow building of large instruction memory blocks for multiple register writes, this could improve the performance by a further 20-30% by my estimates.
In short, Woohoo!
Monday, 26 March 2007
Late night randomness
Yet again I find myself unable to sleep and sat in front of my computer at god-knows-what past midnight.
So, its late at night and I'm sat in front of my computer, logged into a screen session at work via ssh and editing code. *Why?*
I think I have a bit of an obsession, at least with this current project, The deadline for integration testing is mid-April yet here I am, editing code, making sleepy mistakes and updating my blog!
In Gentoo related news, I actually got some work done today, I lurked on bugzie for a while, answered a few user queries and requested that a couple of packages get stabilised.
Slowly but surely I'm becoming more active in Gentoo as a whole rather than just the security stuff.
Well, time to try and sleep again I guess.
Salut!
So, its late at night and I'm sat in front of my computer, logged into a screen session at work via ssh and editing code. *Why?*
I think I have a bit of an obsession, at least with this current project, The deadline for integration testing is mid-April yet here I am, editing code, making sleepy mistakes and updating my blog!
In Gentoo related news, I actually got some work done today, I lurked on bugzie for a while, answered a few user queries and requested that a couple of packages get stabilised.
Slowly but surely I'm becoming more active in Gentoo as a whole rather than just the security stuff.
Well, time to try and sleep again I guess.
Salut!
Saturday, 24 March 2007
FEC2RORC Library
For those of you that are interested in what I have been doing at CERN, the documentation for my fec2rorc library is available on my webspace.
The reason for me uploading it to my website is that I get annoyed looking around the work servers for my documentation, particularly when I'm not at work! (Why I'm working from home, on a Saturday evening I have *no* idea).
Anyway....
http://www.brokenpipe.co.uk/fec2rorc.html
The reason for me uploading it to my website is that I get annoyed looking around the work servers for my documentation, particularly when I'm not at work! (Why I'm working from home, on a Saturday evening I have *no* idea).
Anyway....
http://www.brokenpipe.co.uk/fec2rorc.html
Subscribe to:
Posts (Atom)