techMusings

I got a comment (anonymous.. please let me know who you are!) on the future of performance post.

sounds like you're advocating external co-processors... the kinds of processors he's advocating are more like Tensilica

I am advocating co-processors. In time the capabilities may merge with Van Neumann style chips, or at least be on the same die. Core's (since I don't *think* they do burnt chips) like Tensilica are useful, as are other hybrid designs like Stretch or even (eek, a static chip?) like Clearspeed or even the Cell. The last couple move the mainstream forward, but I think, to really harness app specific power a reconfigurable design will be needed.

The limitations with current FPGAs I'd say, are (for my apps) floating point support / capacity, the clock speed (let's get a 3GHz device - no, I don't really care about the heat coming out of it sometimes), and memory speeds. RAM running at serious speeds (there may be some), like nGHz, to match the chip speeds, will really blow the socks off the performance curves for a much bigger set of applications -- I'm talking Gigs of RAM not the little blobs on-chip in FPGAs.

The RAM speed is the most important one for adoption.

Just read this post from Greg.

He notes:

... [it's possible to] supply MethodConstraints to dictate what types of criteria the transport, invocation and client environments must meet to use the service. There are some interesting interactions here from the perspective that you can tell the invocation layer that your service needs to have a secure transport, with the endpoint implementation providing this guarentee. There are some interactions through the layers that make it possible for the question of "is this constraint met?" to be answered...

I'd like for service lookup results to allow the client software to query the service for its requirements so that a first time use of a service could allow the client to assert the required constraint implementations

So as per my previous post, the client could specify an ECMAScript implementation / data format. Assuming the server end can support the downloading of that language/service format, then any suitable javascript engine could process it -- implementation competition is then possible (obviously the script env would need to cope with the network layer, presumably via a native lib from the VM).

I got a comment, I think from Dan, on my last Jini post.

JAR caching:

It doesn't flush .jars of course and some of that is a core library issue (not specifically a JINI problem).

Afaik, using a different jar: url handler should be able to skip the default one and it's handling/caching. If, the core library (/Sun) can't be persuaded, then it's time for a Jini/OSS one to replace it. If a new handler can't be used to fix this, then Sun need to look hard at Jini support and fix this -- applet containers can do this today...

Discovery & other languages:

I'd be more tempted to go via the gateway route which can interface between other languages and Java. IMHO, it's probably not good practice to expose the implementation of detail of a service in the form of host requirements

Hmm, but for a given service, you don't want to have to create a gateway per service interface etc. I don't see why this can't be a standard field on an Entry -- open to interpretation by the node / filtered at the registry. The key thing is plug and play for other platforms -- there's no need for ANY java in the system if you remove the gateway.

Publicly known Jini impls:

"powered by JINI"

+1.

Via Tim Bray, Greg Matter nails the future of chip performance. As Tim said, he provides numbers to add to the argument.

Of course, while I agree with much of the article..

[the] first version of SPARC was constructed from about a 100,000 transistor ASIC. So today we could fit TEN THOUSAND of our original SPARC microprocessors on a single chip. That, gentle readers, is interesting.

...hmm, serious multi-core...

(Another consequence is that these complex microprocessors are, well, complex. That means more engineers to create the design, more engineers to test that the design is correct, and whole new layers of managers to try to coordinate the resulting hundreds and hundreds of folks on the project. Bugs increase, schedules are missed, and innovation actually decreases.)

...and difficult...

The result: microprocessors are dead.

Oops.

The secret ...[of the solution is]... more sane processor pipeline designs ... more conservative of ... power, and complexity. (A key innovation, however, was to finally fold multithreading into the individual pipes).

Cool, multi-threaded pipelines [my emphasis].

By 2010 microprocessors will seem like really old ideas. ... [In the future] the only place that computer design actually happens is by those who are designing chips. Everything downstream is just sheet metal. The apparent diversity of computer manufactures is a shattered illusion. In 2010, if you can't craft silicon, you can't add value to computer systems. You'd be about as innovative as a company in the 90's who couldn't design a printed circuit board.

I love the sheet metal comment.

I agree with the article though I don't think it goes far enough. Companies like Xilinx are pushing the whole notion of high level instructions or fixed pipelines by enabling fully custom chips. This is what we do. There is a storm coming, and I don't think it's from just multi-core chips.

<advert with="serious points">

With our software (because it is software written for a different layer, with different constraints), we have multi-core with serious hyper-threading, like dozens of them. This combines to give performance numbers which just blow away normal CPU-based systems. We can see real applications which will realise 100-1000x the performance of a typical Pentium/Opteron etc. More is possible with multi-chip in a single rack-based box (say, 2U) with lower power consumption.

While it's not as straight forward as standard software, the ease will come. It's possible today. Come talk to us.

</advert>

I believe custom pipelines, whether Cell, Cg/GPU or full FPGAs are the way things will go. The compilers aren't quite there yet, so it will take a while for the mainstream to adopt this. However, for certain applications, from seismic analysis, through telecoms and military real-time image analysis to financial analytics acceleration, massive benefits are available today.

So I'm not fully agreeing with:

[In the future] the only place that computer design actually happens is by those who are designing chips.

.. since I believe, like the previous wave and the one before, ultimately the compilers will embody amazing levels of engineering knowledge.

In the mean time, start your synthesis tools..

I recently receive an email from my bank, RBS, which looked pretty dubious.

Firstly, the "from" field contained: "RBS" -- a host that doesn't exist. it does also contain the line:

*This is an outbound message only. Please do not reply.*

which suggests that customer feedback is definately not wanted. I can understand they want customers to use certain channels to feedback through, but why not just send an automated reply giving phone numbers etc. It would then allow them to monitor how may people wanted to contact them via email / on the web -- it may be significant and an easy way to understand this.

I tried the above domain name, no website. I tried adding www, removing ccc and combinations. Nothing. This makes the email look like either spam or some sort of con / phish event. Both domains are registered to RBS but not having a web site makes it look dubious.

At the end of the email is:

How do I find out more details?
You can look at the full FAQ's on www.rbssecure.co.uk.

which, if you look at the link destination, goes

to:https://www.securesuite.co.uk/rbs/registration/welcome.jsp?partner=rbs.consumer

Another classic spam/phish tactic. Actually, going to the link text address (rbssecure) does bounce you to the latter. Sounds like the web admins, have never heard of mod_rewrite / ProxyPass. If this is real, then it should look real too.

Following the FAQ link, then seeing Contacts Us page, I thought I'd let them know that I had no idea whether to trust the email or not. There is only a phone number - 0870 010 4542, so I called... only to have the call dropped by the other end with no greeting or identification. Dubious, or simply poor?

As a last resort, I thought I'd detail it all here and let them know via other means (if I can find a way for them to actually listen).

# posted by Ken Horn @ 12:54 pm 5 comments

Dan posts on JINI wish lists and SOAP comparisons. Well, I've posted before about JINI here, so I've asked for a few things.

With my current interest in compute grids, there are a few things I'd ask for:

1. Sort out the class caching -- whether it's the JAR cache or the class loader, I want to be able to flush the classes used in compute nodes. No, I don't want to implement it myself, I want a standard mechanism (or a mature OS implementation). It could be automatic somehow (say, classid based), but a metadata driven option would be better (eg this job depends on lib version 2.3c).
2. Play nice with other platforms -- discovery is essentially a wire protocol, so where are the python, .NET, Ruby implementations? Build a JINI framework in the other langs, and provide some form of interop. On service discovery, declare the proxy's host requirement for the proxy -- this can include the implementation platform.
3. Demonstrate real systems using this. A single travel agent and an rfid system aren't enough. The core community needs to prove better, cheaper, lower risk systems before other people will jump in.
4. Again, keep lowering the barriers to entry, working examples (and simple ones), simplified config, example configs for typical projects. Books are useful -- you don't need a big publisher however, a small one will do, or a self-publish book.
5. Integrate with Spring, Globus, DataSynapse etc etc, integration is key. Make it easy to add it to an existing project, this lowers the adoption risk.
   

Well, I've been torturing myself by doing a bunch of web graphics with the Gimp. It's been the usual tale of usability nastiness and general loathing, however, I have to say I'm getting faster at the select, twist, shake, add a layer, blur, shadow, add two lumps of ice, crush, lather, rinse, repeat.

The somewhat dubious creations will be unveiled over at the next generation grid web site shortly. Basically the website was so ugly (created by me) that it was annoying me enough to self-baptise in the Gimp again. Oddly, the Gimp is like Perl for me, I only use it rarely so that I have to re-learn each time and since it's so unfriendly -- curiously Perl is the extension language of choice for the Gimp -- is the Gimp therefore the GUI alter ego of Perl?

With the apparent drive I heard of to improve the usability of the Gimp, what is the equivalent translation to compare with $) --> $CHANGE_INTRP_INV_13 ?

If anyone Gimp-like made it through that, here's my feature request / RFI: when I save a file, I'd like to retain the undo history. I realise that the file will be much bigger potentially (a limit may be nice too), afaict, currently, I have to choose saving endless snapshots (Save Copy) without undo between them. A second nice to have would be, in a similar vein, maintain a tree of states with navigation between them (in the same way a linear back/forward history stack in a browser is pretty limited).

Saw this again, thought I'd post it...