installing flash player on ubuntu 64 bit

Basically you can install flash player on a 32 bit ubuntu machine by using apt

$ sudo apt-get install flashplugin-nonfree

It downloads and installs flash player. And all you have got to do in restart firefox.

The issue I faced was how to install flash player on a 64 bit ubuntu machine. As far as i am aware there is no stable release of any flash player for a 64 bit machine. The only way to make the flash based websites work is to install something known as "nspluginwrapper".

nspluginwrapper allows you to use 32 bit netscape compatible plugins on x86_64 browsers. So, the flash plugin is 32 bit but nspluginwrapper allows it to run on browsers compiled for x86_64 machines.

To install flash plugin for 64 bit browser using apt:

$ sudo apt-get install nspluginwrapper flashplugin-nonfree lib32mss-mdns

Restart firefox and bingo, you have flash plugin on your browser.

MySQL versus PostgreSQL

I created and ran some simple tests on mysql and postgresql to figure out which one is faster. It is already known that postgresql is more stable and reliable than mysql. pgsql has a rich set of features. It is a complete RDBMS and also supports fulltext search.

All benchmarks were done on my laptop - Intel core 2 duo (2.0 GHz) with 4MB L2 cache & 2 GB ram. I have 64 Bit ubuntu system loaded with MySQL 5.1.24-rc (64 bit binary) and PostgreSQL 8.3.1 (compiled from source).

I used python as a scripting language for writing down my benchmark scripts. I used psycopg2 as a connector from python to postgres and mysql-python as a connector from python to mysql.

The benchmarking was done in phases. Firstly simple Insert, update and select queries were run to check the raw speed of these queries. Then threads were created to run simultaneous insert, update, select and delete queries. I checked the benchmark times for different number of concurrent threads.

I created a simple table on both mysql and pgsql. I used the MyISAM database engine to create table in mysql. :

ABC(id int not null auto_increment primary key, value varchar(250));

Queries that were run are:

Insert(I) : Insert ignore into ABC (id, value) ...(For pgsql, a rule has to be created to ignore duplicate inserts)
Update(U) : Update ABC set value=<something> where id=<random_id>
Select(S) : Select * from ABC where id=<random_id>
Delete(D) : Delete from ABC where id=<random_id>

• Insert - 100000 rows in 1 thread
  Time taken for Mysql : 20.8 seconds
  Time taken for Pgsql : 58.1 seconds
  So, raw insert speed of mysql is much better as compared to pgsql


• 100000 selects in 1 thread
  Time taken for Mysql : 21.76 seconds
  Time taken for Pgsql : 20.15 seconds
  Raw selects are better in pgsql as compared to mysql


• Selects - 2 threads of 100000 selects
  Time taken for Mysql : 40.46 seconds
  Time taken for Pgsql : 27.38 seconds
  So, if i increase the concurrency of selects, pgsql perfors much than mysql


• Update - 2 threads of 50000
  Time taken for Mysql : 23.97 seconds
  Time taken for Pgsql : 34.03 seconds
  Mysql looks better in handling updates here.


• 4 Threads
  Run 1 : [100000 Selects, 50000 Inserts, 50000 Updates, 20000 Deletes]
  Time taken for Mysql : 45.25 seconds
  Time taken for Pgsql : 54.58 seconds
  Run 2 : [100000 Selects, 100000 Inserts, 50000 Updates, 10000 Deletes]
  Time taken for Mysql : 59.05 seconds
  Time taken for Pgsql : 69.38 seconds
  Run 3 : [100000 Selects, 20000 Inserts, 20000 Updates, 1000 Deletes]
  Time taken for Mysql : 35.54 seconds
  Time taken for Pgsql : 31.23 seconds
  These runs show that Mysql is good when you have very large no of inserts/updates/deletes as compared to selects. But pgsql's performance surpasses that of mysql when the number of selects are much higher.


• Finally, lets approach the real life scenario where generally the number of selects are much more than the number of inserts and there are multiple threads performing selects and inserts.
  I will use the following notification here - <no_of_threads> X <no_of_operations(select/insert/update/delete)_per_thread>
  So, for example 3 X 20 Selects = 3 threads of 20 Selects in each thread
  
  Run 1 : [2 X 30000 selects, 3 X 20000 selects, 1 X 20000 inserts, 2 X 10000 inserts, 2 X 100000 updates, 2 X 1000 deletes] Total - 12 threads
  Time taken for Mysql : 42.28 seconds
  Time taken for Pgsql : 44.28 seconds
  Both Mysql and Pgsql are almost at par.
  
  Run 2 : [2 X 50000 selects, 2 X 40000 selects, 1 X 30000 selects, 1 X 20000 inserts, 2 X 15000 inserts, 2 X 15000 updates, 2 X 2000 deletes] Total - 12 threads but number of selects are quite high
  Time taken for Mysql : 61.02 seconds
  Time taken for Pgsql : 48.60 seconds
  So, as we increase the number of operations (specially selects) mysql's performance degrades, whereas pgsql's performance remains almost the same
  
  Run 3 : [4 X 50000 selects, 4 X 40000 selects, 2 X 30000 selects, 2 X 20000 inserts, 3 X 15000 inserts, 3 X 15000 updates, 2 X 3000 deletes] Total - 20 threads (10 threads for select, 5 for insert, 3 for update and 2 for delete) Which is the normal trend in database servers.
  Time taken for Mysql : 169.31 seconds
  Time taken for Pgsql : 128.7 seconds
  Bingo, so as concurrency increases pgsql becomes faster than mysql.

My earlier benchmarks with pgsql 7.x was not as good as this one. With postgresql 8.3.1, the speed of serving concurrent requests has increased a lot. So, in a high concurrency environment, i would generally recommend to go ahead with using postgresql rather than mysql.

Please check the comments section. We have some really interesting comments there...

32 bit or 64 bit

Theoretically a 32 bit processor can address 2^32 bits or 4 GB of memory, where as a 64 bit processor can address 2^64 bits or 16 exabytes of memory. The speed of computing should not differ much. But the fact that a 64 bit processor has 64 bit wide address space, it can perform large calculations faster as compared to 32 bit processors.

Generally, you would not even realize whether you have a 64 bit system or not. I did not realize that my cpu was 64 bit untill last week (after 6 months of having the system). Even if you have a 64 bit cpu, you might have loaded a 32 bit OS on it.

if you do a "uname -a", it would spill out the details of the kernel.
For a 32 bit system it might be something like
Linux jayantbox 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 i386 GNU/Linux
And for a 64 bit system, it would be something like
Linux jayantbox 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

Then, how do you identify if your cpu is 32 bit or 64 bit? If you know your cpu model no, you can google for it and you might find out that theoretically your cpu is a 64 bit or not. Another way is to do a

jayant@jayantbox:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
.
.
.
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 3994.26
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:



The lm flag tells that the cpu in 64 bit wide.

So, you would say, if there is no increase in computing power, what benefit would i get out of using a 64 bit machine?

Well, firstly, if you need your applications to address more than 4 GB of memory, you definitely need a 64 bit system. So suppose you have a machine with 16 GB RAM and you need to run java with a heap size of 10 GB, or run mysql on it with a key_buffer of 8 GB then the only way you can do it is by using 64 bit OS on a 64 bit cpu. With 32 bit system, java can have a max heap size of only 2-2.5 GB and mysql can have a key_buffer size of only 4 GB.

But, desktops. They dont have such large amounts of RAM. Then a desktop should not be a 64 bit system.

Well, untill now, my experience says that if you are using your desktop for general purposes like word processor, games, net browsing etc, then it does not make sense to use a 64 bit system. Cause i found it difficult to get 64 bit stable binaries for most of the programs that i used to use. But if you are using it for heavy processing, development, then 64 bit might help. After shifting to a 64 bit machine, i found out that my system load has gone down a bit and that performance has improved a little (not a huge difference). There is ofcourse a geeky index linked with the use of a 64 bit system.

But 64 bit systems, as of today are meant for servers and not for desktops.

a 64 bit machine can perform large calculations in hardware faster by using 64 bit integers instead of emulating 64 bit operations using a bunch of 32 bit integers. So, you might find heavy games running better on 64 bit platform as compared to a 32 bit platform. But 64 bit platform requires more cache space for the same program on a 32 bit platform due to the bloated pointers and argument padding used in 64 bit systems. You might also come across some 64 bit programs which are slower than 32 bit programs. My personal thought on this is that those programs are not yet optimized to run on 64 bit platforms.

Lets list the pros and cons of using a 64 bit platform as compared to a 32 bit platform.

1. 64 bit platform has large address space as compared to a 32 bit platform.
2. Big calculations at hardware level at hardware level are faster in 64 bit platform as compared to 32 bit platform
3. The same program occupies more memory due to bloated pointers and argument paddings.
4. Binaries compiled on 64 bit platforms are larger as compared to binaries on 32 bit platform.
5. Most commercial softwares are built for 32 bit platform. So finding pre compiled softwares for 64 bit platform might be difficult.

There are cases when you would want to run a 32 bit binary on 64 bit platform - for which 32 bit emulators are available.

You can have a look at some benchmarks for UltraSPARC platform using Solaris 9 here:
http://www.osnews.com/story/5768/Are_64-bit_Binaries_Really_Slower_than_32-bit_Binaries_/page1/