Valgrind (Photo credit: Wikipedia)
I am working on a simulation environment for a NoC. The idea is that we can take a memory reference string – generated by Valgrind – and then test how long it will take to execute with different memory models for the NoC. It’s at an early stage and still quite crude.
The data set it is working with is of the order of 200GB, though that covers 18 threads of execution and so, very roughly speaking, it is 18 data sets of just over 10GB each. I have written some parallel Groovy/Java code to handle it and the code seems to work, though there is a lot of work to be done.
I am running it on the University of York’s compute server – a beast with 32 cores and a lot of memory. But it is slow, slow, slow. My current estimate is that it would take about 10 weeks to crunch a whole dataset. The code is slow because we have to synchronise the threads to model the inherent parallelism of the NoC. The whole thing is a demonstration – with a vengeance – of Amdahl’s Law.
Even in as long a project as a PhD I don’t have 10 weeks per dataset going free, so this is a problem!
I have not had much luck in hunting down what is wrong with my code or the Xerces-c SAX2 parser – but I do think I have successfully updated by hex editor, Hexxed, to handle 64 bit (ie >4GB) files.
Indeed it performs rather better than vi for some editing tasks (Hexxed has a vi like interface).
So, if a hex editor, capable of handling little and big endian code and able to display output in Unicode is what you are after, and if you are vi-conditioned, then maybe Hexxed is your thing.
Groovy code can be found at: https://github.com/mcmenaminadrian/hexxed
While a runnable jar for those of you who have Java but are not yet Groovy can be downloaded at: http://18.104.22.168/hexxed.jar
And there is more about it here: http://cartesianproduct.wordpress.com/2012/06/03/hexxed-usage-options/
Just remember it is code for playing with – don’t bet the farm on it. But, that said, I have no reason to think it does not work.
I cannot imagine that this matters to anyone other than me right now, but for the record (this is taken from a hacked up version of Valgrind‘s Lackey tool):
VG_(printf)("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n");
VG_(printf)("<!DOCTYPE lackeyml [\n");
VG_(printf)("<!ELEMENT lackeyml (application?, (thread)*)>\n");
VG_(printf)("<!ATTLIST lackeyml version CDATA #FIXED \"0.2\">\n");
VG_(printf)("<!ATTLIST lackeyml xmlns CDATA #FIXED");
VG_(printf)("<!ELEMENT application EMPTY>\n");
VG_(printf)("<!ATTLIST application command CDATA #REQUIRED>\n");
VG_(printf)("<!ELEMENT thread (instruction|store|load|modify)* >\n");
VG_(printf)("<!ATTLIST thread tid CDATA #REQUIRED>\n");
VG_(printf)("<!ELEMENT instruction EMPTY>\n");
VG_(printf)("<!ATTLIST instruction address CDATA #REQUIRED>\n");
VG_(printf)("<!ATTLIST instruction size CDATA #REQUIRED>\n");
VG_(printf)("<!ELEMENT modify EMPTY>\n");
VG_(printf)("<!ATTLIST modify address CDATA #REQUIRED>\n");
VG_(printf)("<!ATTLIST modify size CDATA #REQUIRED>\n");
VG_(printf)("<!ELEMENT store EMPTY>\n");
VG_(printf)("<!ATTLIST store address CDATA #REQUIRED>\n");
VG_(printf)("<!ATTLIST store size CDATA #REQUIRED>\n");
VG_(printf)("<!ELEMENT load EMPTY>\n");
VG_(printf)("<!ATTLIST load address CDATA #REQUIRED>\n");
VG_(printf)("<!ATTLIST load size CDATA #REQUIRED>\n");
Update: As originally published this code had an error in the name of the attribute for thread – I have fixed that now.
I did not actually read Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software – I listened to it as I pounded treadmills and pulled cross-trainers and so on in the gym.
1-2-3 boingmash… Mark Frauenfelder, Xeni Jardin, Cory Doctorow and Mitch Kapor. (Photo credit: Wikipedia)
That ought to be a giveaway that it doesn’t actually contain any code or maths or anything else that might require some dedicated concentration, but that does not mean it is not worth reading (or listening to) if you are a programmer, manage programmers or in some way are responsible for the development or purchase of software (it is plain that few or no people at the DWP have read this book – given their travails over the “Universal Credit” project – someone should stick a copy in each minister’s red box pronto).
I have never worked as a professional software developer – though I have written code for money – but still I found this book had a lot of insight, and even manages to explain things such as the halting problem and infinite recursion in a way that non computer scientists are likely to grasp without boring those of us who know what these are.
The book is incomplete, though in that it was written before what looks like the final collapse of the project it describes – the Chandler PIM – in 2008/9 when founder Mitch Kapor withdrew. Chandler sounded like a great idea (like Universal Credit?) but, as the project drags on and on, one begins to wonder what on earth the development team were up to for most of the time they worked on it.
Well worth reading.
One problem about the audio though – I know the American fashion is to mispronounce French words and I don’t want to sound like a European prig (after all this book is about a vital technology in which the US leads the world) – but it goes too far when Albert Camus‘s name is repeatedly made to rhyme with bus!
For the first time in a few years I am mucking about with Perl scripts.
I know the language is in decline and Perl 6 has become the ultimate in vapourware, but I have to report I still love it.
Donald Ervin Knuth (Photo credit: Wikipedia)
Regular readers will know I am usually unstinting in my praise of the New Scientist. But not this week.
There is a very poor article by Michael Brooks, an admitted non-programmer (would you have someone who could not speak French write on the Académie française?) lamenting the “teetering tower of Binary Babel” of the “jerry-rigged” programming languages most of which, he claims, are “still thinly veiled versions of Fortran“.
To make it all better, he asserts, “salvation may be at hand in a nascent endeavour in computer science:user-friendly languages that rethink the compiler.”
These languages “allow programmers to see, in real time, exactly what they are constructing as they write their code.”
And he adds: “Bizarrely, the outcome may look rather familiar” – like a spreadsheet he says.
So, actually, we are back with visual programming tools – such as “Subtext“. Donald Knuth can sleep easy then – Brooks is not challenging him as the greatest living writer on programming, that’s for sure.
I am old enough to remember the legend that was Guy Kewney waxing lyrical in the pages of “Personal Computer World” in 1981 about a BASIC generator called “The Last One” which did indeed claim to be the last program you’d need. At least Kewney demonstrated he knew the subject, even if he got that one profoundly wrong.
I have never written any Python. Maybe that might change in the future, but not soon I think.
English: Python logo Deutsch: Python Logo (Photo credit: Wikipedia)
So PyCon, a big conference for Python developers, normally would not matter to me, especially as it is on another continent.
But this year’s PyCon saw a huge row about allegedly offensive and sexist behaviour. In my view the sexist bit is moot, the offensive bit is mild - if stripped of context. And the context is a year’s worth of rows about much more clearly sexist and offensive behaviour at developer conferences.
I won’t go into the details of the row, because I have no real knowledge of the detail beyond what I have read this evening, but I do have a sense that this is a sign of the software industry waking up to its very serious problems with women and the ridiculous behaviour and poor socialisation of many of the men who work in it.
So the row may have a positive outcome for the rest of us. Eventually.
I have done some work on my Scratch-based version of Conway’s Game of Life…
Regular readers will know I have something of a small obsession with Conway’s Game of Life – the classic “game for no players” based on cellular automata, and so, naturally enough, when I decided that I really had to write my own Scratch program from, err, scratch to sharpen up my skills for teaching children via Code Club, that is what I chose to write – the (not very sophisticated) results can be seen above.
My first conclusion is that Scratch is a truly awful tool for most programming tasks. I know it is not meant to be a general programming tool, but I quickly discovered that it is hobbled even when it comes to doing those things that one assumes, at first glance, it is set up to do – like drawing on the screen. Scratch actually has very, very limited functionality/expressive power when it comes to drawing graphics – being only able to handle pre-provided sprites (as first class objects) and using a pen which marks out one pixel at a time – thus one cannot (at least easily) find a way to draw anything beyond dots and lines on the screen in response to events.
If you run the above program using the Flash player provided by the Scratch site you will probably see one of the big downsides of that as outlines of the old crosses are left on the screen (the Java player does not have this problem but it is very slow in comparison).
From a teaching point of view I also find Scratch’s message-based system less helpful than an imperative
GOSUB like approach: the children I work with, after many weeks, are still struggling with the idea that messages should drive actions (probably we should blame their instructor!) – I know this event-based style is more common in the real world, but I think teaching the idea of problem decomposition via subroutines or functions is probably more important educationally.
Yesterday I went to the first London Hackntalk and gave an impromptu (and so unprepared) and brief talk on my thoughts about teaching children to program – my experience with Code Club makes me rather less starry-eyed about mass programming education. There were a few responses from the audience which suggested I had not really got my point – that we would struggle to fully replace an ICT curriculum based on usage skills with one based on programming – as the audience continually suggested ways to get motivated and engaged kids into programming (rather than make it a mass participation thing), but one point that was made by a member of the audience was very acute – given what our children see computers do in games that cost many millions to develop, how realistic is it to expect all or many of them to put lots of effort into toy programs that chug out the sort of graphics you can see above? I think that is a really difficult issue we have to consider when overhauling the curriculum and I am not sure the enthusiasts of radical change (of which I was and still am one) have thought it through fully.
(I did also encourage them to be Code Club instructors and was a bit disappointed to see that I appeared to be the only one – we urgently need to teach more programming and so these problems of the early days of the overhaul should not obscure the need for change.)
I decided I wanted to write “Conway’s Game of Life” in Scratch (I am sure somebody else will have done this, but that’s not the point).
What a nightmare. Enough to make me rethink my views on Scratch’s usefulness as a teaching tool.
More to follow when I have actually finished it – tomorrow evening I hope.