Blakeyrat Reads StackOverflow While Bored At Work
-
@Lorne-Kates said in Blakeyrat Reads StackOverflow While Bored At Work:
So we switch to chickens.
Wrong. They expect you to become vegetarian. (yes, I know you mentioned it later on.)
Actually, they usually say "there's too many people!" too, so the actual answer is they expect most people to die (just, of course, not them.)
-
@Adynathos said in Blakeyrat Reads StackOverflow While Bored At Work:
The modern replacement for C should be LLVM, all the types explicit.
No. While the type system is OK (I guess, though remember that signedness is a property of the operations, not the types) the rest is just working with a somewhat-unusual assembler. Nobody ought to work with LLVM until they understand what a φ-node is and why they need it.
-
@Lorne-Kates said in Blakeyrat Reads StackOverflow While Bored At Work:
I love these "will save X amount of Y" bullshits. Because they always ALWAYS ignore the amount of X that will be incurred to replace Y with Z.
They also ignore that some parts of the world can grow normal grass way easier than cereals.
-
Why does a local var reference cause a large performance degradation?
Consider the following simple program: using System; using System.Diagnostics; class Program { private static void Main(string[] args) { const int size = 10000000; var array = new
I like the question. It's obvious to people who have been working with computers for awhile, but I could see how it would trip up a newbie.
EDIT: This I read this comment from the asker:
@ChrisDunaway In both situations it's allocating 10 million different strings. In the fast version I happen to not use the result of that allocation, but it still occurs - it's not (and can't/shouldn't) be optimized away.
And now I've changed my mind, he's an idiot.
I'd love to hear his reasoning on why that string in a tiny scope which is never used "can't" be optimized away, though.
EDIT EDIT: Oh it turns out I'm the idiot. C# does create a second string for some reason, and the speed difference is due to different garbage collection modes.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
I'd love to hear his reasoning on why that string in a tiny scope which is never used "can't" be optimized away, though.
My take: it's probably not impossible, but it's difficult and the current compiler doesn't bother. The problem is proving that the allocation of the string (and preparation of the arguments, though that's a simpler case) doesn't have an observable effect, despite it involving allocation and a
methodconstructor call. Now, the exact implementation of the constructor is known, so analysing into it is possible (and JIT compilers can do that sort of thing easily enough) but the allocation itself is very difficult to prove failure-free.As long as the allocation is for a fixed amount and can be paired up with a deallocation in a cheap way, it really isn't a big deal.
-
This post is deleted!
-
@dkf said in Blakeyrat Reads StackOverflow While Bored At Work:
The problem is proving that the allocation of the string (and preparation of the arguments, though that's a simpler case) doesn't have an observable effect
It would be useful to be able to mark a function "has not side effects" (like in functional programming), for easier optimization and to be sure it does not break anything.
-
@Adynathos said in Blakeyrat Reads StackOverflow While Bored At Work:
It would be useful to be able to mark a function "has not side effects" (like in functional programming), for easier optimization and to be sure it does not break anything.
Yes, but that's not really necessary in the JIT as that can actually determine the fact for real. Or decide that that's not a provable fact and doing it would be an unsafe optimisation.
But anything with
new(outside of a context that catches all failures it can generate) is not side-effect free. Allocating the space for the object can fail; you can't prove that it won't since it can be made to fail by a change outside the process, imposed by the OS. It's just unlikely (especially if an identically-typed-and-sized object has just been released into the GC).
-
@dkf said in Blakeyrat Reads StackOverflow While Bored At Work:
But anything with new (outside of a context that catches all failures it can generate) is not side-effect free. Allocating the space for the object can fail; you can't prove that it won't since it can be made to fail by a change outside the process, imposed by the OS. It's just unlikely (especially if an identically-typed-and-sized object has just been released into the GC).
But a failed allocation is never a desired side effect if you're not doing anything stupid, so it doesn't effect a decision to optimize it away.
There are optimizations that C# won't do by default when you're debugging, even on Release, I'm not entirely convinced that it wouldn't already do that.
-
@fbmac said in Blakeyrat Reads StackOverflow While Bored At Work:
But a failed allocation is never a desired side effect if you're not doing anything stupid
Well, “almost never”. The difference is usually negligible unless you're working with very large memory blocks or doing something really complicated.
so it doesn't effect a decision to optimize it away.
No. That's not the same thing at all. In this case, you have to deal with the fact that the
newoperator has a defined failure semantics that include the key point that there is at least one exception that can occur apart from those thrown by the constructor, due to a failure to allocate the space required. This is a known failure mode. The optimiser cannot prove that it won't occur, so it has to assume that it might. That means that the call to the allocator has to remain, even if the result of that call can be immediately marked for deletion (and that's a pretty easy thing to determine).
-
@Adynathos said in Blakeyrat Reads StackOverflow While Bored At Work:
The modern replacement for C should be LLVM, all the types explicit.
What I would love more than anything is an ecosystem where 'real' languages compile to LLVM, which gets compiled into native machine code by the operating system. Each OS writes a LLVM->native compiler/optimizer, and nobody has to worry about the python virtual machine. Unladen swallow tried to do this but it died.
That's the Java dream I guess, but including an interpreted bytecode layer makes all of that system-independence pointless. Why compile to bytecode? You already have to distribute a bytecode emulation layer, just distribute the interpreter.
If you can't compile bytecode to real native instructions what's the point of it?
Oh, it turns out CLI does this. And Mono is open-source now. If only ironpython could call into C libraries. :(
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
That's the Java dream I guess, but including an interpreted bytecode layer makes all of that system-independence pointless.
Right; and like Java, you have an ass shit GUI with no way to make a quality one. That's the part Java did wrong, you're not addressing that problem at all. (Actually, there's more than just that wrong in Java-- for example, its runtime giving wrong bad stupid paths when applications ask for the "user" folder in Windows. But.)
Getting the code running on multiple platforms is easy. Making an full, complete, native look-and-feel application is very difficult. Java barely even tried. I have no assurances that LLVM would do any better.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Making an full, complete, native look-and-feel application is very difficult.
Honestly I recognize how difficult that is but I also don't care very much. I don't have to worry about GUI toolkits, I do number-crunching computing mostly.
OS providers don't want to standardize on UI widgets, because that's a lot of how they differentiate themselves. As a result, UI needs to be slightly retooled if you want to use native widgets for each new platform. Hashtag business reasons.
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
Honestly I recognize how difficult that is but I also don't care very much.
Then you already have 437423742376427 solutions without adding another LLVM-based one. Sheesh.
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
OS providers don't want to standardize on UI widgets, because that's a lot of how they differentiate themselves. As a result, UI needs to be slightly retooled if you want to use native widgets for each new platform. Hashtag business reasons.
Right; but my point is unless you're going to tackle that problem, we don't need more Javas or more .Net's or more Pythons, or Perls, or Gos, Rubys or... there's a MILLION WAYS to run the same code cross-platform now. Why add more? Unless you're going to actually solve a problem that hasn't been solved?
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Unless you're going to actually solve a problem that hasn't been solved?
I want to compile my code to LLVM or bytecode of some kind and have it runnable anywhere with native speed. We don't have that, I want it, and it's not really that related to the GUI problem. That's a distinct business problem with business constraints.
I should just give up and use PyPy or possibly IronPython. :(
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
I want to compile my code to LLVM or bytecode of some kind and have it runnable anywhere with native speed.
Then learn Go or Rust.
YOU ALREADY HAVE WHAT YOU WANT.
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
I should just give up and use PyPy or possibly IronPython.
Right; speed is super-important to you, so you're going to write the code in Python. THIS IS RATIONAL THINKING AND NOT-AT-ALL-INSANE.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Right; speed is super-important to you, so you're going to write the code in Python.
Python is big in the Ivory Tower Forest. Except for numpy being unavailable, pypy is pretty much ideal. The python ecosystem is essentially a big stew of dynamic python with little nuggets of C libraries sprinkled throughout. It's not great.
Go explicitly does not compile to LLVM. All Go binaries contain the Go runtime (and the entire go stdlib
). This is not what I want.My point is, I want all languages to compile to LLVM IR and the OS to compile LLVM IR into real machine code, because it's insane for anything else to happen.
Rust does compile to LLVM IR. I guess I want higher-level languages to compile as well as Rust does.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Then you already have 437423742376427 solutions without adding another LLVM-based one
And what are those solutions then?
The key point is that the mechanism needs to be present on most machined by default.
Java is great but for some unknown reason it is not by default included by any OS.
-
@Adynathos said in Blakeyrat Reads StackOverflow While Bored At Work:
Java is great but for some unknown reason it is not by default included by any OS.
They were at one time. They fucked it up by being incompetent, and then getting all pissy at Microsoft for trying to make a Java runtime that didn't suck shit.
-
@blakeyrat Also it is very sady they abandoned Java Applets instead of improving the tech and including it in browsers. Making web applications would be super easy, instead of the JS/HTML hell trying to reimplement the same features years later.
-
@blakeyrat Embrace, extend and extinguish tactics came from internal Microsoft documents, you can't claim they were just making things better.
They would have killed Java, or transformed it into something windows-only.
-
@Adynathos said in Blakeyrat Reads StackOverflow While Bored At Work:
Java is great
You gotta be buffaloing me. The whole point of this, literally the entire point, is that you need a compiler to native machine code. And there are N languages and M architectures, and so we don't have to address NxM possibilities we can just do N+M by compiling to LLVM and then 'executing' the LLVM by compiling to native machine code.This might be really hard in the case of some dynamic languages, but it lets you optimize chipset pipelining and branch prediction and various other insane optimizations at different levels.
(also fuck java. Respect my keystrokes! Unnecessary capital letters are stupid. )
-
@AyGeePlus .net had a thing for compiling bytecode to native at install time IIRC
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
is that you need a compiler to native machine code
If there is a platform-independent format for executable code (be it LLVM, JVM or whatever), I don't really care how the execution is being done if the performance is good.
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
Oh, it turns out CLI does this.
I know. I wish it had caught on more. I didn't even know about this until I started googling things to make sure I didn't look like an idiot.
-
@fbmac said in Blakeyrat Reads StackOverflow While Bored At Work:
Embrace, extend and extinguish tactics came from internal Microsoft documents, you can't claim they were just making things better.
It went like this:
Sun: "Java is perfect, we don't care that it can't use ANY Windows GUI features like accessibility or voice control or anything like that."
Microsoft: "well, we've followed your spec but we really think our developers want to add Windows-specific features, so we'll implement a few in their own namespace in a compatible way"
Sun: "MURDER DEATH KILL MICROSOFT EBILS OMGOMG OMG LAWSUITLAWSUITLAWSUIT!"
MIcrosoft: "Fine; then we won't adopt Java. Sheesh."
Oracle: "Yeah, Sun's flat busted, we're buying them now."
So you're right that Microsoft embraced and extended Java, but the "extinguish" part wasn't a homicide, it was a suicide.
-
@Adynathos said in Blakeyrat Reads StackOverflow While Bored At Work:
I don't really care how the execution is being done if the performance is good.
And you shouldn't have to!
Compiling to java bytecode that runs on the JVM means you need to carry a JRE everywhere. Those are hundreds of megs(for some reason. Probably variable names and camelcase
) and inline optimizer notwithstanding, interpreted languages with 'bytecode' is kind of silly. Not to mention Java 'bytecode' is fairly high-level.(note, I want LLVM because it can be compiled basically anywhere. Anything that compiles to native machine code would be acceptable, including java bytecode if that could be made to work.)
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
note, I want LLVM because it can be compiled basically anywhere
Where you've carried an LLVM compiler. Kind of like carrying the JVM around to compile the java bytecode.
Yes, yes, I get that they're different things and there are reasons to prefer one over the other, but it's not like "basically anywhere" has LLVM compilation services. I'd think that you're more likely to find a JVM than LLVM.
-
@boomzilla And the JVM contains stuff that might be of interest to people who aren't just CLI-using math weirdos. Like... the ability to open a window and draw buttons on it. It's not good at it, but it's capable of it. LLVM would require millions of lines of new code to do that.
-
@boomzilla In theory you can compile LLVM and splat the compiled code to other machines without carrying the JVM with you. In practice you can also do that with Java bytecode(well, GCC claims to be able to), but nobody does.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
LLVM would require millions of lines of new code to do that.
No, LLVM would require you to compile some of the millions of lines of existing code that already does that, to do that.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Microsoft: "well, we've followed your spec but we really think our developers want to add Windows-specific features, so we'll implement a few in their own namespace in a compatible way"
If only there was a way to extend programming languages with new functions. Like a 'library' of functions.
Seriously, the MSJVM didn't pass automated Java 1.1 compatibility tests(didn't do JNI right or something) but put the picture on it that said it did. How are you on MS's side on this one?
-
@AyGeePlus My side is "Java apps are all ugly unusable slow abominations on the desktop, and ANYTHING that makes them go away is ok by me."
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
@AyGeePlus My side is "Java apps are all ugly unusable slow abominations on the desktop, and ANYTHING that makes them go away is ok by me."
That's not a position as much as it is a statement of fact. Ugly and unusable are subjective, but boy are they slow. (I think it's the GC that's most of the problem.)
I'm just pointing out your description of the Sun v Microsoft lawsuit is inaccurate.
-
@AyGeePlus The gist of it is. Microsoft was 100% behind Java, to the point where they expended huge amounts of resources building their own JVM from spec, until Sun suddenly decided they didn't really want that 90% of their install base and sued to get rid of it.
I don't know how Sun thought Microsoft would react, but if they thought it was anything other than "Microsoft will stop shipping the JVM altogether, fuck you" than they're amazing idiots. You don't bite the hand that feeds you.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Microsoft was
100%110% behind JavaSo behind Java they added extra bonus stuff to the Java Core libraries(just put them under microsoft.*, not java.* Seriously). So behind Java they didn't implement the JNI or the RMI, choosing instead to implement their own version(RNI) and then saying 'Java 1.1 compatible' on the front.
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
You don't bite the hand that feeds you.
And just because you have more money doesn't mean you get to breach contract whenever you want.
I don't know if you're a
but you can read words, right?
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
In theory you can compile LLVM and splat the compiled code to other machines without carrying the JVM with you.
Oh, sure. Sorry, I was under the impression that you wanted to distribute the LLVM bytecode itself, not a compiled blob.
-
@boomzilla I mean, I do.
This would benefit me, who writes code for clusters all the time, a great deal. One producer machine compiles to native code that many subsidiary machines can then execute. Or you download bytecode, and it's one-time compiled for your machine by your OS.
It has benefits.
-
Why did Voyager have tricobalt torpedoes?
Why did Voyager have the tricobalt torpedoes with them in the first episode of the series? Seven of Nine brought this up in "The Voyager Conspiracy" (Season 6). Was there any truth to what Seven ...
Considering all the shit that even a typical Starfleet ship goes through having a couple large explosives on-hand seems like a good idea. Remember that episode of Next Gen where they get stuck in a space wedgie and needed a large explosive and didn't have one? (They had to instead supply hydrogen and let some telepathic alien detonate it.) Heck, maybe Voyager has tri-cobalt explosives specifically for that reason.
Considering the rate that ships go through torpedoes, though, and the size of a photo torpedo relative to the size of Voyager, 42 is a really small number. I mean, our submarines carry a small number of torpedoes because each torpedo is like 1/5th the length of the entire ship. Photons are just big enough to be used as coffins, and the space used by Voyager's dining room or one of its holodecks could store hundreds. They could line the shuttle bay and have 150 probably. Or have every crew member keep 2 in their closets, that'd be 120.
BTW, "The Voyager Conspiracy" is one of the surprisingly good episodes of Voyager.
BTW BTW, this question also reminds me of the excellent series premier of DS9, when the stripped and barely-functional station is facing 3 Cardassian warships and Kira's trying to bluff them that the station is fully-armed:
Kira: "Fire 6 torpedoes as a warning shot."
O'Brien: "We only have 6 torpedoes."
Kira: "We aren't going to win this fight with torpedoes, Chief."
-
Were there ever any depictions of non-android robots in any Star Trek episode or movie?
Possible Duplicate: Why are there so few robots in Star Trek? I would say that the relative lack of onscreen robots had to do with show budgets, but even some of the cheesiest science fiction ...
Star Trek didn't use robots because robots looked cheap and crappy and appeared in the kind of sci-fi (for example: Lost In Space) that Star Trek was consciously not trying to be anything like.
(Although arguably the most famous film/TV robot, Robbie the Robot, originated in Forbidden Planet which has an extremely Star Trek-esque script.)
When they did start using robots, it was industrial non-human robots (like the NOMAD probe, or the Exo-Comps in Star Trek: TNG) and not the shitty kind played by humans in bad costumes.
With one exception.
I think you know what it is.
Yeah. Voyager did it. And it was an extremely bad costume.
(Satan's Robot doesn't count, because he's obviously a spoof and also pretty awesome-looking.)
-
Has a fifteen year old from Canada discovered a hidden Mayan city?
Recent news stories have reported on the discovery of a lost Mayan city by William Gadoury, a 15-year-old from Canada. According to these reports, Gadoury noticed a correspondence between the locat...
Until he gets his ass in a jeep and drives out to those GPS coordinates, then no, no he has not discovered jack shit.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
then getting all pissy at Microsoft for trying to make a Java runtime that didn't suck shit.
The Microsoft JVM ran rings around Sun's, at that time.
-
@fbmac said in Blakeyrat Reads StackOverflow While Bored At Work:
Embrace, extend and extinguish tactics came from internal Microsoft documents, you can't claim they were just making things better.
They would have killed Java, or transformed it into something windows-only.Bullshit. I was there when it happened. Microsoft added a handful of JVM-specific methods to a couple of classes. I remember the analysis. Also, those methods were ones that many programs wouldn't even need, so the vast majority of them would still have been compatible with other JVMs.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
to the point where they expended huge amounts of resources building their own JVM from spec, until Sun suddenly decided they didn't really want that 90% of their install base and sued to get rid of it.
Sun, if anyone there had a brain, probably didn't like Microsoft's answer to AWT, the WFC (Windows Foundation Classes) which were all kinds of better than AWT's API.
I'm sure it's not a coincidence that the .Net basic class library looks a hell of a lot like WFC.
-
@FrostCat said in Blakeyrat Reads StackOverflow While Bored At Work:
Bullshit
wikipedia said so, and I'll rather trust wikipedia than some random person in a forum
-
@fbmac Wikipedia is edited by pissers.
-
@blakeyrat said in Blakeyrat Reads StackOverflow While Bored At Work:
Has a fifteen year old from Canada discovered a hidden Mayan city?
Recent news stories have reported on the discovery of a lost Mayan city by William Gadoury, a 15-year-old from Canada. According to these reports, Gadoury noticed a correspondence between the locat...
From the comments:
"Are you aware that this story has been covered by multiple reputable news agencies, including BBC, CBC, National Post, Journal de Montreal, Newsweek, Daily Mail, Express, Huffington Post, Channel 9 Australia.... "
Reputable.I'm sure none of them have ever reported a story that was wrong.
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
This might be really hard in the case of some dynamic languages
Yes. It is. The LLVM optimiser isn't tuned for the JIT case, which is what you need to get really good performance out of dynamic languages. LLVM's main focus is on being a really nice back end of a standard compiler, handling common things like optimisation and native code generation.
-
@AyGeePlus said in Blakeyrat Reads StackOverflow While Bored At Work:
Those are hundreds of megs(for some reason. Probably variable names and camelcase )
It's virtually all the Java language runtime, which includes a lot of stuff. GUI? In there. XML handling? In there. Internationalisation engine? In there. I think even the Java language compiler is in there. The JRE core isn't very large (it's a bit of C++, the GC engine, the low-level code verifier and the JIT compiler) but it is only a little bit of the JRE-as-distributed.
Anyone accusing the JRE of being a bloated pig is pushing at an open stable door. With the horse long bolted.
-
@FrostCat said in Blakeyrat Reads StackOverflow While Bored At Work:
Microsoft added a handful of JVM-specific methods to a couple of classes.
There's a list of the issues at Wikipedia. Some of the problems were caused by the people involved just being too suspicious of each other to work together well; if they hadn't gone in with daggers drawn, stuff could have been worked out.
I'm guessing that the JNI vs J/Direct stuff could have been sorted out if there'd been a will (given that JNI is pretty sucky, I think I know which way this should have gone) and a compromise reached over callbacks and delegates. RMI would have been a harder fight, as it would have had a big impact on the lock-in tactics favoured by MS at this point (as RMI and DCOM played in the same space). The vendor-specific libraries stuff would have been awful, but possible to handle out of band. (Apple also had some shenanigans for their JVMs, but they were small and didn't make cross-platform applications impossible.)
But the people didn't trust each other enough to get that far and it spiralled all the way into court.
Visual J++ - Wikipedia