- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Hey! I thought that I was the only one who re-used cards with variables to avoid waiting for a free 029!!!
Admin
Oooh I found a bug: case 16 < 0: should be case 16 << 0:
Admin
Eyes myEyes = goggles.doNothing();
Admin
Admin
It's sad you can't do that in C#. The break is mandatory :( (And that's nearly the only thing why I hate that language)
How could they do it?? Why did they destroy Duff's device? Why, oh, why???
[/whining]
Admin
Was this anonymised by transation from Pascal to C?
Admin
Actually, you can fall through if a bunch of cases map to the same behavior: http://msdn2.microsoft.com/en-us/vcsharp/aa336815.aspx
You can also use goto case, then cut your own throat and cry yourself to a gargling bloody death.
Admin
I'm pretty sure that the author doesn't know what the hell this is supposed to do
Admin
Well, this is it, folks. We've found the real WTF. We should all just go home now.
Admin
My jaw just dropped.
I do not understand how anyone could ever think such code was necessary. It is just lunacy. Do they think that everyone has to do that if they use the language?
Definitely a case of fingers hitting the keys and looking at the screen but not much going on behind the eyes.
Admin
Java's String class is 24 bytes larger than a char[] array on a 32-bit processor (4 for object monitor, 4 for vtbl pointer, 4 for array reference, 4 for start position in array, 4 for end position in array, 4 because JVMs like to align stuff on 8-byte word boundaries). This means that in Java, this line of code:
takes up 40 bytes (likely 72 on a 64-bit processor). In my open-source (Eclipse-based) Java project, I've been slowly changing the codebase over from using Strings to using char[]s and some of the code is actually starting to look like this WTF.Admin
Oops, the empty string is actually 44 bytes of memory. Forgot to add space for the reference itself.
Admin
Hey, some of us still have to use RCS.
Admin
Psst. Those are 'return' statements. A break would be superfluous. It'll still compile, but you'll get a warning about unreachable code.
Admin
Congrats for the n&(n-1)==0. And I was just reading draft of the 4th AOCP on bit manipulations...
Admin
That is not Duff's device. Duff's device is intermixing while and case loops:
(notice how the do starts inside the 'case 0')
Admin
So they were passing numbers from pascal as strings and didn't want them to go on the heap?
Admin
Oh really?
Admin
I've seen something similar to the powers of 10 that actually made sense -- on an embedded processor, had to do fast saturation inside the tightest loop (signal processing), and it turned out it was faster to index an array than put in the saturation logic.
But not something to be done lightly. I doubt there was that good a reason here.
Admin
If The water leaked from it, it cost a lot more to fix, though.
Admin
[quote user="operagost"][quote user="Steve"][quote user="anonymous"]The rest of the WTFs just look like someone having no idea how to code... at least in Java (or probably any newer-generation languages). This has the earmarks of an old-school mainframe coder.[/quote]Hey! I resemble that remark! (Started in the middle 1960s when punched cards were all the rage and we didn't need any newfangled text editors, green screens, or operating systems -- just put the compiler deck in the hopper, slap the source code deck on top, and press "START".) [/quote] So they not only looked like washing machines, but worked like them?[/quote
If the water leaked out of them, it cost a lot more, though.
Admin
Our whole productive code is based on char-arrays since some years ago a designer meant that Strings are just too slow.
BTW: Index-Checking in arrays was too slow for him as well:
int indexOf(char[] text, char search) { int i = 0; try { while(true) { if (char[i] == search()) return i; i++; } } catch (ArrayIndexOutOfBoundsException e) { return -1; } }
Admin
Well, that's a blast from the past - writing this is probably a mistake (assuming that most people here want to "burn the witch") but I think it's worth putting some context in for posterity, it also helps explain what looks like insane code. (You can of course still disagree with the reasoning we used for implementing it).
The year: 2002/2003ish
Imagine a real-time distributed system, hundreds of machines, each with several processes on them. The processes talk to each other via socket connections using a highly optimised low-latency message passing library.
In general you could pass data around with this library (which did it in a binary format) with no problem at all as the data tended to be doubles and ints, but every now and then there was the need to pass strings around. The library happilly handled strings, but the receiving process would have to allocate memory for the incoming string. There was also a lot of wasted memory form int/double to string conversion.
Remember, this was a realtime system, and at the bleeding edge of JVM use (JRocket from memory). Garbage Collection ergonomics weren't as good as they are nowadays - this was a problem because if the GC kicked in, it stopped the world. Bad news for a real-time system.
So, passing primitives between processes was fine as there was practically no memory consumed by doing so (socket overheads aside).
The senior architect decided that we needed to find a way to stop wasting memory on transient strings and string manipulations. Hence PStrings were born. (passing char[]s around instead of Strings).
So, where are we:
As I wrote the PString library you'd think I'd recognise isPString, but I don't. Looking at it here it looks plain wrong so I can only assume it has been modified since, or something is missing. Perhaps it's been refactored since originally developed and needs further cleaning up? I expect the JIT optimizes it down so it's not a performance hit, but the code's rubbish. I'm also surprised at the lack of comments, I tend to comment heavily, especially for something unclear.
All the other code in the WTF relates to number to string representation conversion, which you'll find dotted around the web and in Sun's Java source code. I used (with permission) code from the following book I believe: http://jlbtc.eduunix.cn/index/html/java/O'Reilly%20-%20Java.Performance.Tuning.2nd.Edition.eBook-LiB/0596003773_javapt2-chp-5-sect-3.html There were a couple of bugs in it which we helped fix, but as you can see, efficient double->string conversion is not a simple task, there are lots of look-up tables used to speed things up.
This appears to be someone else who has used the same library: http://www.koders.com/java/fid9B2B30D4084F831F061F3440EB40815111402793.aspx?s=mdef%3Ainsert
Finally, let's pose a few questions
Q. Are all of those lookup tables and crazy looking 'NaN' and 'Infinity' char[] wrong? A. No, that's how you do high-speed number to string conversion. For speed, look-up tables can be your friends whilst sacrificing memory.
Q. Are they worthy of a WTF A. Hell yeah. I scratched my head fixing a bug in the code from the book for quite a while. It would have taken me months to write one from scratch, and it wouldn't have been nearly as efficient.
Q. Are 'PStrings' a good idea? A. Back then, after repeated analysis with OptimizeIt and JProbe against our processes, I'd say it was the right thing to do. Nowadays, and having talked to Brian Goetz about modern day GCing, I'd say almost definitely not. JVMs have moved on and the GC is much improved nowadays.
Q. Am I sure it's my code? A. It might not be, but I definitely coined PStrings back in 2003 for our project, and it supported number<->string conversion. Let's be honest though, it's not exactly the most creatively named library (Hmm, pascal style strings, what could we call it?).
Cheers, Rob
Admin
note to self: whenever my code looks like ascii art, there's something wrong with it.
Admin
You can do the same in Java.
Admin
Strings (unmeasured) are too slow for him, exceptions (unmeasured) are perfectly fast enough, yet Java (unmeasured) was a speedy enough solution for his problems?
How many pills did you have to feed this guy daily? And of what kind?
I'm assuming that "productive" is a typo here.
Admin
In fact, pace JSR001, I can't see a single good (or even justifiable) reason to implement a real-time system in Java in the foreseeable future. There are plenty of good reasons not to do so:
(1) It requires a JVM. Huge memory footprint, which may or may not be a problem. Plus, JIT solutions can approach "native code" solutions asymptotically (and I'm a huge fan of Python's Psyco), but you're still giving up on the essentials for real-time programming (which Rob mentions). (2) The threading model. Say no more. (Although I'm sure that JSRxxx does.) (3) Java is not a natural language for real-time programmers. I have a lot of sympathy for people who say that C++ isn't either (although I'd argue that it's much closer), and therefore I'd expect to see real-time programs written in C, or maybe Forth, or a home-brew equivalent. I'd imagine that learning the discipline to program in real-time Java would be painful and would provide no obvious benefit. (4) Leaving the language to one side, if you insist on hiring a team to program real-time Java, you're going to have a huge problem with libraries. Now, I don't like Java's libraries at all, but that's not the point. If you hire a Java programmer to write a real-time system, they are going to use them -- and why shouldn't they? It's part of their natural environment. They are, in fact, Doing The Right Thing. Unfortunately, Java libraries (Sun- or Third-Party) are not designed to be real-time. This way lies madness.
Arguing about whether Java can, or should, be used as a real-time language is fun, and might lead to innovative high-level solutions (such as switching the goddamn garbage collector off altogether).
Arguing about low-level crap like string-to-int conversion makes sense in a C environment, but none whatsoever in a Java environment. It doesn't work at that level. Why the hell do you need to convert between the two in the first place, in a real-time system?
This whole thing (and I think Rob's solution is pretty neat, under the circumstances) appears to me to be the insane result of so-called architects with a preposterous political mission, no doubt mandated by some idiot in Marketing who wants to be the first to announce a Java Real Time System to the world.
There are, obviously, better ways to do it.
Admin
Wouldn't have to be C#, C++ can do that too.
</pointless observation>
Admin
real_aardvark
The industry within which I work takes a laissez-faire approach to terminology. Hard/soft real-time are not typically understood and are used to mean 'high-performance' regularly, a mistake I made in my reply above (my audience differs here). This was very much a high-performance system, and not a real-time one. Apologies for the confusion.
Genuine real-time systems are a completely different ballgame, and fascinating in their own right.
Admin
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarghhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Admin
Sometimes there's a good reason for inflicting pain. And although I cannot really judge whether your reasons were good enough, I now believe they were. It's still terribly ugly and I hope I will never have the need to do anything remotely like it, though.
Admin
The people who need to be burnt at the stake^W^W^W^W^W confess their sins are, as usual, the marketing department. I've lost track of the number of idiots who proclaim that a VB.Net or WinCE system is "real-time." Presumably, some defenceless purchasers out there actually believe it.
The only justification for the OP, in other words, is, as you say, "high performance." It sounds like you put a lot of thought into this. I just have this horrible suspicion that the "architects" in charge failed to profile the system in a realistic setting, or (at a lower level) to minimise the type clashes across function boundaries. High-performance does not imply bit-headed coding (although this is all too often mandated by those in charge).
I stand by my comment that the result is a thing of beauty, however, and I wouldn't change it for the world...
Admin
Anything C# can do, Java can do with only a geometric increase in stack depth.
Admin
Yep.. C# is the way to go.. You wouldn't even have to make things this complicated, because no matter what you do, the program is dog slow and basically useless :-}
Admin
tl;dr
Admin
Yes. Yes! YES! YEEEEEESSS!!!!!1!111!1!
BUZZGAZM! Oh yeah baby, give it to me once more!
B U Z Z G A Z Z M !
Massively Distributed RealTime Java!
Now if that ain't Rocket Science... I'll burst the dotcom bubble myself!
Oh wait.
Admin
Well Rob's last comment was excellent. Every once and awhile there are cases for exceptions to the rule (for example using goto in classic C).
In today's times yes that looks like questionable code, but at that moment in time, it was likely the best choice.
I don't know how many of you do game programming but they sometimes have to resort to tricks like this because CPU cycles are more valuable than RAM or disk space.
Admin
uh, oh. You seem to have shut up the trolls.
Admin
Made my day... Thanks for that
Admin