On the other hand, you still get some speedup from parallelizing your code in a distributed fashion and pretending that your multicore machine is a cluster-in-a-box. (In my experience the speedup is actually as-good or better, perhaps because contention for the main bus is the limiting factor in both cases but separating the work along process boundaries results in better locality and more efficient use of caches, but I'm just speculating here.) And once you bite the bullet and go distributed, the sky is the limit as to how far up you can scale. Right now shared-memory multicore parallelism is kind of a sweet-spot in the programming-effort-to-speedup tradeoff, but ultimately its a detour on the road to true scalability.
the_golden_eel
u/the_golden_eel
Feed options
Hot
New
Top
View
Card
Compact
What is the sane person's use case for quaternion literals? Are you really going to write
Rotation<3,double> r = 0.37078990192R + 0.8318099079I + 0.19377299161J + 0.37793612957K;
99% of the time quaternions are used for rotation, so there's a pretty good chance the numbers involved are either irrational (on account of the square root used to normalize them) or the output of a trig function in which case you're not using a litteral anyway.
That's how you do cross platform C++? Re-write a significant chunk of your app for every platform? That's great if you're a multi-billion dollar software company, or an open-source project that was bootstrapped by one. But if it's just me and maybe a few other devs, and and we've got a handful of users on the mac, half-a-handful on linux and 2 handfuls on windows (think quick-and-dirty in-house development) then Qt is the only sane solution.
For sure, but there might be other languages that are friendlier. LLVM and Clang are big projects with lots of very smart people working very hard on them, plus they have performance requirements that justify the extra verbosity/tedium/complexity of C++ (as compared to say Python, Ruby, OCaml, etc.) I just want to hack on something fun in my spare time. I use C++ almost exclusively at work, and a toy compiler would be a good excuse to try something else.
I'm guessing that's the JIT equivalent of hello world, and like ManicQin says, it's a lot for formidable than the assembly-like IR.
A question for LLVM users: how much functionality do you lose if you only do ahead-of-time compilation using the (textual) IR and the LLVM command line tools? E.g., are there any optimizations that aren't available if you use LLVM in this way? As a compiler back-end, how does it compare to C?
I've seen people dismiss LLVM because it's written in C++. I happen to like C++ for certain things, but writing a compiler (for fun) isn't one of them, and the LLVM bindings for other, more compiler-implementation-friendly languages seem to lag behind the C++ LLVM API. Does the command line tool suite (llc, llvm-ld, opt, and friends) similarly lag in features? Is it enough to get started on toy/prototype language implementation? For some reason, using llvm-the-toolsuite rather than llvm-the-library seems like a simpler and cleaner way to get started, but I'd love to hear experiences of people who've tried it both ways, any which they prefer. (Again, this is for simple prototype/experimental statically-typed compiled languages, where the other obvious choice is compile-to-C)
