General Discussion Undecided where to post - do it here. |
Reply to Thread New Thread |
![]() |
#21 |
|
Chrome came with a brand new implementation using JIT (just-in-time compiling). We just need to kill IE 6-8 quickly. ![]() ![]() |
![]() |
![]() |
#22 |
|
So then it'll use more memory and be just as slow the first time you run a website, won't it? Does it only use JIT for methods? How does it handle lambdas? ![]() I haven't looked into the specific implementation of it, just the high-level design. It's not just as slow the first time you run it because the conversion itself is highly optimized, and it doesn't just run it literally as it's written. It aggressively optimizes the JS, just as when you compile C++ or something with optimizations turned on. Because it's done intelligently from start to finish, it's wickedly fast. ![]() ![]() ![]() |
![]() |
![]() |
#23 |
|
gcc isn't even that clever. The IBM C/C++ compiler smokes the **** out of gcc in terms of performance. It's not even close. Unfortunately it's PowerPC only. But they do insane amounts of research and innovation in compiler design & optimization. Intel's C/C++ compiler is by far the best for x86...I think Visual Studio is 2nd, then gcc.
gcc is awful because it's lenient with the standards. Though they're trying, slowly, to tighten up. I can't remember all the devs I had *****ing at me thinking the compiler was broken -- "But this C++ code works with gcc!", and they never took the answer "gcc shouldn't. Your code is not standards compliant" very well. *******s. ![]() |
![]() |
![]() |
#24 |
|
|
![]() |
![]() |
#25 |
|
I actually had a mini argument with the dude interviewing me today for a (mostly) C++ position. It was about the use of virtual destructors (which is asked in every ****ing C++ interview EVER...if you interview for a C++ job and you didn't prepare for this question or know it intuitively, you deserve to not get the job).
I told them the reason why you should have virtual destructors for any class with any virtual members is because if it's not virtual, it's undefined behaviour to the C++ runtime how to proceed with destructing any derived class if it is deleted via a base class object. He tried to "correct" me that it will simply always leak memory by never calling the destructors of any derived class, if you delete it via a pointer to its base class. I spent a good two minutes arguing this was incorrect (very politely), and in fact it is an undefined behaviour that is simply inconsistent from compiler/runtime to compiler/runtime. But that for all intents and purposes one should assume it would leak memory, and simply always use virtual destructors for any classes with virtual members. About 30 minutes after the call, I got an email from the guy telling me I was right. ![]() |
![]() |
![]() |
#26 |
|
|
![]() |
![]() |
#28 |
|
|
![]() |
![]() |
#29 |
|
I'm probably the only CS geek on the planet who can't ****ing stand Python. |
![]() |
![]() |
#30 |
|
I have to admit, it is INCREDIBLY slow with objects (probably because it type checks CONSTANTLY), mixing tabs and spaces is clinically proven to cause people to GO POSTAL, and it is extremely difficult to test all of your code and edge cases can be a huge ****ing ***** but oh my god it's so simple! My company launched a python-powered extremely dynamic website (Plone is the CMS), and immediately after putting it in production the site slowed to a CRAWL. It was HIDEOUSLY slow. Patheticly slow. Unbelievably slow. I had to "fix" the problem by implementing aggressive HTTP proxy caches (Varnish), hand-tuning browser cache settings, implementing memcached (which was a MySQL perf problem more than Python), and basically get the code to run once, cache for hours...and never run again. Because it was so ****ing slow. Even that didn't fix it. I had to break it up into an Amazon EC2 array with a load balancer. It'd constantly poll the load levels on the server, and once it sustained at a high level it'd automatically spawn a new server (boots, configs, and installs in ~3 mins) and attaches to the load balancer to handle the extra load. During our lunch time peak traffic, the site runs on 12 ****ing servers...it shrinks down to 1 automatically at its lowest traffic (3am). Anyway...that was a ****ing month of a nightmare, all thanks to Python. ![]() |
![]() |
![]() |
#32 |
|
|
![]() |
![]() |
#35 |
|
|
![]() |
![]() |
#36 |
|
|
![]() |
Reply to Thread New Thread |
Currently Active Users Viewing This Thread: 2 (0 members and 2 guests) | |
|