391–400 of 579 posts
Earlier quoted context omitted.
Yes, and why? way to not address the question at all.
Are you asking why the M2 is faster than the i5?
Tangential, but I practically owe my life to this guy. He wrote the flask mega tutorial in what I followed religiously to launch my first website. Then right before launch, in the most critical part of my entire application; piping a fragged file in flask. He answered my stackoverflow question, I put his fix live, and the site went viral. Here's the link for posterity's sake https://stackoverflow.com/a/34391304/41802…
You have made my day, sir. :)
I hope it doesn't get stuck at 3.14, like TeX. https://www.reddit.com/r/RedditDayOf/comments/7we430/donald_...
Earlier quoted context omitted.
> x86 doesn't have magical backwards compatibility powers. I never said it did; other ISAs have similar if not longer periods of backwards compatability (IBM's Z systems architecture is backwards compatible with the System/360 released in 1964). > The amazing backwards compatibility of Windows is purely due to the sheer continuous effort of Microsoft. I never mentioned Windows but it's ridiculous to imply its backwar…
>I never mentioned Windows but it's ridiculous to imply its backwards compatability is all on Microsoft. I never said that. Windows was just an easy example. >Show me a single example of a backwards breaking change in x86 that Windows has to compensate for to maintain backwards compatability. - The shift from 16-bit to 32-bit protected mode with the Intel 80386 processor that fundamentally altered how the processor m…
I said x86 has "over 30 years of backwards compatibility". The 80386 was released in 1985, 40 years ago :)
> Intel 80286 introduced a 24-bit address bus to support more memory, but this broke the address wraparound behavior of the 8086.
This is the only breaking change in x86 that I'm aware of and it's a rather light one as it only affected programs relying on an exactly 2^16 memory space. And, again, that was over 40 years ago!
> The shift to x86-64 that Microsoft had to compensate with emulation and WOW64
No, I don't think so. A x86-64 CPU starts in 32 bit mode and then has to enter 64 bit mode (I'd know, I spent many weekends getting that transition right for my toy OS). This 32 bit mode is absolutely backwards compatible AFAIK.
WOW64 is merely a part of Microsoft's OS design to allow 32 bit programs to do syscalls to a 64 bit kernel, as I understand it.
Earlier quoted context omitted.
I've been writing Python professionally for a couple of decades, and there've only been 2-3 times where its performance actually mattered. When writing a Flask API, the timing usually looks like: process the request for .1ms, make a DB call for 300ms, generate a response for .1ms. Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it…
> Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it back out for 3 seconds. > You could rewrite that in Rust and it wouldn't be any faster. I was asked to rewrite some NumPy image processing in C++, because NumPy worked fine for 1024px test images but balked when given 40 Mpx photos. I cut the runtime by an order of magnitude for…
Personally though I find it easier to just drop into C extensions at the point that NumPy becomes a limiting factor. They're so easy to do and it lets me keep the Python usability.
Earlier quoted context omitted.
I think perhaps their hope is that eventually Python can get to Go-level if not Rust-level performance if they keep up the optimizations. I do personally believe this to be possible. The motivating example is Julia, which is a high level language with low-level language's performance. After arriving there, developers will care.
I agree, I think that's probably the hope. It's interesting you bring up Julia here because I was just reading the post about the 1.12 release and this comment struck me: https://news.ycombinator.com/item?id=45524485 Particularly this part is relevent to the Python discussion: What is Julia's central conceit? It aims to solve "the two language" problem, i.e. the problem where prototyping or rapid development is done…
Earlier quoted context omitted.
You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…
To be fair, if math did have version numbers, we could abandon a lot of hideous notational cruft / symbol overloading, and use tau instead of pi. Math notation is arguably considerably worse than perl -- can you imagine if perl practically required a convention of single-letter variable names everywhere? What modern language designer would make it so placing two variable names right next to each other denotes multipl…
Earlier quoted context omitted.
> Are there any serious technical reasons not to do it? Yes. First is startup time. REPL cycle being fast is a big advantage for development. From a business perspective, dev time is more expensive then compute time by orders of magnitude. Every time you make a change, you have to recompile the program. Meanwhile with regular python, you can literally develop during execution. Second is compatibility. Numpy and pytor…
I really hope I'll never need to touch code written by people who code in python and throws it at a plausible randomiser to get java or C If you for some reason do this, please keep the python around so I can at least look at whatever the human was aiming at. It's probably also wrong as they picked this workflow, but there's a chance it has something useful
However, if the output quality is crap, then well, maybe his creativity should not be rewarded. I've seem hefty amount of Map in Java, written primarily by JS developers.
Earlier quoted context omitted.
> Why not use a faster language in the first place? Well for the obvious reason that there isn't really anything like a Jupyter notebook for C. I can interactively manipulate and display huge datasets in Python, and without having to buy a Matlab license. That's why Python took off in this area, really
I agree - Jupyter notebook is really the key feature Python has that makes it attractive for research/scientific computing. I would say the REPL too but until very recently it was extremely shoddy so I doubt many people did any serious work in it.