Slashdot Mirror

"Multi-Core technology is good for desktop systems as it is meant to run a lot of relatively small apps Rarely taking advantage of more then 1 or 2 cores. per app.In other-words it allows Multi-Tasking without a penalty. We don't use super computers that way. We use them to to perform 1 app that takes huge resources that would take hours or years on your PC and spit out results in seconds or days."

Sorry but that's not entirely correct, most super computers work on highly parallel problems using numerical analysis techniques. By definition the problem is broken up into millions of smaller problems that make ideal "small apps", a common consequence is that the bandwidth of the communications between the 'small apps' becomes the limiting factor.

"Back in the early-mid 90's we had different processors for Desktop and Super Computers."

The earth simulator was refered to in some parts as 'computenick', it's speed jump over it's nearest rival and longevity at the top marked the renaissance of "vector processing" after it had been largely ignored during the 90's.

In the end a supercomputer is a purpose built machine, if cores fit the purpose then they will be used.

"I'd also be looking as seriously parallel processing."

If you haven't seen this it might interest you. Note that it's a simulation for use in studying the physiology of the mammalian brain, not an AI experiment. Any ghost in the machine would have to emerge by itself in pretty much the same way mind emerges from brain function.

with some experts now believing general AI to be attainable within the next decade.

I think the next decade is a little ambitious. The problem is the amount of space required to store the data, which is probably hundreds or even thousands of petabytes.

For example, take the human brain. It's believed to only have about 100 billion neurons, but there are between 1 and 10 quadrillion synapses (~10 for children and between 1 and 5 for adults).

Whether it's biological or software, it'll require roughly equivalent complexity to create a brain as intelligent as a human brain.

Thousands of petabytes might be available for supercomputers in 10 years, but that volume of storage probably won't be more generally available in 10 years.

And to make the brain think at a speed within an order of magnitude or two of a human, you need to be able to process each "neuron" probably about 100 times per second (based on projects like BlueBrain)

That kind of processing power is probably at least 20 years away.

But otherwise, I agree, this is almost definitely on the horizon. I don't think a generalized ANN like the ones you're talking about will be the way it's done. I think something more akin to Blue Brain, which simulates real neurons is more likely to be where the first intelligent, sentient software will emerge.

Your class can't be used concurrently, because Ruby is not actually SMP-capable.

But JRuby is.

I should note that, in a simple test, Erlang got about three times slower when I enabled SMP mode.

JRuby is a non-standard Ruby implementation. From their feature list: "Most builtin Ruby classes provided". Emphasis mine. Additionally, see below why support for OS threads isn't enough to implement M:N actor:thread scheduling.

As for Erlang SMP speed -- first, they implemented SMP support. Then, they started to optimize it -- It has the architecture necessary to improve performance. Ruby, in contrast, still has a GIL, which means every single component and extension will need to be reviewed for thread-safety before the GIL can be removed (which means, never).

It can't be used on multiple systems, because the messaging can't be used across nodes.

Except it can, with DRb. Which also provides sloppy SMP support -- just run two nodes on the same machine.

How many "nodes" are you going to run on the same machine? Each ruby process consumes a great quantity of resources, the elimination of that resource drain is the entire purpose behind Erlang's tiny-stack microthreads -- they consume very few resources, so you can have a great many of them.

Single-machine, non-concurrency queue-based message passing systems are what we usually call "linked lists".

Erm, what? I know what a linked list is, and I don't see the comparison.

You've created a dead-simple message queue based on delivery of messages to a thread-owned linked-list. Erlang implements externally scheduled pattern-based actor message delivery, using thread-scheduled microstacks to allow for an enormous number of concurrently deliverable processes. One key element of these implementations is that they do NOT consume a thread per actor. Since you're so up on JRuby, I recommend Philipp Haller's papers on his actor library for Scala.

Assuming the implementation of thread-scheduled actor message delivery in Ruby (rather than JRuby), you'll still be stuck with the GIL, making the whole exercise, well, moot. If you use JRuby, you still don't control scheduling of microthreads, leaving you with 1:1 correspondence between an executing actor and a real thread, whereas Erlang is capable of maintaining M:N scheduling of *executing* actors to real threads.

This M:N correspondence truly matters -- without it, blocking operations inside of an actor mean that the entire thread is blocked and useless for other purposes. It's not possible to implement the M:N model without control over your execution stack, which means true microthreads are unimplementable in both JRuby and Ruby.

DRb is just another RPC implementation.

...and Erlang's RPC isn't?

No. RPC is a limited form of message passing -- RPC is something you build ON TOP OF the message passing model. If you skip the "message passing" step and go straight to RPC, you wind up with something that ignores the complexity of the network -- the network fails, messages get lost, dropped, or ignored. Given this ignorance of the medium, RPC interfaces assume synchronous message delivery and response, which then precludes asynchronous delivery and response.

In erlang, processes and (immutable) messages are first class entities, whether they're operating locally or remotely.

Again, I have to go, "huh?"

DRb allows objects to be created and "passed" between the machines. I could do:

remote_object = DRB::whatever remote_object.some_method :arg1, :arg2 ...

How is this different than Erlang's PIDs, other than being syntactically cleaner?

Scala has actors, which are allow you to do something _like_ green threads: http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html

Take a look at the project http://bluebrain.epfl.ch/

This is very exciting as it could point to a future where you can literally hack your own brain.

Do you have a backup?

According to their website, MIT's tuition is 35K/yr + 10k in housing.

go to a good community college for the first two years, transfer, and still get that MIT degree

A friend of mine works on this:

http://youtube.com/watch?v=5Tq8dgVZLmI

http://birg.epfl.ch/

we'll have no way to configure the linking and weights of those neurons [...] It's just too complex

The blue brain project is already simulating a cluster of 10,000 neurons known as a neucortical column. Althought quite good already (in terms of biological realism), their simulation model is still incomplete with a few more years work to get the neurons working like in real life. With more computational power to increase neuron count and better models they will be able to one day simulate an entire mammalian brain.

from what i understand of this project there modeling this at a cellular level, which i would assume would include all the major ion channels and other big biological factors that would effect the system.

http://bluebrain.epfl.ch/Jahia/site/bluebrain/op/edit/pid/19092

"This type of research is cool, but neuroscientists generally aren't impressed until results can be reproduced in a living system."

The first sentance from TFA: "In a laboratory in Switzerland, a group of neuroscientists is developing a mammalian brain - in silicon".

Further down it says "...and it [the rat brain part] behaves exactly like its biological counterpart. It's something quite beautiful...

Now tell me how you can possibly "reproduce it in a living system", isn't it the whole point of any simulation to reproduce the system under study?

"Most of the models make lots of assumptions that may or may not hold true in the actual biology."

In the eighties when I hacked away at my own simulations for fun this was true, the reason was only computer science types understood how to implement the concept, however we CS types had only a minimal understanding of neuroscience (if any), not to mention many CS types loath testing and documentation. This particular project is however a well funded marriage of CS and Neuroscience, personally I think their claims are credible for two reasons, first the people making the claims are neuroscientists, second they are supported by IBM who have a good track record when it comes to goal orientated research.

Besides, CS has a concept called "black box testing", it tells us that if the model "behaves exactly like its biological counterpart" it doesn't matter how the internals of either bring about the behaviour.

Adding a microphone/camera and transmitter to the "Moth" sized microflyer (video available) noted in the article might be possible, but your flight time is going to suffer and be in the tens of minutes... not very useful right now or at least until battery efficiencies improve.

Some of the micro-flyer tech. from the noted Flying Insects and Robots Symposium is pretty slick as well. I especially like the Flapping-Wing MAV with a single fixed wing and dual flappers than creates a pseudo-ground effect to fly more efficiently/stably.

Lastly, considering the Blackbird (high altitude/high speed) and stealth technology that the government started developing all the way back in the 1970's for goodness sake, you really need to push the imagination to honestly even guess at what they might be working on currently.

International Symposium on Flying Insects and Robots: http://fir.epfl.ch/monteverita.html
Insect size flapping MAV (Japan): http://www.fit.ac.jp/~y-kawa/

Great stuff, hardly news though, it just seems like the same thing as some Swiss lab has been working on for years.
Publications: http://isic2.epfl.ch/page58678.html
Some press coverage: http://www.sciam.com/article.cfm?chanID=sa025&arti cleID=0002C2E1-17B2-1508-97B283414B7F0000
Products?: http://www.solarisnano.com/solarenergy.php

You and the parent might be interested in Scala:

http://scala.epfl.ch/

Hybrid OO/Functional language that compiles down to JVM and CLR bytecode. It supports operator overloading as well as a lot of other cool things. There are even Eclipse and Emacs plugins for dev work :).

Derek

I'm not sure if the first link is correct -- it isn't a research paper, just an intro-level lecture to integrate-and-fire models, one of the topics covered in computational neuroscience. The actual research paper by Earnshaw & Bressloff requires a subscription, but here's the abstract:

Biophysical Model of AMPA Receptor Trafficking and Its Regulation during Long-Term Potentiation/Long-Term Depression

AMPA receptors mediate the majority of fast excitatory synaptic transmission in the CNS, and evidence suggests that AMPA receptor trafficking regulates synaptic strength, a phenomenon implicated in learning and memory. There are two major mechanisms of AMPA receptor trafficking: exocytic/endocytic exchange of surface receptors with intracellular receptor pools, and the lateral diffusion or hopping of surface receptors between the postsynaptic density and the surrounding extrasynaptic membrane. In this paper, we present a biophysical model of these trafficking mechanisms under basal conditions and during the expression of long-term potentiation (LTP) and depression (LTD). We show how our model reproduces a wide range of physiological data, and use this to make predictions regarding possible targets of second-messenger pathways activated during the induction phase of LTP/LTD.

Computational neuroscience is a great topic. If you're interested in learning more about it, there's a nice book by Gerstner & Kistler called Spiking Neuron Models, which can be purchased hard-copy or downloaded for free online. The wikipedia page is also pretty good, with plenty of links to fun neural simulation software.

(And yes, I Am A Computational Neuroscientist... or at least I'm in a computational neuroscience grad program ;)

• Possibility to a certain degree of working at home through the use of TV-telephones, telefaxes, etc. (forecast: 1998)
• Acquisition of observation data from unmanned probes around Uranus, Neptune, Pluto and outside the solar system. (1999)
• Development of optical communication technology that can realize substantial savings in the use of copper. (1999)
• Possibility of external fertilization or artificial womb. (2001)
• Widespread use of heart transplant from human being by resolving problems such as transplant immunity, rejection and donor. (2001)
• Practical use of rapid-transit railway using iron rail and iron wheel, which can run at 300 km/h. (2006)
• Development of artificial ear. (2007)

• Possibility to a certain degree of working at home through the use of TV-telephones, telefaxes, etc. (forecast: 1998)
• Acquisition of observation data from unmanned probes around Uranus, Neptune, Pluto and outside the solar system. (1999)
• Development of optical communication technology that can realize substantial savings in the use of copper. (1999)
• Possibility of external fertilization or artificial womb. (2001)
• Widespread use of heart transplant from human being by resolving problems such as transplant immunity, rejection and donor. (2001)
• Practical use of rapid-transit railway using iron rail and iron wheel, which can run at 300 km/h. (2006)
• Development of artificial ear. (2007)

• http://www2.epfl.ch/Jahia/site/uneedip/op/edit/pid /11703 (french only)

Stefano Nolfi's team (responsible for the research in TFA) usually come up with very solid and ingenious research, and the project mentioned is a continuation of a large EU-funded project with interesting results. But it should be remembered that this research is quite far from any actual applications, in large part because people schooled in classical engineering instinctively distrust anything that has been "evolved". Understandable, as there is often no way to tell why the evolved AI is doing what it is doing, just that it is doing it, and no guarantees that it will continue doing it when you need it the most. Sometime in the far future, however, I believe artificial evolution might be the standard way of creating control and intelligence for various purposes.

Perhaps Web 2.0 is tired?

No, PHP is tired. It's now all about Ruby, Python, LISP, and the more obscure but no less interesting Lua, Scala, Qi, OCaml, among others, and various derivatives and frameworks.

Unfortunately, I didn't use Nice so far, so I can't comment on speed. However, I can't say Scala code was too slow, except maybe for the compiler :-). Although Scala has no 'nullable' types as Nice, they can be emulated using the Option class (heavily used in the library). For the latter point, indeed, Scala can not inject methods into existing classes, but up to a point, they can be achieved using views.

An interesting comparison between Nice and Scala can be found here although it might be out of date (it considers Scala 1.0, while Scala 2.1 has been released recently).

Scala is a language that targets the JVM and nicely fuses the object-oriented and functional programming paradigms. It is statically typed, has closures, a powerful collections library, integrates perfectly with Java (all Java classes can be imported 'as-is' in your program), pattern matching, and much more. See also the discussion on Lambda the Ultimate.

There is a really nice Scheme interpreter on the JVM called SISC:

http://sisc.sourceforge.net/

IMNSHO Scheme is so much nicer than Python et al that there's not even a decision to be made here as far as dynamic languages on the JVM.

There's also Scala, which is another statically typed language on the JVM. It is SORT of like Java, and can use Java classes natively, but is about 20 times more pleasant to use than Java (if you're into higher-order functions and pattern matching and that kind of thing... but then, everyone should be into that stuff). Anyway, Scala isn't a scripting language, but depending on what you're planning on doing, using it may persuade you that you didn't actually need a scripting language, you just needed a language that wasn't painful to use like Java is.

Scala:
http://scala.epfl.ch/

http://lis.epfl.ch/index.html?content=member.php&S CIPER=111729

Click on projects

The new achievement -- temperatures of billions of degrees -- was obtained in part by substituting steel wires in cylindrical arrays 55 mm to 80 mm in diameter for the more typical tungsten wire arrays, approximately only 20 mm in diameter. The higher velocities achieved over these longer distances were part of the reason for the higher temperatures.

(The use of steel allowed for detailed spectroscopic measurements of these temperatures impossible to obtain with tungsten.)

As one might expect they actually publish in electron volts (eV) which is probably also used internally. This is very convenient for lots of eksperiments in solid state physics, particle physics and apparently here. I don't see why they shouldn't convert to more widely (mis?)understood units when they write for public consumption. That the american unit system needs fixing badly is another discussion.

FYI room temperature is about 25 meV. Since eV is an energy unit (the potential energy of an electron lifted 1V) you need to convert back and forth with Boltzmanns constant.

In particle physics masses of particles are measured in eV, here the famed E = mc^2 is used implicitly.

The paper with the proposed model explaining these findings is available here for anyone that can understand it. They refer to instabilities (of the Rayleigh-Taylor kind?) causing ion viscous heating as they are dissipated. When an array of wires is heated and implodes, most of the content of the wires remain unmoved at the beginning, with only the outer parts being converted to plasma and moving toward the center. The inner left-overs are eventually converted as well and make the trip, though not necessarily until after the peak energy radiation.

Very interesting post!
I haven't touched eiffel since early 90s so I can't give a fair comparison. In regards to my wide-ranging research on choosing a programming language for my current work, I didn't consider eiffel too strongly as I am drawn more to dynamic typing or at least strong type inference (see scala, http://scala.epfl.ch/ ). I realize that dynamic typing generally makes it more not less difficult to deliver a provably correct system. erlang takes a unique approach to this by the way it handles errors. The programmer is encouraged to not program defensively and to let the erlang system handle errors for anything the programmer did not explicitely expect. This is a unique approach and when tied to a dynamic language seems to work well.
I find great qualities in many programming languages. Ruby, Python, Java, Smalltalk, C++, Haskell, OCaml all have their place from a language perspective.
However, I wanted more than a language but a complete system with distribution, database, web server, fault-tolerance all built in.

So far as langugage design goes, I am very found of scala. The team behind scala created a syntax that melds pure objects, pure functions and type inferencing without clutter. A remarkable acheivement. However, scala is so new that it has few of its own libraries. I was tempted to embark on creating the frameworks/libraries I needed for scala, but I wanted out of the framework business. Erlang has an evolved syntax and is not without its quirks and inconsistencies. I have been able to put my purist attitude aside by being grateful for the comprehensive system it provides.

I can tell you this: What initially attracted me to erlang was the ejabberd project http://ejabberd.jabber.ru./ ejabberd has most of the qualities of the type of software I expect to build. This includes massive concurrency, security (in the form of process isolation and shared nothing data structures), fail-over/distribution, multi-database support, html templating for the web ui. ejabberd accomplishes this with a much smaller code base than comparable Java solutions. After studying the ejabberd product, I started to take erlang more seriously...the rest is history.
I recently completed my first large project for a customer using erlang (including the latest ajax stuff) and have received most of the benefits I thought I would receive.

BTW, I have been living in Shanghai since 2000 and have found the pimsleur madarin tapes to be the best. Yes, a different approach can mean so much more than just more content.

good luck...

While there are no estimated timescales here, beyond simulating a neocortical column in two - three years, I would expect to knock a few decades off of your estimates if the project is a success. This is one of the most interesting research projects that are using the latest Blue Gene hardware. Another factor that will make these results occur at an earlier date than expected is the aspect of simulation speed. To get interesting results froma simulated brain would not require a 1:1 ratio between simulation speed and reality. These structures could be simulated at a much slower rate whilst still revealing information about how they work.

I just googled for a Haskell implementation in Java.

The nearest thing to Haskell in Java that I've heard of is Scala.

Absolutely. All I get concerned about is the idea that because some projects are far faster with Ruby alone or with Rails, then this is a general advantage that this sort of development technique will have over Java in all circumstances for all scales of project.

Ah, well, we're in agreement there! I'm a firm believer in using the right tool for the right job, and as you say, sometimes Ruby isn't the right tool for the job. Java does have some neat libraries and APIs, and alternative languages for the JVM like Nice, Groovy or Scala, can make one's life quite a bit simpler. You also get the performance advantage, which is always nice.

Where I am it is time to say Merry Christmas!

Here too. Merry Christmas! :)

I think this may be an issue with size of codebase: you claim you'd look at pmd, but wouldn't it be easier just to check by hand. To which i'd say: not in 40,000 source files, no it wouldn't. When I first ran PMD against our 40,000 source files I turned up four bad semi-colons, three of which were real bugs (one had no side effect).

Probably. Generally the projects I've been involved in have between 10 to 300 source files. I'd be rather hesitant about using Python for a project that needed 40'000 source files! I might be tempted to try Scala for such a task.

Some of the replies below comment on the operations-per-second estimates of the brain, so I won't. There is, however, a really interesting project at the Brain Mind Institute in Switzerland to simulate, in large detail, a full neocortical column of the brain on several BG/L racks, donated by IBM for this cause. As a consequence, this project is called the "Blue Brain Project", and you can read a bit more about it here:

IBM
http://domino.research.ibm.com/comm/pr.nsf/pages/n ews.20050606_CognitiveIntelligence.html

New Scientist
http://www.newscientist.com/article.ns?id=dn7470

Main site (which doesn't seem to be working at this moment!)
http://bluebrainproject.epfl.ch/

In addition to all the lovely foss for windows, the only closed source program I ever recommend is nLiteXP . You basically copy your XP disc to a directory, and then sick nLite on it. It extracts the cabs and can really neuter it (Highly customizable with a slick GUI) and you can get your default XP install from ~2GB down to 400MB highly usable. Less if you wanted. nLite will make a new iso file that can be customized for auto install and service pack slipstreaming and driver install, all sorts of nifty things. You burn that and install.

So basically, you can have 350MB of core windows XP and another 500MB of the best FOSS for windows. A highly capable and speedy efficient XP box, its a great option for a lot of older hardware. I was doing this two years ago after getting fed up with closed and crappy apps, and then realized I might as well go all the way and use linux, so its a good intro to people who are curious about what open source offers. A lot of people were cautious about bringing free stuff to a closed platform, but I think it can only be good, as it increases awareness and may spur a platform switch like me. Also, not spreading freedom into an area where there lacks freedom sounds a lot like not donating food to an area that is starving. Neither will get people to move to linux/out of the third world.

Er, Delphi never supported type inference, closures, or metaprogramming of the sort that Microsoft are introducing to .NET in C# 3 and VB 9. These features are coming from the functional programming world, from languages like Lisp and ML.

For existing languages that offer similar features in a braces syntax, see Nemerle or Scala.

(Languages like Ruby offer related features, but their lack of static typing means they're more distant cousins.)

Depends on where you look:

http://linuxshop.ru/linuxbegin/win-lin-soft-en/tab le.shtml
http://gnuwin.epfl.ch/en/index.html

Enjoy

What would be really nice is to see this grow past a simple MD5 database. If you're going to get traffic, you really should get an NTLM database up and start populating it as soon as possible.

A few other places have these, in differing amounts. Rainbowcrack has tons of them, but require you to submit some before being allowed to query the system. I did submit a few NTLM hash tables, but it took the better part of a week to get my query back (it's supposed to be a lot faster than that).

There's also Ophcrack which uses tables similar to rainbow tables. It has a web interface to query NTLM hashes for simple passwords.

With these pre-computed hash tables, basic password security is starting to take a hit and it's becoming more and more worthwhile to use a simple but long password rather than a short and complex one. If you're on Windows, it's also VERY worthwhile to read about forcing Windows to store only the NTLM hash and drop the LM hash. It breaks old compatibility with Win 9x but is very worth it if you don't need that. This helps against precomputed attackes but has an even bigger impact agains brute-force attacks.

Absolutely. Burn off a bunch of copies, and hand them out while talking about the Free beer/speech concept.

For anyone who hasn't looked at the Open CD lately, it still has all the OSS for windows goodness it always had, and now it includes Ubuntu live on the same CD with the same apps installed there.

I was also going to suggest GnuWin as well, but they seem to be in limbo at the moment. Maybe put together your own disk of OSS apps based on their list, which has several good titles that the Open CD doesn't have. The two compliment each other fairly nicely.

Absolutely. Burn off a bunch of copies, and hand them out while talking about the Free beer/speech concept.

For anyone who hasn't looked at the Open CD lately, it still has all the OSS for windows goodness it always had, and now it includes Ubuntu live on the same CD with the same apps installed there.

I was also going to suggest GnuWin as well, but they seem to be in limbo at the moment. Maybe put together your own disk of OSS apps based on their list, which has several good titles that the Open CD doesn't have. The two compliment each other fairly nicely.

I use my very own enotes.el under GNU/Emacs.

The total amount of water on the Earth is invariable.

The Solar Impulse Project: a round-the-world trip on a solar powered airplane

http://www.solar-impulse.com/en/index.php
http://solar-impulse.epfl.ch/
http://iacs.epfl.ch/cmcs/Solar_Impulse.php3

The Solar Impulse Project: a round-the-world trip on a solar powered airplane

http://www.solar-impulse.com/en/index.php
http://solar-impulse.epfl.ch/
http://iacs.epfl.ch/cmcs/Solar_Impulse.php3

I can see your point, but DES does have other weaknesses. Just last year, for my research project in math I wrote a perl script that could crack any word document encrypted with an alphabetic key in less than a day. But of course that is fairly easy since the alphabet is only 14 characters when encrypted in DES (the last bit is discarded). Given, I exploited the small keyspace, but I still wouldn't trust a DES derivative over AES or one of the other modern ciphers.

the open cd

http://theopencd.org/

and GNUWin II

http://gnuwin.epfl.ch/en/index.html

Though the included software is all relatively recent, developement on maintaining GNUWin has halted as of Nov of last year. They are currently looking for contributors who are motivated enough to help lead and continue the project.

"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvw xyz0123456789!@#$%^&*()-_+=~`[]{}|\:;"',.?/ "

You can either spend a few months creating your own Rainbow Tables http://www.antsight.com/zsl/rainbowcrack/, or you can buy the 64GB tables for $640, http://www.antsight.com/zsl/rainbowcrack/rt_price. txt.