Please wait...
Of course, back then, we used CISC processers that allowed us to write smaller code. Now that everything is RISC, and I think we've moved away from CISC compiling, we have to use many more bytes of code to do the same thing, but it works faster.
project.
The idea behind the contest is that the rigid constraints of designing for the web are what force us to get
truly creative. Between servers and bandwidth, clients and users, HTML and the DOM, browsers and platforms, our
conscience and our ego, we're left in a very small space to find highly optimal solutions. Since the space we
have to explore is so small, we have to look harder, get more creative; and that's what makes it all
interesting.
http://www.the5k.org/ (I think all the programs are long gone)
I think it might be more interesting to program in the MMIX environment, as it is stable for all generations (being a learning tool and all):
http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html
Tue Dec 24 2013 07:52:44 EST from fleeb @ Uncensored
Of course, back then, we used CISC processers that allowed us to write smaller code. Now that everything is RISC, and I think we've moved away from CISC compiling, we have to use many more bytes of code to do the same thing, but it works faster.
not to forget the leading zeroes you have to cary when compiling 64 bit code.
Today's CISC processors are actually just RISC processors surrounded by a bunch of microcode. Occasionally someone poses the question, "can we write directly to the RISC core?" but Intel and AMD and IBM don't make that interface available. Presumably they want to be able to change it without worrying about backward compatibility.
So it's true that the argument over whether RISC is faster is no longer interesting. RISC won a long time ago. The new question is whether you want your optimization-to-RISC done in microcode or by the compiler.
Does anyone even bother to look at their compiler's machine code output anymore? Even to see how large the resulting object code is?
Mon Dec 30 2013 10:03:44 AM EST from IGnatius T Foobar @ UncensoredToday's CISC processors are actually just RISC processors surrounded by a bunch of microcode. Occasionally someone poses the question, "can we write directly to the RISC core?" but Intel and AMD and IBM don't make that interface available. Presumably they want to be able to change it without worrying about backward compatibility.
So it's true that the argument over whether RISC is faster is no longer interesting. RISC won a long time ago. The new question is whether you want your optimization-to-RISC done in microcode or by the compiler.
Does anyone even bother to look at their compiler's machine code output anymore? Even to see how large the resulting object code is?
Only when compiling Python down or bare bones without external libs or C code and linking to non-stdlib stuff - I don't trust my own rusty skills these days. I used to be able to write (and compile C) on my trusty HP 100LX out in the woods and still get the job done. Sadly, I am more sloth like and need motivation to write code to a schedule (and / or) make it worth my while to write tighter code. I do get the chance here and there, but less and less these days. Wish I could do it more, and refine the craft, but it is a dying profession - just like making the hardware that pre-dates us all. That is probably why I own multiple Cherrypi boards (original 256MB models made in China), and only use one to be a - print server, file server, firewall, and media server (all at the same time)... Wish I could come up with more uses for the remaining boxed Pi's. But then again, I am old and I ramble too long...
on modern pc the resulting size of the binary is the challenge- what
can you get done on a modern pc with 1k code?
More, if you are willing to code to low-level apis (e.g. Win32s on Windows...)
1k is not a lot though, even on a C64
Hrm... is Win32 really a 'low level api'? I thought there were some api calls that device drivers make that seem a little lower level than the Win32 API.
It's that kind of relativity that has always bugged me when looking at job opportunities. It doesn't help that that people writing out the job offers don't always know what they're saying.
Hrm... is Win32 really a 'low level api'? I thought there were some
api calls that device drivers make that seem a little lower level than
the Win32 API.
Yep. These days it's quite rare to build a windows app without a gazillion layers of class libraries. But it used to be quite common to code directly to the KERNEL, USER, and GDI dlls and not much else...
Hrm... if java's == compares against reference equality, is there a reasonably easy way to compare against value equality?
java.lang.Object has a standard method "equals()", so all objects (except arrays) that can be passed by reference have an .equals() method that can be overridden. (The method for arrays exists, but can't be overridden.)
you use your IDE to auto-generate an equals() implementation. It's a parsimonious model, in that there's only one way to do things, but it's not the model a lot of people expect.
public boolean equals(Object x)
Compares this BigDecimal with the specified Object for equality. Unlike compareTo, this method considers two BigDecimal
objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method).
Does it consider zero and negative zero to be the same number?