Let's talk about about C++, as it deserves it from time to time.
Especially because I've lost a couple of days on a not-enough-advertised-feature:
std::ifstream in;
in.open("somefile",std::ifstream::out);
(
https://www.destroyallsoftware.com/talks/wat)
Opening an input file stream for output is not at all convoluted.
It's both a crystal clear code and a brilliant idea!
Good enough to transcribe it in the standard library:
http://www.cplusplus.com/reference/fstream/ifstream/open/
What difference does it make with fstream? Or should I rather open an ofstream for input? It leaves plenty of room for speculation. if someone knows, he shall write a blog post immediately!
But if the standard offers some weird path, by virtue of Murphy's law, be sure that someone will follow it, whether accidentally or not.
Murphy's law has more to offer: Microsoft implementation changed somewhere between .NET 2003 and .NET 2010, so that opening an input file stream for output on a write-protected file does now fail, what it didn't previously...
Of course, the file has to be read only at deployment site, not in developer's configuration where we have debuggers, otherwise things would be much too trivial.
Recompiling a legacy application while not exerting enough code review is a dangerous thing, so let's not blame C++ for our own mistakes. Except that C++ did not especially help here.
My colleagues said: "tu-mourras-moins-bete" (auf deutsch). Not so sure: I feel like this kind of information is not going to reduce the entropy in my brain.
I'm not going to change C++. I can't. But I'm itching to simplify our own Squeak Stream hierarchy with such reduction of entropy in mind. Don't push me!
Previous post was about alignment problems in Smallapack matrix inversion. Let us look at another one that crippled the jpeg plugin for 64 bits windows flavour of opensmalltalk Virtual Machine (issue 119).
The problem originate at win64 requirement for jmp_buf type used in setjmp/longjmp: it must be 16-bytes aligned. I couldn't find a reference to this requirement, but there is a definition in some header that ensure such alignment. Appropriate cygwin grep in /usr/x86_64-w64-mingw32/sys-root/mingw/include will reveal:
setjmp.h: typedef _JBTYPE jmp_buf[_JBLEN];
setjmp.h: typedef SETJMP_FLOAT128 _JBTYPE;
setjmp.h: typedef _CRT_ALIGN(16) struct _SETJMP_FLOAT128 {
With such definitions, the C compiler will manage to properly align the data, so we don't have to worry... Or do we?
We use setjmp/longjmp for the purpose of error handling (and properly quiting the primitive). But we had the brilliant idea to put such jmp_buf member in a structure (see JPEGReadWriter2Plugin/Error.c).
The layout of the structure cannot vary for each instance, so if we want one member to be aligned on 16bytes boundary, the sole solution is to align the whole structure itself to 16bytes boundary, and fill enough gaps between members. Alas, both gcc and clang fail to do so. I don't know if I should report a bug for that.
Imposing that requirement to our own structure, in a portable and future-proof way is less than obvious. So the workaround was rather to use a pointer on a jmp_buf - see pull request #120.
This kind of bug is pretty tricky, but if you have to implement some VM parts in C, what do you expect?
Smallapack is the Smalltalk interface to LAPACK, the famous Linear Algebra Package (see github).
Despite the decent level of stability achieved by Smallapack these last years, interfacing a huge library like this can't be that simple, it's like asking for trouble. The last bug reported was about non reproducibility of matrix inversion. Indeed, it is easily reproducible on Mac OSX with this snippet:
(10 to: 100) detect: [:k |
a := LapackSGEMatrix rows: k columns: k.
a fillRandUniform.
x := ((1 to: 100) collect: [:i | a reciprocal]) asSet asArray.
x size > 1].
Above code does invariably return 32 on Mac OSX Squeak/Pharo, whatever VM, 32 or 64 bits, Spur or Cog.
On Squeak, a short path for trying above code is to first file this in:
((Installer ss project: 'Smallapack') package: 'ConfigurationOfSmallapack') latest install.!
ConfigurationOfSmallapack loadLatestVersion.!
I've long been clueless about this one, debugging 32x32 matrices is no fun (prepare to scan thousands of digits), especially when the differences between matrices are small, and especially when results differ from one shot to another... Inspection of code and step by step debugging did not reveal anything. Anyway, why does it happen only in single precision and not double? And why not in Linux?
I tried to reproduce above behavior with a C program without success for a while. Until I discovered that the results of C did differ in 32 and 64 bits. That's been the enlightment: Apple internally use different optimized paths for the Accelerate.framework. Especially when the alignment of data varies, the proof in C below:
//
// main.c
// test_sgetri
//
// Created by Nicolas Cellier on 30/01/2017.
//
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <Accelerate/Accelerate.h>
typedef struct {
int nr;
int nc;
float *data;
float *alloc;
} sge;
unsigned int align = 0;
sge sgealloc( int nr , int nc )
{
sge new;
new.nr = nr;
new.nc = nc;
new.alloc = (float *)malloc( sizeof(float) * (nr * nc + align) );
new.data = new.alloc + align;
return new;
}
void sgefree( sge const * m )
{
free(m->alloc);
}
sge sgedup( sge const * m)
{
sge new = sgealloc( m->nr , m->nc );
memcpy( new.data , m->data , sizeof(float) * m->nr * m->nc);
return new;
}
sge sgerand(int nr,int nc)
{
sge m = sgealloc(nr,nc);
int isUniform = 1;
int seed[4] = {1 , 11 , 111 , 1111 };
int size = nr * nc;
slarnv_(
& isUniform,
seed,
& size,
m.data);
return m;
}
sge sgeinv( sge const * m )
{
sge a = sgedup( m );
int *ipiv = malloc( sizeof(long) * m->nr);
int info;
sgetrf_(
& a.nr,
& a.nc,
a.data,
& a.nr,
ipiv,
&info
);
if( info ) {
fprintf(stderr,"sgetrf failed info=%d\n",info);
abort();
}
float w;
int lwork=-1;
sgetri_(
& a.nr,
a.data,
& a.nr,
ipiv,
& w,
& lwork,
& info
);
lwork = (info==0)
? (int) w
: a.nr * 10;
float *work = malloc( sizeof(float) * lwork );
sgetri_(
& a.nr,
a.data,
& a.nr,
ipiv,
work,
& lwork,
& info
);
if( info ) {
fprintf(stderr,"sgetri failed info=%d\n",info);
abort();
}
free(work);
free(ipiv);
return a;
}
int main(int argc, const char * argv[]) {
sge m = sgerand(32,32);
sge ref = sgeinv( &m );
for( unsigned int i=0;i < 16;i++) {
align = i % 8;
sge tmp = sgeinv( &m );
if( memcmp( ref.data , tmp.data , sizeof(float) * m.nr * m.nc) ) {
fprintf(stderr,"reciprocal differs from reference at step i=%u\n",i);
abort();
}
sgefree( &tmp );
}
sgefree( &ref );
sgefree( &m );
return 0;
}
Conclusion, every problem I encounter in Smallapack can be solved by the same swiss knife solution: just check the alignment. Objects are rellocatable by garbage collector in Smalltalk, so there is no easy fix. Maybe I'll have to insist on using well aligned heap instead of Smalltalk memory, I thought I was relieved of such heaviness since the advent of 8 byte alignment in Spur. Alas 8 is not enough... Who knows if a future SSE5 won't require a 2^5 alignment. Tsss!
Opening an input file stream for output is not at all convoluted.