541–550 of 819 posts
Earlier quoted context omitted.
"faster" vs "reduced time". Many people confuse rate of work with reduction in time, and it's exceptionally annoying :(
Bonus points if the 'speed is faster'.
I love me some of those "discount -50%" signs though.
Earlier quoted context omitted.
Shit performance is what happens when every response to optimizations or overhead is immediately answered with "premature optimization is the root of all evil." Or the always fun "profile it!" or "the runtime will optimize it" when discussing new language features and systems. So often performance isn't just ignored, it's actively preached against. Don't question how that new runtime feature performs today or even da…
The Java and Python runtimes, which have much better test coverage and higher correctness standards than most enteprise applications, shipped a broken sort method for decades because it was a few percent faster. Never mind that for some inputs the returned value wouldn't actually be sorted. As an industry we're not qualified to even start caring about performance when our record on correctness is so abysmal. If you h…
Earlier quoted context omitted.
Transpile to C? Zig or Rust?
> Transpile to C? If you transpile something to C it does't mean it will be fast. You can write slow C code (or transpile something to C that will be slow). The compilers are not the issue here.
Earlier quoted context omitted.
Go fills that spot for me. I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go structs are isomorphic to C structs. Even though Go has garbage collection, it allocates everything it can on the stack, so only long-lived shared-between-goroutines objects are subject to garbage collection. Go abstracts concurrency, completely removing all conc…
Go strikes me as one of the best "good enough" languages we have right now. You're not going to do HPC in Go, but it's performant enough to run circles around a lot of high level languages and dynamic languages. It abstracts away the stuff that's super error prone about manual memory management, and it's so brutally simple that it's hard for one of your colleagues to write code you're not going to be able to understa…
It ain’t running circles around any managed language, with perhaps the exception of Python.
C#, Java, JS all have comparably good performances, sometimes much better - e.g. when GC can’t be avoided.
Earlier quoted context omitted.
Huh? "10 compilers, IDEs, debuggers, package managers" what are you talking about? (Virtually) No one uses ten different tools to build one application. I don't even know of any C++-specific package managers, although I do know of language-specific package managers for... oh, right, most scripting languages. And an IDE includes a compiler and a debugger, that's what makes it an IDE instead of a text editor. "and at t…
>No one uses ten different tools to build one application. I meant you have a lot of choices to make Instead of having one strong standard which everyone uses, you have X of them which makes changing projects/companies harder, but for solid reason? I don't know. >"and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware" sure, if you're compiling something enormous and bloated...…
Source for claim: That's a problem we actually faced in the Windows CI at my old job. Our test suite invoked about 100k to 150k programs (our program plus a few 3rd party verification programs). In the Linux CI the whole thing ran reasonably fast, but the Windows CI took double as long. I don't recall the exact numbers, but if Windows incurs a 50ms overhead per program call you're looking at 1:20 (one hour twenty minutes) more runtime at 100k invocations.
Also I'm pretty sure I've built LLVM on 16GB memory. Took less than 10 minutes on a i7-2600. The number of files is a trade off: You can combine a bunch of small files into a large file to reduce the build time. You can even write a tool that does that automatically on every compile (and keeps sane debug info). But now incremental builds take longer, because even if you change only one small file, the combined file needs to be rebuild. That's a problem for virtually all compiled languages.
Earlier quoted context omitted.
Agreed that switching to lower level languages give the potential of many orders of magnitude. But the thing that was most enlightening was that removing pandas made a 9900% increase in speed without even a change to language. 20 minutes down to 12 seconds is a very big deal, and I still don't have to remember how to manage pointers.
I don’t believe orders of magnitude is achievable in general. Even python, which is perhaps the slowest mainstream language clocks in at around 10x that of C. Sure, there will be some specialized program where keeping the cache manually small you can achieve big improvements, but most mainstream managed languages have very great performance. The slowdown is caused by the frameworks and whatnot, not the language itsel…
Earlier quoted context omitted.
Perhaps the solution is more on the bioengineering side of things: make smaller people so they can fit in smaller rooms.
That would have a nice side benefit or making space exploration much more economical. Faster too if you can bioengineer higher G resistance at the same time. Maybe someday the outer planets will be colonized by tiny humans measured in millimeters, with 125mm humans darting around the various moons shot out of repurposed tank canons, all laughing at the slow giants stuck down the gravity well on Earth.
Earlier quoted context omitted.
Because it is like saying you use a bash script to configure and launch a c++ application and saying it is a bash script. Python is not a high performance language, it isn't meant to be and it's strengths lie elsewhere. One of it's great strengths is interop with c libs. Your assertion was that numpy etc will be faster than something else despite being python: > Try writing a matmul operation in C++ and profile it ag…
I mean TensorFlow is c++/cuda! No. When I write Tensorflow code I write Python. I don’t care what TF does under the hood just like I don’t care that Python itself might be implemented in C. Though I got to say TF is quite ugly and not a good example of Python’s user friendliness. But that’s another topic.
Article says at one point, "We have reduced the time for the computation by ~119%!", which is impossible. If you reduce it by 100% it is taking zero time already.
It gets even better when people start switching between percentages and "percentage points" referring to a measure that's in percentages originally.
Unfortunately, most of those things are easier communicated and harder to get wrong if you try speaking in a more natural way. This is now "twice as fast" or "2.1x faster" is much clearer and can't go past zero :)
Similarly, I think it'd help to switch back from percentages to actual factors (119% = 1.19), and saying "we reduced the time for the computation by 1.19 of original time" would clearly show what's wrong (and saying "by 1.19x" would signal how it's a small reduction, so it's wrong as well).
Finally, I am 94.8% certain people will keep using percentages even where inappropriate, and with too much precision too!
NIM NIM should be part of the conversation. Typically, people trade slower compute time for faster development time. With NIM, you don’t need to make that trade-off. It allows you to develop in a high-level but get C like performance. I’m surprise its not more widely used.
I've used Nim for about 2 years now. It's a wonderful language but it's desperately lacking a proper web framework and a proper ORM. If such a thing existed I would probably drop Elixir for Nim career-wise.